{{announcement.body}}
{{announcement.title}}

Jenkins Configuration as Code: Need for Speed!

DZone 's Guide to

Jenkins Configuration as Code: Need for Speed!

Today we'll see how Jenkins Configuration as Code works faster to manage configuration with simple, declarative YAML files.

· DevOps Zone ·
Free Resource

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 to discuss the JCasC project and its future!

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

Additional Resources

Topics:
configuration ,devops ,jenkins ,jenkins configuration as code ,tutorial ,yaml

Published at DZone with permission of Nicolas De Loof , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}