Jenkins founder and CloudBees CTO Kohsuke Kawaguchi has issued a bleak assessment of the current state of the CI/CD platform and announces a new roadmap that steers it in to a container and cloud native future.
“Trapped in a local optimum and losing appeal to people on the outside” is Kawaguchi’s bleak verdict on the state of the Jenkins automation engine. To address current issues such as service instability and brittle configuration he has formulated a roadmap to get the project back on track. According to Kawaguchi, what is now needed above all is a version of Jenkins that runs well on Kubernetes – a cloud native Jenkins, so to speak. On top of that, some breaking changes seem necessary to gain development speed again.
Jenkins’ plugin structure makes it difficult to work on changes that span across multiple plugins. Also the testing infrastructure in place doesn’t instill enough confidence in contributors to ship code. He also noticed that smaller, reasonable changes tend to get lost in discussions, while regular contributors seem to fear the quality of outside code additions since they’ll have to be accountable once everything is released.
Everything is better in the cloud
To get to an out of the box stable Jenkins, Kawaguchi proposed a Cloud Native Jenkins sub-project to the Cloud Native Special Interest Group of the project. The final product should embrace paradigms like isolated function as a service build execution, a microservice architecture, and service interaction via Kubernetes CRDs, that are propagated by the Kubernetes community. He compares the container orchestration project with Java, describing both as the winning platforms of their time and therefore the ones to orient by.
Another aspect to focus on in Cloud Native Jenkins is configuration as code – the Jenkins initiative of the same name has already been well received to tackle some configuration issues. Jenkins X – a Continuous Integration and Continuous Development for cloud applications on Kubernetes – already showed some efforts to use Jenkins on Kubernetes, so the new cloud native project has to be built in a compatible way. The aim is for Cloud Native Jenkins to become the general CI/CD engine that runs on Kubernetes, with Jenkins X being able to draw on that.
Since extensibility is becoming more and more of a problem, the project will look into microservices and containers as a new way to add functionality. To become highly available without burdening admins, a move to data services that are backed by cloud managed services also seems to be unavoidable for Kawaguchi. Some of the main elements needed to get Cloud Native Jenkins off the ground are already available in Jenkins Pipeline, Evergreen, Configuration as Code, and Jenkinsfile Runner. Things Iike a GUI, and use of persistent volumes might take a while to get added though.
Meanwhile back on earth
Not everyone will be happy to make a switch to cloud native, so additional efforts to get Jenkins 2 to evolve are necessary. To get the development process up to speed, there is a need to renegotiate the expectation around releases, Kawaguchi feels. A new release model with higher frequency releases that uses the rolling distribution system Evergreen might do the trick.
Another expectation the Jenkins team will likely have to break with moving forward is the idea of forever compatibility. Compatibility and the protection of the users’ investment will still be on the agenda, but if a higher number of major releases and therefore breaking changes are needed, Kawaguchi will be open to that.
In order to drive the changes mentioned, CloudBees will staff efforts to accelerate Configuration as Code and make it more central to Jenkins, improve developer experience and Jenkins Pipeline. They’ll also look into reducing plugins, and the integrations needed today, so that it gets easier for maintainers to concentrate on the project’s important parts. More details can be found in Kawaguchi’s blog entry on the topic.