What Is Jenkins Configuration as Code?

Jenkins has long been the de facto CI/CD system for enterprises, but managing it has traditionally required a dedicated administrator who manually configures Jenkins and its large ecosystem of plugins through verbose XML files. CloudBees addressed this operational burden by releasing version 1.0 of the Jenkins Configuration as Code (JCasC) plugin, which allows administrators and developers to define Jenkins configurations in human-readable YAML instead of XML.

With JCasC, teams can:

• Write Jenkins configuration in plain-text YAML files that are easy to read and edit
• Store those configuration files in a version control system such as Git
• Validate and test configuration changes before applying them
• Reuse a single configuration file to set up multiple Jenkins instances consistently

Why Configuration as Code Matters for Jenkins

Jenkins supports over 1,400 plugins, and configuring each one manually through the Jenkins UI or raw XML is error-prone, time-consuming, and difficult to audit. JCasC applies the same principles used in modern software development — version control, code review, repeatability — to Jenkins configuration management.

Mike Wolf, managing director and modern delivery leader specializing in DevOps and Agile at KPMG, speaking at DevOps World | Jenkins World 2018 in San Francisco, noted that configuration as code removes tedious manual processes and supports more industrialized, scalable use of Jenkins across large organizations. Equally important, it encourages system administrators to adopt the rigor and discipline of the modern software development lifecycle.

Mik Kersten, CEO at Tasktop Technologies, framed it as part of a broader industry shift:

“Over the past decade, the DevOps community has started taking all of these deployment and configuration steps and thinking of them as a part of the program — as code. This means we can start applying programming concepts, such as immutability, to the entire delivery pipeline.”

— Mik Kersten, CEO, Tasktop Technologies

Is YAML Good Enough for Jenkins Configuration?

Not everyone in the DevOps community is convinced that YAML is the right medium for configuration as code. Companies such as Atomist and Pulumi have pushed further, enabling developers to express configuration and infrastructure using real programming languages — JavaScript, TypeScript, and Python — rather than markup or domain-specific languages.

Rod Johnson, founder and CEO of Atomist, argued that YAML has inherent limitations when describing complex behaviors:

“There is a role for configuration, but whenever you are describing rich behaviors, code is a lot better. Too often configuration like YAML becomes a bad imperative programming language.”

— Rod Johnson, CEO, Atomist

Kohsuke Kawaguchi, then CTO of CloudBees and creator of Jenkins, acknowledged these alternative approaches but defended JCasC’s pragmatic scope: the plugin is designed to be “good enough for ordinary users of Jenkins.” His reasoning is that user adoption itself drives the plugin’s evolution — as more teams use JCasC, they will push its boundaries and drive further development.

The Broader Shift: Infrastructure and Configuration as Real Code

JCasC sits within a broader industry movement toward treating all infrastructure and configuration decisions as software artifacts. Joe Duffy, CEO of Pulumi, described this shift:

“Configuration as code has been a key addition in the DevOps toolkit over the past decade, to apply more rigorous software engineering practices to configuration problems across an enterprise infrastructure, from virtual machines and containers to databases and networks.”

— Joe Duffy, CEO, Pulumi

Key engineering practices that become possible when configuration is treated as code include:

• Version control and change history: Every configuration change is tracked with a commit message and author attribution
• Code review: Peer review of configuration changes catches errors before they reach production
• Automated CI/CD pipelines: Configuration files can be tested and deployed through the same pipelines used for application code
• Reusable abstractions: Shared modules and packages allow teams and communities to standardize common configurations
• Unit testing: When configuration is expressed in a real programming language, it can be unit tested — something that is difficult or impossible with YAML or XML alone

Atomist’s Johnson also pointed out that code written in modern languages benefits from IDE tooling — syntax highlighting, autocomplete, refactoring support, and static analysis — advantages that flat configuration files cannot offer. Modern languages are also inherently more modular and reusable, making it easier to share and maintain configurations at scale.

Practical Takeaways for DevOps Teams

Whether a team adopts JCasC’s YAML-based approach or a full code-first tool like Pulumi, the underlying principle is the same: Jenkins and infrastructure configuration should be managed with the same discipline as application code. For most Jenkins shops, JCasC offers a practical, low-friction entry point:

• Start by exporting your existing Jenkins configuration to a YAML file using the JCasC plugin
• Commit that file to a Git repository and establish a pull-request review workflow for future changes
• Use the same YAML file to spin up staging or test Jenkins instances for validation before applying changes to production
• As complexity grows, evaluate whether a full programming-language approach (Pulumi, Atomist, or Groovy-based Jenkinsfile pipelines) better fits your team’s needs

The DevOps community’s direction is clear: configuration is too important to manage manually. Tools like JCasC lower the barrier to adopting this discipline without requiring teams to overhaul their existing Jenkins investments.