Submitted By Jenkins User Canux Cheng
A cumbersome legacy process for building, testing and releasing software is a huge challenge for a global cybersecurity company that has to stay ahead of hackers, fraudsters and trends in cybercrime.
Organization: Cybersecurity solutions for enterprises, governments and SMBs worldwide
Industry: Network Security
Programming Language: C/C++, Node.js, Python, Golang
Platform: Docker or Kubernetes, Linux, Windows
Version Control System: GitLab
Build Tool: Makefile, Jenkinsfile
Community Support: Jenkins.io websites & blogs, Networking at Jenkins event
Creating a flexible CI/CD chain to meet the development needs in the field of cybersecurity.
Background: This international cybersecurity company serves enterprise, governments and small businesses worldwide. The developer team always had too many balls in the air with multiple projects happening simultaneously. These included virtualization tools like kernel-based virtual machines (KVM) IKVM and Oracle’s open source VirtualBox. The interdependencies between projects were applause-worthy. However, nearly everything was managed via a cron job, a time-based scheduler in a Unix-like computer operating system that would program jobs to run periodically at fixed times, dates, or intervals.
Goals: Move everything to Jenkins instead of relying on cron jobs and scripts.
Solution & Results: The main target was to have an automated CI/CD chain and with a few steps using Jenkins, and we got what we wanted. Each project would replace cron job scripts and makefile with a Jenkinsfile, and we used the Jenkins plugin API or an http-based API instead of having to invoke a shell command.
Then we had another challenge: moving all code to GitLab.
To do so, our developers commit code to GitLab which triggers Jenkins to invoke a Jenkinsfile. We built the code on the container using Python/C++ for the back-end and node.js on the front end, allowing us to push to Harbor, a private open source container image registry. Now we can pull new images and deploy to a test bed. Once done, we can then launch an automation test, and if the test passes, the PM can release the latest version.
There were some basic steps we had to follow, including:
- How to convince developer use Jenkins:
- We created a Jenkinsfile for each project
- We deleted Makefile and cron job scripts
- We gave developers no choice
- How to notify users about build/test result:
- We used Slack and email
- How to integrate with GitLab:
- We used the Jenkins-GitLab-plugin
- How to integrate with container:
- Again, we used the Jenkins-GitLab-plugin
- How to monitor Jenkins:
- We rely on Prometheus in Grafana
Now, everyone has a Jenkins account and everything can be visible on the Jenkins UI. It’s like having a DevSecOps Hub. And we got excellent results, including:
- everything is triggered automatically
- every developer/QA knows exactly what is happening with their code, and in real time
- integration with GitLab makes code management easier
- integration with a private registry makes image management easier
- Jenkins status is always visible in case a server or service goes down