Jenkins Configuration as Code: Migration

Written by: Nicolas De Loof
3 min read

This blog post is the last article in a six-part series on Jenkins configuration as code.

Using Jenkins configuration as code, one can manage the Jenkins controller configuration with simple, declarative YAML files and manage them as code. Looks promising, so how do you start?

How to migrate?

A major end-user concern is adopting a tool that they don’t need to learn from scratch: they already run a production Jenkins controller, with hundreds of configured plugins, and adopting JCasC will be a huge migration effort for them.

Even users who start a fresh new Jenkins controller from scratch will probably not write their initial JenkinsYAML file without concrete samples. If you missed previous blog posts from the Jenkins configuration as code series, we generate reference documentation and schema you can rely on. But this is still the hard way.

Samples and demos

For those, our GitHub repository includes a demos folder , with sample configuration for various plugins and use-cases (you’re welcome to contribute!). That can help you get started, cherry-picking samples that match your requirements, until you get used to the YAML syntax and Jenkins configuration as code usage.

But life can be easier.

Export from live instance

While building the Yaml-to-Jenkins configuration engine, we noticed in most places we can also get the other way, producing Yaml content from a live Jenkins instance.

Actually, web user interface (UI) data binding, which Jenkins configuration as code replicates with YAML inputs, is built on the same principle: it takes string representation of the data mode in the web UI and converts them into Java model when you hit the submit button. It , also exposes the Java model as web form elements when you come back to the configure page.

So we introduced the export feature.

This button will produce YAML content to reflect the configuration of your Jenkins instance.

One major issue we had implementing this is we only want to exports elements that are not in the default state, to avoid creating a huge YAML dump. In doing so, you can discover the actual changes in this YAML export when you make some changes using the web UI.

This is the lazy way to discover the YAML syntax and to get ready within minutes with Jenkins configuration as code.


Due to internal Jenkins glitches, the export can’t be used as-is to create a Jenkins controller clone, and the YAML stream could include some warnings about the failure to export data. At least, you can use it as a basis to write your own YAML configuration file.

Ok, so what’s next?

This blog post is the last one from the Jenkins configuration as code series. We hope this helped you discover this project and its benefits, and that you’ll give it a try.

You can read more about the Jenkins configuration as code plugin on the project’s GitHub repository . To chat with the community and contributors join our gitter channel . Or come see us in person at DevOps World | Jenkins World 2018 to discuss the JCasC project and its future !

Additional resources

Jenkins Configuration as Code: Look Ma, No Hands

Jenkins Configuration as Code: Sensitive data

Jenkins Configuration as Code: Plugins

Jenkins Configuration as Code: Need for Speed!

Jenkins Configuration as Code: Documentation

Stay up to date

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