We’ve seen the evolution of Jenkins over the years become an integral part of the DevOps culture in organizations around the globe. Teams consistently collaborated and made contributions with plugins for the open source project. Nevertheless, adopting DevOps best practices and getting used to the plugin-heavy Jenkins environment hasn’t always been easy for developers.
As a result, Jenkins X was proposed as a sub-project of Jenkins over a year ago to reduce the complexity of delivering CI/CD for cloud native applications on Kubernetes. In this blog post, I’ll cover the features of Jenkins X discussed in the Jenkins X: Continuous Delivery for Kubernetes webinar.
Environment promotion via GitOps
Jenkins X uses GitOps to set up and manage environments and application versions in Git repos. The benefits of using Git for source control management are well documented and established so we’ll use Croc Hunter, a small open source demo, to illustrate how Jenkins X leverages GitOps. Here’s a screenshot of the GitHub repository for this application.
Jenkins X creates the staging and production environments out-of-the-box. Here’s what Croc Hunter looks like in the staging environment.
With this application, you can shoot crocodiles with lasers as long as you want. At the bottom of the screen, you will find the pod hostname of the Kubernetes cluster along with the region, release version and commit ID. The application runs similarly on a different Kubernetes cluster in production.
To explore the typical development flow with GitHub, Jenkins X leverages several open source projects in the Kubernetes ecosystem to implement GitOps. It requires a separate Git repo for every environment. In the example, a small change in the Git repo replaces lasers with fish.
After making the necessary changes in the code, we need to create a new branch; let’s call it “No lasers” and then submit the PR from GitHub.
As soon as we submit the PR, Jenkins X starts a build process on serverless Jenkins. (That’s correct! Jenkins X can run both traditional Jenkins masters and serverless Jenkins where each build triggers containers that just run for the duration of it). Thereafter, it provides the status of the PR build process as shown below. If you are interested, you may want to check what’s happening behind the scenes in a Kubernetes console.
We can interact with a bot to do tasks like approving the PR, assign a user or rerun tests.
On completing the process successfully, the bot also prompts to explore the PR built in the preview environment in Jenkins X.
In the preview environment, we can check if the changes are successful. In our case, the ship has started shooting fish instead of lasers, as intended.
Now, all we have to do is go back to the repo and comment “/approve”, which is configured to tell the bot to approve the merge request.
The bot automatically merges the PR with the master and we can delete the branch.
The PR is automatically promoted to the staging environment. Here, we can see a new version 0.0.131 in the staging to confirm the same.
As illustrated above, Jenkins X automates the setup of pipelines shipping containerized applications. It allows us to make changes, commit and create PR on GitHub and automatically runs code coverage upon PR on serverless Jenkins. Further, it builds the PR and provides a preview environment before you deploy it on staging or production. Once you approve the PR, it is automatically merged into master triggering deployment on the staging environment.
Moving on, let’s explore what else makes Jenkins X special.
While Jenkins X simplifies change requests, testing, CI/CD, audits, rollout and monitoring, it can also be extremely useful in the actual development. It allows you to create a development environment inside k8s cluster in the cloud.
If you have an existing project, you can use a single line command to create a DevPod (a development environment using Kubernetes cluster in the cloud):
jx create devpod —sync
The command detects the type of project and creates a DevPod for you with all the tools pre-installed. You can sync the changes to the DevPod using the following command:
Jenkins X comes with a list of curated quickstart applications that can help you avoid starting from scratch. You can use the following command to quickstart your project:
jx create quickstart
This will give you a list of quickstarts and prompt you to select a language and name your project. Once you have completed these steps Jenkins X automatically creates a new application using the quickstart in a sub-directory. It initializes a Git repository and adds your source code to it. Further, it also builds Dockerfile, Jenkinsfile, Helm charts and everything you need to trigger your first pipeline. This significantly speeds up the process to start a new project.
Jenkins also automates pipeline creation when you import your existing project into Jenkins X.
The road ahead
It’s important to mention that Jenkins X keeps on adding features to benefit users, developers and the open source community. One of these upcoming features is Progressive Delivery with Jenkins X. Progressive Delivery includes techniques such as Canary deployments, where new versions of the software are rolled out to a limited subset of users, and gradually expanded or rolled back on the basis of their performance. We are currently working on automating the entire process. In case you are interested in to learn more about all such upcoming features, you can visit the Jenkins X roadmap page.