Jenkins is the way to achieve simple, effective, code-driven CI/CD and other automation pipelines
Moogsoft Observability Cloud
Launching Jenkins in Kubernetes allowed for worker agents to be launched as pods with the exact containers needed to complete different stages of pipelines.
Background: Founded in 2012, Moogsoft is an AI-driven observability company that provides intelligent monitoring solutions for smart DevOps. We deliver an advanced cloud-native, self-service platform for software engineers, developers and operators to instantly see everything, know what's wrong and fix things faster.
When I started with the organization we were using Jenkins, but not in a great way, with an EC2 instance as a controller using two other static EC2 instances as worker agents. Our deployment model using helm and individual customer instances means other tools for CD were a mess to configure without expensive 3rd party enhancement or direct support.
Goals: We apply AI & machine learning algorithms to your log, metric, trace and alert data. This results in less noise and effective correlation of actionable alerts, reducing the number of incident tickets created and delivering deep contextual insights that enable teams to solve IT problems faster than those relying on rules-based or manual approaches.
Solution & Results: We ended up moving our Jenkins deployment to Kubernetes and building out a Jenkins Shared Library. Jenkins in Kubernetes allows us to dynamically launch worker agents as pods with the exact containers we need to complete different stages of our pipelines.
Honestly, Jenkins made it simple to do what other tools like Spinnaker and Harness couldn't handle very easily. It isn't a small amount of code, but it's not unreasonable either.
DRY'ing out our pipelines with the shared library resulted in most of our pipelines / jenkins jobs being simple function calls to it. This allowed us to abstract the convolution of our pre-existing deploy model behind simple interfaces that were less intimidating for our developers to use/maintain.
The library scripts are also infinitely more testable because of an internal policy we have of "shell/bash/native at the last mile". This means we put as much of our logic into groovy as possible and only use 'sh' or 'bash' steps where most of the needed parameters are supplied from Groovy logic and the withEnv function.
Plugins we used:
- Kubernetes Cloud Plugin - Dynamically create, use, and destroy Jenkins workers.
- Jenkins Shared Libraries - Vary the implementation of the functionality being used in pipelines using git branches. parallel step.
- Gitlab Plugins - The original one was bad, but there are newer multibranch options we are moving to.
- Junit Plugin - Reports.
- Gatling Plugin - Reports.
- Selenium Plugin - Reports.
- Sonar Plugin - Reports and build blocking.
Awesome results!
- We shortened our service change release cycles from weekly to ad-hoc based on merges to master.
- QA team managed pipelines and improved quality of our releases.
- Automated customer instance provisioning.