DevOpsDays Warsaw 2015 - Łukasz Szczęsny - JaaC

### Overview At DevOpsDays Warsaw 2015, Łukasz Szczęsny, a system engineer at 4finance IT and co-organizer of the Warsaw Linux User Group, presented "Jenkins as a Code" (JaaC). The talk addresses the operational challenges of managing Jenkins at scale, including manual UI configurations, brittle upgrades, unversioned job changes, orphaned plugins, and plain-text credentials. Szczęsny details how his team transitioned hundreds of manually clicked Jenkins jobs into fully automated, version-controlled infrastructure and pipeline definitions using Ansible and the Jenkins Job DSL plugin.

### Key Topics - **Pitfalls of Manual Jenkins Management**: Relying on manual UI configuration leads to un-auditable changes, breaking updates, plain-text credentials stored in SCM XML files, and fear of upgrading legacy instances. - **Infrastructure Automation**: Automating Jenkins master installation, plugin installations, tool provisioning (JDK, Maven, Gradle), and slave node lifecycle management. - **Jobs as Code (JaaC)**: Comparing approaches for version-controlling jobs—such as Jenkins CLI with raw XML, Jenkins Job Builder (from OpenStack), Workflow plugin, and Jenkins Job DSL plugin. - **Case Study at 4finance IT**: Implementing an Ansible-driven provisioning workflow and a Gradle-based Jenkins Job DSL repository with tests to automate roughly 1,000 jobs. - **Jenkins 2.0 Roadmap**: Upcoming improvements discussed by Kosuke Kawaguchi and the community, including decoupling Groovy from core, JavaScript modularization, a UX overhaul, Jenkinsfile integration, and open-sourcing the Stage View plugin.

### Technical Details - **Provisioning & Infrastructure**: Szczęsny uses Ansible for master configuration and tool setup. Slave management uses AWS CloudFormation with Auto Scaling groups and Amazon Machine Images (AMIs) equipped with the Jenkins Swarm plugin, allowing new EC2 instances to auto-connect to the master. Docker plugins and Groovy console SSH scripts are also noted as alternatives. - **Job DSL Implementation**: Jobs are maintained in a Gradle project stored in Git/Stash. The Gradle setup allows developers to write Groovy DSL code in their IDE, compile, and run tests verifying generated XML before changes are applied. - **Enforcing Read-Only Jenkins**: The team locked down Jenkins UI modifications. All changes must be proposed via pull requests. A single initial "seed job" runs automatically every five minutes to scan the DSL repository and create, update, or prune Jenkins jobs. - **Disaster Recovery**: Szczęsny highlights an incident where a misplaced exclamation mark in a Groovy console script deleted almost every job; because everything was defined in code, the entire pipeline suite was recreated within five minutes. - **Interoperability with Workflow**: In the Q&A, Szczęsny clarified that Job DSL does not compete directly with the Jenkins Workflow (Pipeline) plugin. Instead, Job DSL can be used to generate the initial Workflow seed jobs programmatically.

### Takeaways Automating Jenkins setup and treating jobs as code eliminates human error, provides an audit trail via Git pull requests, resolves credential management issues, and makes Jenkins instances reproducible and disaster-resilient. Combining configuration management (Ansible) with Job DSL and automated seed jobs allows engineering teams to scale to thousands of jobs without relying on fragile, manual UI interactions.