Objective
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.
Introduction
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.
Business cases
Eases setup
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.
Autonomous teams
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.
Increases release velocity
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.
Boosts team productivity
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.
Improves predictability of releases
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.
Promotes auditability
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.
Enhances business sustainability
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.
Summary
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.
Resources
The following resources will help you learn:
James Strachan’s recorded talk at DevOxx UK