Jenkins X is an open source project that offers automated CI/CD for cloud native applications on Kubernetes. Now over a year old and under the auspices of the Continuous Delivery Foundation, the emerging interest and growing implementations of Jenkins X has developers learning more about this technology and what it can do for them.
Using Jenkins X provides developers with a number of benefits including faster software delivery releases, simplicity of installation and configuration and enhances the business sustainability over time.
In this blog post, I’ll answer some of the most common questions about Jenkins X and why it’s important to you.
So what is Jenkins X? James Strachan, distinguished engineer at CloudBees and chief architect of Jenkins X, defines Jenkins X as an “open source opinionated way to do continuous delivery with Kubernetes, natively,” without worrying too much about the underlying infrastructure. Jenkins X supports all major cloud platforms including Amazon, Azure, Google, IBM Cloud, OpenShift and Pivotal. It is a sub-project of Jenkins and uses automation, tooling and DevOps best practices to increase development speed and improve CI/CD.
With Jenkins X, Kubernetes can be leveraged without spending too much time and effort configuring the complex ecosystem. It reduces the complexities and provides a guided approach with the right selection of tools, all within a system that is easy to use and learn. Jenkins X ensures that when a project is started, it’s not necessary to spend a lot of time creating the structure and gathering the required files. If you need a Kubernetes cluster, all the tools can automatically be in working condition without worrying about installation and configuration. In fact, a single jx command in Jenkins X can create CD pipelines, Git repositories and set webhooks. The list of what Jenkins X does is vast, and grows daily.
Unlike Jenkins, Jenkins X is opinionated and built to work better with technologies like Docker or Kubernetes. Having said that, Jenkins and Jenkins X are deeply related as everything that is done with Jenkins X can be done with Jenkins, using several plugins and integrations. However, Jenkins X simplifies everything, letting you harness the power of Jenkins 2.0 and using open source tools like Helm, Draft, Monocular, ChartMuseum, Nexus and Docker Registry to easily build cloud native applications.
In fact, it’s this selection of tools and processes that make Jenkins X special and different from Jenkins and any other CI/CD solution. For instance, Jenkins X defines the process, while Jenkins adapts to whichever process are wanted or needed. Jenkins X adopts a CLI/API first approach, relies on configuration as code and embraces external tools (e.g., Helm, Monocular, etc). On the other hand, Jenkins has a UI first approach with configuration via UI, and everything heavily driven by internal plugins. Additionally, the Jenkins X Preview environments enable developers to collaboratively validate changes integrated into the codebase by creating a running system per Pull Request.
Software development processes have completely transformed over the last few years and continue to evolve. With DevOps, developers’ responsibility for application and configuration management has significantly increased. While DevOps aims to improve the speed of development and reduce the risk of downtime, the transition from developer to the operational role hasn’t been very smooth for developers. Nonetheless, DevOps is gaining higher acceptance and adoption. At the same time, significant changes have taken the industry by storm.
Microservices architecture: While the cloud with its several deployment models (public, private and hybrid) gained adoption across all industries, the challenge of deploying, managing and updating applications remained unresolved. This enabled a way forward for a microservices architecture. Unlike the monolithic apps, apps built on microservices can be deployed on smaller, independently deployable and scalable hosts. After taking a cue from the likes of Amazon, eBay, PayPal and Netflix, today most organizations are moving applications from the monolithic to the microservices architecture.
Container ecosystem: Containers, which offer OS virtualization, gained popularity as they solve some of the problems associated with microservices. Today, different containers on the same host can deploy microservices built on different technologies and frameworks. This allows developers to use whatever language they are comfortable with and package the dependencies within the container itself. Containers are also more efficient than virtual machines (VMs), which virtualize only the hardware. Docker, which helped lead the container movement, has a huge repository of preconfigured Docker images in its Dockerhub public repository, which open-source communities use in abundance. These and many other advantages have made containers a default choice for deployment of code on the cloud.
The rise of Kubernetes: While containers make things simpler, they are not free from challenges. In fact, they are similar to VMs when it comes to managing or orchestrating them. It is challenging for any organization to make sure that machines are not under or over provisioned and every dollar spent for memory, CPU, or storage is well accounted for. There was a need for a solution which allowed efficient and optimal operations with an ability to move containers around, automatically if possible. Google found this exact solution a long time ago and later introduced it in the form of Kubernetes. The open source solution simplifies installation, upgrades and orchestration of containers. Though other cloud vendors also offer their own solutions to orchestrate containers, Kubernetes is vendor-agnostic and offers a common platform for handling containers across all types of clouds and even an in-house infrastructure.
Nonetheless, with all these changes, today developers have a lot of options within a fragmented open source ecosystem with numerous tools for CI/CD. Every tool is purpose-built to solve a part of the problem, but it’s not easy to choose the right ones. It can take years for an organization to gain a good enough understanding of CI/CD and develop an efficient setup. Developers often have to spend more time fine-tuning their CI/CD setup than work on real development. There’s also not a straightforward way to manage Kubernetes clusters and people are wary of the lack of effective monitoring for Kubernetes in production environments.
Though Jenkins can help developers make the most of their CI/CD setup with Kubernetes, it is not easy to select the right combination of plugins and configuration which can all work in tandem with the code. Very few teams agree on what’s the best way to do CD on Kubernetes and many haven’t ever set up a Jenkins Pipeline.
These challenges led the community to think about a solution which can leverage Jenkins to automate CI/CD in the cloud for those who haven’t used Kubernetes before or even those who are using Kubernetes but are struggling with CI/CD. The thought eventually took the form of the Jenkins X project.
Jenkins X is built for developers and is designed to help ship code faster, following the best practices in DevOps. That’s why it offers preview environments, simplifies cluster creation with DevEx and can run on different cloud providers’ clusters. One of the biggest advantages of using Jenkins X is that knowledge of Kubernetes internals isn’t necessary and developers can start leveraging the ecosystem right away. However, if it’s necessary to change the setup to fit specific environments or workflows tweaks can be made to the underlying Dockerfile, Jenkins X pipeline, Jenkinsfile or Helm charts as everything is versioned in Git. Let’s examine some of the most talked about features of Jenkins X:
Automated CI and CD: Jenkins X offers a sleek jx command line tool, which allows Jenkins X to be installed inside an existing or new Kubernetes cluster, import projects and bootstrap new applications. Also, Jenkins X creates pipelines for the project automatically.
Environment Promotion via GitOps: Jenkins X allows for the creation of different virtual environments for development, staging, and production, etc. using the Kubernetes Namespaces. Every environment gets its specific configuration, list of versioned applications and configurations stored in the Git repository. The promotion of new versions of applications between these environments is done automatically following GitOps practices. Moreover, code can be promoted from one environment to another manually and change or configure new environments as needed.
Preview Environments: Though the preview environment can be created manually, Jenkins X automatically creates Preview Environments for each pull request. This provides a chance to see the effect of changes before merging them. Further, Jenkins X adds a comment to the Pull Request with a link for the preview for team members.
You can learn more about all Jenkins X features here.
Easier setup: Jenkins X offers build packs for different kinds of projects, automates the installation, configuration and upgrades of external tools (Helm, Skaffold, Monocular etc.), and helps developers get started quickly with a single line jx command. Moreover, developers have freedom to explore the internal plumbing of Jenkins X whenever deemed fit.
Isolation: Every team gets to run its own instance of Jenkins X; either in a shared cluster or in their own separate clusters. Within a shared cluster, each team can have its own namespace and can effectively share resources while being able to have different pipelines, flows, and configuration as that used by other teams. With separate clusters, the teams get its own set of resources, and won’t be impacted by other teams’ workloads.
Higher velocity: Jenkins X allows unhindered development without shipping logistics slowing things down. Powerful commands expedite most tasks and provide seamless integration with cloud or SCM. For example, a simple ”jx create cluster gke” command installs Jenkins X on Google cloud. AWS (EKS), Azure (AKS), Oracle (OKE) and more can also be used. Furthermore, the application code along with all necessary files for containers, packaging, and pipelines are stored in a common repository and are available out of the box.
Faster recovery: GitOps creates a single source of truth with everything versioned and comments available for every pull request. The configuration as code, of both Jenkins X and your environments, allows developers to get the right context and traceable information to resolve outages faster.
Predictable releases: Jenkins X helps create development/test environments using the “jx create devpod” command to provide each developer their own sandbox inside the Jenkins X cluster. As the devbuild pods are the same as those used in the pipeline used in production, it ensures code will perform in a predictable manner. Further, Jenkins X helps spin up Preview Environments before code is promoted to production. All these features help roll out stable code.