Kohsuke Kawaguchi, creator of Jenkins and CTO at CloudBees, spoke last month at Jenkins World in Nice about five on-going initiatives to modernize the popular CI/CD tool. The goal is to address the ageing pains Kawaguchi discussed in a post earlier this year, in particular, what he called the "Jenkinsteins" that have arisen: bloated centralized installations of the tool used by a large number of projects and teams, leading to poor performance, as well as dependencies and administration nightmares. The initiatives revolve around Jenkins Evergreen, Jenkins Pipeline (Blue Ocean), Jenkins Configuration-as-Code, Jenkins X, and Cloud-Native Jenkins. Each of these is at a different stage of development and will evolve independently from the others.
A faster out-of-the-box experience is the goal of Jenkins Evergreen, providing pre-assembled, batteries included in distributions that require less administration and configuration effort. Also, Blue Ocean (a widely used plugin today focusing on cleaner visualization of pipelines) will become the default UI (a specific timeline was not announced), removing the current need to switch to classic UI every time a modification is needed. Jenkins Evergreen will also bring self-upgrading capabilities, mostly transparent to users, Kawaguchi said. Evergreen is currently in beta and not recommended for production use yet.
Kawaguchi told InfoQ that Evergreen will finally enable the Continuous Delivery of Jenkins itself. It will enable running post bootstrap self-tests and diagnostics, sending information back for the corresponding teams to monitor errors and trends. Auto-rollback in case of upgrade failure will also be built in. When asked if users would be able to add their own post bootstrap diagnostics, Kawaguchi said the team working on this project should consider that possibility.
Jenkins Configuration as Code (also known as JCasC) aims to support codifying the setup of Jenkins (with sensible defaults) in YAML so that installation and updates to the delivery system can be fully automated. Changes to Jenkins configuration can then be treated by a team like any other code commit and pull request, and rolled back in case of problems. Finally, removing dependencies on Jenkins UI accelerates its setup and administration, is less error-prone and more repeatable. Version 1.0 of the JCasC plugin was released early September and is ready for production use.
Jenkins X is a separate solution altogether from Jenkins (although they share the same pipeline engine behind the scenes) that was introduced earlier this year. It provides a strongly opinionated view for delivering cloud-native (Docker and Kubernetes based) applications based on a GitOps approach. One of its strengths is to quickly onboard newcomers by making use of common third-party tools (Helm charts, Skaffold, and Prow as of version 1.3) and automating common pipelines for particular stacks with the quickstart feature. The jx command line tool further supports the automation of administration tasks and setting up pipelines as well as Kubernetes clusters and environments. Jenkins X is ready for production use.
When asked whether creating a separate solution like Jenkins X could be confusing or increase friction for adoption, Kawaguchi told InfoQ that Jenkins X "carries the same DNA" as Jenkins, just with a different distribution. Jenkins X is directed at specific use cases and workflow, with a reduced UI surface. He also believes that at some point Jenkins X will be bundled with classic Jenkins, as adoption grows. Kawaguchi prefers to see the ecosystem as a whole:
Jenkins is becoming bigger than just a web application and a bunch of plugins. It's a platform for automation. What really makes Jenkins Jenkins is this ecosystem power that a lot of people build on top and experiment and take to different directions. If you look at Jenkins X, that DNA is very much present.
Finally, modernizing Jenkins to run itself as a full cloud-native application in Kubernetes, thus benefiting from increased availability and performance, is the goal of the Cloud Native special interest group. This group will be making incremental improvements to Jenkins architecture in order to move away from its traditional client/server design. For example, supporting pluggable external storage for Jenkins data (currently kept in the server's file system) and moving towards a stateless Jenkins service. There is no timeline at the moment for completion of this initiative, or any of its parts.
At InfoQ we are keen to receive input from our readers. Have you experienced growing pains with classic Jenkins? Do you think the ongoing initiatives will take away those pains? Comments below.
