Jenkins gets new cloud flavor: Jenkins X promises to automate CI/CD and DevOps practices
© Shutterstock / Igoror
New project alert! Jenkins X is built on Jenkins’ shoulders but its focus lies on automating CI/CD for the cloud using Jenkins, as well as other open source tools including Kubernetes and Git. Let’s take a look under its hood.
Can Jenkins become more cloud native? The answer is yes and it’s all thanks to Jenkins X, which is currently proposed as a sub-project within the Jenkins Foundation.
The difference between Jenkins and Jenkins X is that the latter focuses on automating CI/CD for the cloud using Jenkins plus other open source tools like Kubernetes, Helm, Git, Nexus/Artifactory etc.
Jenkins X is targeted at existing and new Jenkins users who are either:
- Already using Kubernetes and want to adopt CI / CD
- Want CI / CD and increasingly to move to the public cloud – though don’t necessarily know anything about Kubernetes
If you want to develop apps on Kubernetes, you can use Jenkins to do CI/CD but that’s no easy job.
But with Kubernetes lies a unique opportunity. It defines the structure and high-level constructs that we can leverage through Jenkins. When we integrate Kubernetes and Jenkins together, developers need not be familiar with how best to do CD on Kubernetes (most people are not) nor do they need to be familiar with Jenkins Pipeline (most people are not). This much better ease of use can make Kubernetes itself a much more attractive platform, and make Jenkins a de-facto CI/CD platform for Kubernetes. This is the motivation of Jenkins X.
Before we dive deeper into what Jenkins X can do, it’s movie time!
Jenkins X “extends the Jenkins ecosystem to solve the problem of automating CI/CD in the cloud,” James Strachan wrote in the blog post announcing the new project.
One of the perks of using Jenkins X is that you don’t have to lose time figuring out how to package software as docker images, create the Kubernetes YAML to run their application on kubernetes, create Preview environments or even learn how to implement CI/CD pipelines with declarative pipeline-as-code
Jenkinsfiles. Everything is automated.
Jenkins X features
Automated CI/CD Pipelines
- get a Pipeline automatically setup that implements best practice CI/CD features:
- makes sure your code is in a git repository (e.g. GitHub) with the necessary webhooks to trigger the Jenkins CI/CD pipelines on push events
- triggers the first release pipeline to promote your application to your teams Staging Environment
On each Pull Request:
- a CI pipeline is triggered to build your application and run all the tests ensuring you keep the master branch in a ready to release state
- your Pull Request is deployed to a Preview Environment
When you merge a Pull Request to the master branch, the Release pipeline is triggered to create a new release:
- a new semantic version number is generated
- the source code is modified for the new version
- new versioned artifacts are published including:
- docker image, helm chart and any language-specific artifacts
- the new version is promoted to Environments
Environment Promotion via GitOps
Each team gets their own environments. Staging and Production are default environments but that doesn’t mean you cannot create as many environments as you need and call them whatever you want.
Each Environment maps to a separate namespace in Kubernetes so they are isolated from each other and can be managed independently.
They use GitOps to manage environments and perform promotion, which means that:
- Each environment gets its own git repository to store all the environment specific configuration together with a list of all the applications and their version and configuration.
- Promotion of new versions of applications to an environment results in:
- a Pull Request is created for the configuration change that triggers the CI pipeline tests on the Environment along with code review and approval
- once the Pull Request is merged the release pipeline for the environment which updates the applications running in that environment by applying the helm chart metadata from the git repository.
Environments can promote automatically as part of a release pipeline but it’s also possible to use manual promotion. The Staging environment is configured to use automatic promotion while Production uses manual promotion.
Jenkins X allows you to create Preview Environments for Pull Requests. This usually happens automatically in the Pull Request Pipelines when a Pull Request is submitted; however, you can do it manually via the jx preview command.
This happens when a Preview Environment is created:
- a new Environment of kind
Previewis created along with a kubernetes namespace which show up the jx get environments command along with the jx environment and jx namespace commands so you can see which preview environments are active and switch into them to look around
- the Pull Request is built as a preview docker image and chart and deployed into the preview environment
- a comment is added to the Pull Request to let your team know the preview application is ready for testing with a link to open the application
Heads-up: Since Jenkins X has more moving pieces than a single JVM, it also needs a Kubernetes cluster.
Alternatively, you can install Jenkins X on an existing kubernetes cluster (provided that it has RBAC enabled!). Also, if you can install and run minikube, you should be able to install Jenkins X on it as well.