Jenkins is shifting gears on its platform to address a number of problems like service instability, brittle configuration, and more for Jenkins developers.
As an open source automation server, the Jenkins offers hundreds of plugins to support developers build, deploy and automate the projects. Released in 2011, the platform is currently having thousands of contributors and millions of users.
However, the Jenkins developers face several challenges in the development cycle of a software project. Enterprises nowadays are running bigger workloads, loading up more plugins, while expecting higher availability at the same time.
A lot of projects require developers to frequently restart them because of issues with resources and plugin upgrades. However, the restarts imply degraded service for the software delivery teams. In such cases, they need to wait longer for their builds to start or complete. Service stability has become a mission critical service for enterprises, and the enterprises can’t wait for that long.
The admins aren’t confident about making the changes to projects as it can cause issues for software delivery teams. Making a change that spans multiple plugins is difficult for contributors, as the users might not always upgrade numerous changes at once. When the contributors ship a code, they aren’t confident enough about running it automatically.
Kohsuke Kawaguchi, the creator of Jenkins, and CTO of CloudBees wrote in a blog post, that it’s time to tackle the problems, taking two new initiatives— Cloud-native Jenkins, and to insert a jolt in Jenkins.
The Cloud-native Jenkins is a general-purpose continuous integration and continuous delivery (CI/CD) engine that runs on Kubernetes. It embraces a fundamentally different architecture and extensibility mechanism.
On the other hand, the jolt in Jenkins continue the incremental trajectory of Jenkins 2. It will accelerate the development and offer better stability.
Cloud native Jenkins is now going to embrace the Kubernetes’s serverless approach, the functionalities deployed as separate microservices, as well as the services interacting through Kubernetes CRDs. It will enable infinite scalability, pay-as-you-go cost model, immutability, zero downtime operability etc.
Jenkins is also moving the data storage from file system to data services backed by cloud managed services. It will help users achieve high availability and horizontal scalability.
The Configuration as Code in the Cloud-native Jenkins will partly address the brittle configuration issues. New extensibility mechanism has also been introduced to solve service instability system.
Furthermore, the Cloud-native Jenkins will address the security vulnerabilities that are caused due to design.
Kohsuke mentioned that part of the aim of Cloud-native Jenkins is to grow and morph Jenkins into a shape that works well for Jenkins X.
“Cloud Native Jenkins will be the general-purpose CI/CD engine that runs on Kubernetes, which Jenkins X uses to create an opinionated CD experience for developing cloud native apps.”
Since, the Cloud-native Jenkins only targets a subset of Jenkins functionalities, Kohsuke said that the team behind Jenkins will inject a jolt in Jenkins. They will continue to serve the production workloads on Jenkins 2 while breaking some stuff for accelerated development and better scalability.
Also read: Jelastic PaaS evolves to support Go programming language
Kohsuke will discuss the direction of Jenkins at Jenkins World on September 16 to 19, 2018 in San Francisco.
