The Business Value of Jenkins X in Automating Continuous Everything for Kubernetes

When a team evaluates a new tool, the evaluation task could get de-prioritized in the company’s product backlog. Traditional product owners treat these evaluations as “expenses” and not investments. They would much rather have the entire team focus on pushing revenue-earning features to production. However, forward-thinking product owners understand the velocity, predictability and sustainability that infrastructure-as-code offers, and make healthy bargains to position the team for long-term success.

While vendors bring the latest and greatest tools to the table, enterprises are often left wondering about the business value (or the lack of it) that these solutions bring to their organization and to their customers. This blog cuts your cost of evaluation by articulating business use cases and why you should care. This should help you continue your journey to build modernized solutions for continuous everything.

Teams often spend days manually setting up Jenkins, pipelines and implementing CI/CD effectively. To alleviate that problem, James Strachan and the Jenkins X community have architected and developed Jenkins X, a CI/CD solution for modern cloud applications on Kubernetes.

Jenkins X comes with all the automation you need to be able to focus on your application code. It automates all your CI/CD needs on Kubernetes including:

• Automatic releases with semantic versions, the creation of artifacts, Docker images and Helm charts

• Automatic promotion of versioned artifacts across your environments via GitOps

• Preview environments created on each pull request

Let’s look at the business cases that Jenkins X brings to the table.

A single “jx” command to rule them all

Jenkins users love the single Java command for installation. Jenkins X maintains this tradition and introduces the jx command line . Jenkins X has build packs for different kinds of projects, like Go, Node.js, Spring Boot, etc. to jump start users. Jenkins X can recognize an existing project with “jx import” too, but I chose to create a new Go application using “jx create quickstart.”

I chose to create a new Kubernetes cluster on Google Cloud and used the command “jx create cluster gke” from the getting started guide . For those of you who have tinkered with Kubernetes, you will appreciate the managed Kubernetes services that the cloud providers are coming up with. Jenkins X leverages these managed services, and performs a lot of nitty-gritty details behind the scenes to simplify the workload of teams implementing continuous everything.

Automates install/config/upgrades of tools

Jenkins X automates the installation, configuration and upgrades of tools like Helm, Skaffold, Jenkins, Monocular, Nexus, Docker, KSync, ChartMuseum, etc. This vastly simplifies the user experience, since users don’t have to stomach all the various pieces on day one and can learn at their own pace. With the built-in automation, teams can focus on releasing quality and secure software frequently and predictably to customers, without worrying about the shipping logistics.

Each team gets its own controller

Each team installs its own instance of Jenkins X, where they see their own pipelines in the UI. Each team can have its own controller that won’t interfere with other controllers in the organization.

Each team gets an elastic pool of pods

Each team has their own Kubernetes build pods. Hence, teams can run at their own pace and don’t have to line up behind the entire organization’s workload.

We often preach about the need for purposeful (not suicidal) speed without articulating how exactly we should do that. This is how.

Creates your Git repository and pipelines

The GitHub integration, along with webhooks to trigger pipelines on new commits, made my day. Application, containerization, packaging, pipelines - see all the files that come out of the box! Teams can start to develop new features and tests right away, without getting bogged down by shipping logistics.

Creates a Kubernetes cluster in the cloud

I installed Jenkins X on Google Cloud and it was seamless with a single ”jx create cluster gke” command. Just like that! All I had to do was create a project on Google Cloud and use that project id. You could choose a different cloud of course, like AWS (EKS), Azure (AKS), etc.

Organizations attempt to measure productivity in an attempt to enhance it. The following are classic ways to generate automated infrastructure-as-code and Jenkins X does these out of the box.

Containerizes your application

Authoring immutable infrastructure can take some time, and time is money. Teams will appreciate that application containerization is automated in Jenkins X for applications that generate images and that the Dockerfile is auto-generated.

They say "There ain't no such thing as a free lunch." Well, in Jenkins X, not only did I get the lunch for free (“main.go ” is our sample Go application), I got the lunch box (the Docker container) as well.

Packages and deploys containerized apps

Jenkins X makes releases boring. Helm charts appear in the automatically configured Helm repository. The application runs in a container in the Kubernetes cluster on Google Cloud. Very little drama, I would say.

Declares your first pipeline

And guess the cost of generating your first pipeline, aka Jenkinsfile. None! A neat Jenkinsfile is auto-generated by Jenkins X without you having to key in a single line of pipeline syntax. See Jenkinsfile for a sample Go application .

The default pipeline with three stages (CI Build and push snapshot, Build Release, and Promote to environments) is depicted below in the BlueOcean view.

Feel free to customize the various stages of your pipeline as needed. At CloudBees, we recommend that you practice declaring your pipelines rather than scripting them to prevent the Jenkinsfile from becoming a kitchen sink and eventually a maintenance nightmare.

From the command line, you can use ‘“jx open jenkins” or “jx console” to open the Jenkins UI in a browser. In the screenshot below, five runs of the pipeline have happened with #s 1, 4 and 5 succeeding.

Pre-commit validation in production

Sincere engineers test on local before committing code but local validation on laptops can be error-prone due to missing/incorrect dependencies.

Using “jx create devpod,” you could create a Dev/Test environment using the exact build pods that the pipeline will use in production. With “jx sync,” you could sync your source code inside a container in the Kubernetes cluster on the cloud. Hence, “works in my environment!” is a thing of the past.

Validation in a preview environment

The preview environment is equivalent to a pre-production or an integration environment, where you can validate your application’s behavior alongside other apps, if you choose to. Here’s where you see the world in the same light as your customer would, and that raises confidence before you promote your code to production.

Git is the single source of truth in the Jenkins X world. Audit trails are available in Git, thanks to GitOps being the norm. Everything is versioned, and hence production outages can be debugged with ease.

GitOps!

I have encountered teams having trouble scaling static environments as the company grows. Sharing is not always caring - teams step on each others’ toes when they share static environments. GitOps enables teams to define their environments in an inexpensive and scalable fashion.

Jenkins X uses GitOps to manage configurations for environments and applications, and also application versions. Two environments - staging , and production - are created by default as Git repos, and they do not (and should not) share resources. By default, code promotion happens automatically to staging and manually to production using the “jx promote...” command. However, this is configurable. No one needs to manage these repos.

The presence of one (or more) manual gate(s) is, in fact, the primary difference between continuous delivery and continuous deployment. Some organizations do not allow headless end-2-end runs all the way to production. To remove all manual gates, you may have to wade through both technical challenges and political power play. Jenkins X makes these configurable and you can remove the manual gate(s) when you have built in the organizational discipline.

The number of environments and their names are configurable with the “jx create environment” and “jx edit environment,” although we recommend you take a minimalist approach. As far as environments are concerned, less the merrier, since each additional environment adds to maintenance overhead.

Jenkins X reduces the shelf time of new features and improves “Time2Market” without burning out team members. Teams can:

• Experiment with new ideas safely

• Pivot quickly if the experiment fails.

Here’s how.

Eases rollbacks

Although continuous delivery advocates for roll forward only, the capability to rollback is essential, although you may choose to not use it. In Jenkins X and GitOps, application versions are Git tags. Releases are done from the controller branch, and you could see the release versions under the Release Tab in GitHub. Hence, if you chose to, you could easily revert to the last known good version.

Lowers adoption cost

There is one important question that should be answered by teams doing tool evaluations. If the proof-of-concept of a new tool fits your bill, what would be the transition cost? That is, how many person-hours would it take to migrate away from your current approach? Many successful proofs-of-concept never see the light of day simply because the migration cost is prohibitively expensive and interferes with the team’s “keep the lights on!” responsibilities.

Jenkins commands the lion’s share of the market in the world of pipelines, and every small, medium and large company banks on the fact that most/all new hires come “equipped” with Jenkins knowledge. That radically reduces a key business metric “Time2Code” - which is the time taken for a new hire to build, configure, deploy, test and release code to production.

The powerhouse beneath Jenkins X is ….(drum roll)... Jenkins! So, if you are familiar with Jenkins pipeline-as-code, you are in for a treat. Additionally, Jenkins X automates the installation, configuration and upgrade of Jenkins and other open source tools in a way that teams can focus on building products that wow their customers.

The plethora of technologies and concepts and how they interact can be intimidating in the beginning...

• Continuous everything (integration | testing | delivery | deployment | analytics)

• GitOps

• Git and version control

• Containers and Docker

• Skaffold, which facilitates CD for Kubernetes applications

• Container orchestration and Kubernetes

• Helm charts, that define, install and upgrade apps in Kubernetes

• ChartMuseum, an open-source Helm chart repository

• Managing Kubernetes on a cloud of your choice (Google cloud, AWS, MS Azure...)

• Jenkins Declarative Pipeline syntax and Jenkinsfile

• ...etc.

...and, hence the automated CI/CD solution helps you focus on writing quality and secure applications instead of burning the midnight oil on infrastructure.

Pipeline is no longer a pipe dream! Jenkins X gives more power to you, and removes the pain that makes cloud-native CI/CD on Kubernetes a tough shot in the dark.

Take part in shaping the future of Jenkins X by trying it out and letting us know what issues you face.

The following resources will help you learn:

1. Jenkins X introduction

2. Jenkins X source code

3. Jenkins X webinar

4. James Strachan’s recorded talk at KubeCon

5. James Strachan’s recorded talk at DevOxx UK