A couple weeks ago, I wrote about the Jenkins Essentials effort, on which we’ve been making steady progress. Personally, the most exciting challenge of this project is defining the machinery to drive automatic updates of Jenkins Essentials, which viewed from a high level, are classic continuous delivery challenges.

In this post, I wanted to dive into a bit of the gritty details of how we’re going to be delivering Jenkins Essentials with automatic updates, which has some really interesting requirements for the development of Jenkins itself.

Jenkins Essentials

The traditional Jenkins core and plugin development workflow involves a developer working on changes for some amount of time, then when they’re ready, they "create a release" which typically involves publishing artifacts to our Artifactory, and then on a timer (typically every 15 minutes) the Update Center will re-generate a file called update-center.json. Once the new Update Center has been generated, it is published and consumed by Jenkins installations within 24 hours. Of course, only after Jenkins administrators recognize that there is an update available, can they install it. All in all, it can take quite a long time from when a developer publishes a release, to when it is successfully used by an end-user.

With our desire to make Jenkins Essentials updates seamless and automatic, the status quo clearly was not going to work. Our shift in thinking has required a couple simultaneous efforts to make this more continuously delivered approach viable.

Developer Improvements

Starting from the developer’s workflow, Jesse Glick has been working on publishing "incremental builds" of artifacts into a special Maven repository in Artifactory. Much of his work is described in the very thorough Jenkins Enhancement Proposal 305. This support, which is now live on ci.jenkins.io allows plugin developers to publish versioned changes from pull requests and branches to the incrementals repository. Not only does this make it much easier for Jenkins Essentials to deliver changes closer to the HEAD of master branches, it also unlocks lots of flexibility for Jenkins developers who coordinate changes across matrices of plugins and core, as occasionally is necessary for Jenkins Pipeline, Credentials, Blue Ocean, and a number of other foundational components of a modern Jenkins install.

In a follow-up blog post, Jesse is going to go into much more detail on some of the access control and tooling changes he had to solve to make this incrementals machinery work.

Of course, incremental builds are only a piece of the puzzle, with those artifacts, Jenkins Essentials has to be able to do something useful with them!

Update Improvements

The number one requirement, from my perspective, for the automatically updated distribution is that it is safe. "Safe" means that a user doesn’t need to be involved in the update process, and if something goes wrong, the instance recovers without the user needing to do anything to remediate a "bad code deploy."

In my previous post on the subject, I mentioned Baptiste’s work on Jenkins Enhancement Proposal 302 which describes the "data safety" system for safely applying updates, and in case of failure, rolling back.

The next obvious question is "what’s failure?" which Baptiste spent some time exploring and implementing in two more designs:

On the server side, of which there is substantial work for Jenkins Essentials, these concepts integrate with the concept of an Update Lifecycle between the server and client. In essence, the server side must be able to deliver the right updates to the right clients, and avoid delivering tainted updates (those with known problems) to clients. While this part of the work is still on-going, tremendous progress has been made over the past couple weeks in ensuring that updates can be safely, securely, and automatically delivered.

With the ability to identify "bad code deploys", and having a mechanism for safely rolling back, not only does Jenkins Essentials allow seamless updates, but it enables Jenkins developers to deliver features and bugfixes much more quickly than our current distribution model allows.


While Jenkins Essentials does not have a package ready for broad consumption yet, we’re rapidly closing in on the completion of our first milestone which ties all of these automatic update components together and builds the foundation for continuous delivery of all subsequent improvements.

You can follow our progress in the jenkins-infra/evergreen repository, or join us in our Gitter chat!

About the Author
R. Tyler Croy

R. Tyler Croy has been part of the Jenkins project for the past seven years. While avoiding contributing any Java code, Tyler is involved in many of the other aspects of the project which keep it running, such as this website, infrastructure, governance, etc.