Jenkins Configuration as Code: Need for Speed!

Written by: Nicolas De Loof

2 min read

Stay connected

This blog post is the fourth in the Jenkins configuration as code series.

Using Jenkins configuration as code one can manage the Jenkins master configuration with simple, declarative YAML files, and manage them as code . But one can argue this was already feasible, by managing Jenkins’ XML configuration files as code and storing them in a Git repository.

Applying configuration

Administrators who have implemented Jenkins configuration as code using XML templating know how challenging it is to make some configuration changes. One needs to update the configuration, then ask Jenkins to reload it from the disk, and then wait for a long time for the reload to complete. The pipeline’s asynchronous nature hopefully allows this to happen without stopping builds, but this is still a major trouble for development teams, as the web user interface (UI) isn’t available for a significant amount of time.

As a side effect of reload slowness, administrators avoid reloading the configuration until it is really required. In doing so, the configuration might become out of sync with the upstream reference version, and result in various issues and frustrations. As a result, “minor fixes” might be applied manually on the web UI as a workaround while waiting for the next configuration time slot to apply nightly.

As a result, you lose all the benefits for an as code approach, as you have to configure Jenkins twice: once by using the web UI for a quick fix and the second time to reproduce those changes in XML.

In the blink of an eye

Jenkins configuration as code doesn’t use this reload mechanism. Actually it doesn’t even know about XML persistence on disk. Jenkins configuration as code relies on the web UI data-binding mechanism used when one submits a configuration page to set up Jenkins. Internally, Jenkins converts a json web payload into configuration changes. For Jenkins configuration as code, we reproduced this exact same mechanism, but replaced the json payload with YAML documents.

When you apply a JCasC configuration, you actually run something comparable to submitting all the configuration forms at once.

Actually you probably will hit the “Reload” button multiple times, as you won’t believe we already completed a full reconfiguration of your master within a second.

Ok, so what’s next?

Read more about Jenkins configuration as code plugin on project’s GitHub repository , join our gitter chat to discuss with community and contributors, and meet us at DevOps World | Jenkins World 2018 todiscuss the JCasC project and its future!

Also don’t miss our next post from the Jenkins configuration as code series!

Additional resources

Part 1: Jenkins Configuration as Code: Look Ma, No Hands

Part 2: Jenkins Configuration as Code: Sensitive Data

Part 3: Jenkins Configuration as Code: Plugins

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.

Loading form...
Your ad blocker may be blocking functionality on this page. Please disable for an improved experience.