Jenkins, the popular open source CI/CD system, has reached a crossroads, with founder Kohsuke Kawaguchi looking to tackle issues—including instability and configuration problems—that have caused the platform to lose appeal.
The autonomous nature of the Jenkins community has made it unable to solve some issues, which are becoming more pronounced with the project now more than ten years old, Kawaguchi said in a bulletin.
Under Kawaguchi’s plan, the platform’s growing pains will be tackled through a two-pronged development vision:
- Cloud Native Jenkins, a general-purpose CI/CD engine that runs on Kubernetes, embracing a fundamentally different architecture architecture and extensibility mechanism.
- Jolt in Jenkins, which continues the incremental trajectory of the Jenkins 2 upgrade but with users able to gain what is really needed, such as a faster pace of development and improved stability.
What’s wrong with Jenkins
Kawaguchi listed Jenkins’s problems, which include:
- Service instability, with a Jenkins instance—particularly a large one—requiring too much overhead to keep running and requiring daily restarts. Each restart implies degraded service, with software delivery teams having to wait longer for builds. Admins expect Jenkins to better defend itself from issues such as pipeline execution problems and runaway processes
- Brittle configuration, in which Jenkins admins have had to deal with changes, such as installing and upgrading plugins and tweaking job settings, that have caused unintended side effects. Too many admins are not confident they can safely make changes. Upgrading Jenkins and plugins is an important subcase of this situation, with admins often not understanding the impact, thus decreasing their willingness to upgrade and making it difficult for the project to move forward quicker. A compatibility burden ensues.
- Assembly required, with the platform not working out of the box but requiring assembly, like a bucket of Lego blocks.
- Reduced development velocity, with a change spanning multiple plugins proving difficult and tests not offering enough confidence to ship code.
While Kawaguchi’s proposal perhaps paints a grim picture of where Jenkins stands, he said that the project’s future still is very bright, pointing to a growing adoption rate. The proposed changes will let Jenkins be used by a much broader base of developers and devops teams.
Proposal No. 1: the Cloud Native Jenkins subproject
A convergence of several efforts, Cloud Native Jenkins is proposed as a subproject in the Cloud Native Special Interest Group. Anchored by Kubernetes container orchestration, the project would embrace serverless computing, microservices, and—to promote reuse and composability—Kubernetes custom resource definitions.
Also, a new extensibilty mechanism would to continue the Jenkins ecosystem. Microservice- or container-based extensibility, for example, avoids service instability.
Pipeline-shared libraries also are envisioned. Other components of the proposed Cloud Native Jenkins subproject include:
- Taking long-term data and moving it to the cloud.
- A more-central role for Jenkins Configuration as Code, for defining configuration via a plain text YAML syntax, to help alleviate brittle configuration problems.
- A secure-by-default design.
- Jenkins Evergreen, a project intended to solve Jenkins’s brittleness and developer-velocity problems. Evergreen features a preassembled collection of components that can be immediately used to implement CI and CD workloads.
- Cloud Native Jenkins MVP (minimum viable product), featuring a function-as-a-service-style build engine that can be used underneath the Jenkins X cloud system on Kubernetes. This MVP consists of a webhook receiver service to trigger a build engine and is continuously delivered through Evergreen. But it will have no Blue Ocean-style UI.
CloudBees, which has been critical in the development of Jenkins and employs Kawaguchi as its CTO, proposes the continued evolution of the Jenkins pipeline as part of the revamp. A CD pipeline in Jenkins provides workflows, which can be declarative or scripted. There is an ongoing effort to remove continuation-passing-style execution of a pipeline and isolate failures during execution. The plan is to evolve the pipeline so it works well with the Cloud Native Jenkins effort.
Proposal No. 2: the Jolt in Jenkins subproject
Under Kawaguchi’s proposal, Jenkins 2 would continue but at an accelerated speed as the Jolt in Jenkins subproject. Jenkins’s developers need to continue to serve the majority of production workloads on Jenkins 2. But the hope is that by being willing to break things, Jekins will more quickly address its flaws, such as slow pace of development and instability.
Where to download Jenkins
You can download Jenkins from the project website.