[ ] Update the Part 1 post with a message stating that it is no longer relevant, replaced with this post
[ ] Add Table of Contents
[ ] Add link to git repo
This post is an Update to You Don't Know Jenkins - Part 1, which was written in 2016. If you're looking to deploy & automate a new Jenkins server, use this guide, rather than the steps listed in Part 1.
The Jenkins ecosystem has changed significantly since I wrote Part 1 of the You Don't Know Jenkins series, back in 2016. Pipeline's (previously called Workflows) have matured, and Jenkins introduced a declarative syntax to make it even easier to define Jobs for non-developers.
The Jenkins team has also responded to our collective frustration with Jenkins server installation & initial configuration.
They've released a plugin called "Configuration as Code" which allows us to natively automate almost all of the Jenkins server configuration checklist I described in Part 1:
All company/third party tools required on the build server should be codified
Create a single automation administrator user on Jenkins
Install Jenkins plugins (and allow specific versions to be specified)
Credentials & Secrets should be retrieved from a secure data source and configured in Jenkins.
Configure Jenkins (using xml files on the filesystem, or API calls)
security realm/authentication type (eg. LDAP)
execution nodes, slaves
installation directory
views
Create a single bootstrap Jenkins DSL job that polls git for changes (we'll talk about that below)
Completely disable configure access to the Jenkins server.
~Configure your CM system to reconfigure the Jenkins server on a schedule (weekly/monthly you decide), which lets you continuously update to the latest stable release~
While server level configuration will still need to be managed by a configuration management system (like Chef/Ansible/Docker), we can now configure our Jenkins server (and Jenkins plugins) via yaml configuration files, that are natively understood by Jenkins and backwards compatible.
Before we dive into the Configuration as Code plugin and how to use it, let me just remind you that this post is part of a series that is all about solving common problems using new Jenkins features, modern automation & configuration-as-code practices.
Todo
The Jenkins ecosystem has changed significantly since I wrote Part 1 of the You Don't Know Jenkins series, back in 2016. Pipeline's (previously called Workflows) have matured, and Jenkins introduced a declarative syntax to make it even easier to define Jobs for non-developers.
The Jenkins team has also responded to our collective frustration with Jenkins server installation & initial configuration. They've released a plugin called "Configuration as Code" which allows us to natively automate almost all of the Jenkins server configuration checklist I described in Part 1:
configureaccess to the Jenkins server.While server level configuration will still need to be managed by a configuration management system (like Chef/Ansible/Docker), we can now configure our Jenkins server (and Jenkins plugins) via yaml configuration files, that are natively understood by Jenkins and backwards compatible.
Before we dive into the Configuration as Code plugin and how to use it, let me just remind you that this post is part of a series that is all about solving common problems using new Jenkins features, modern automation & configuration-as-code practices.
Immutable Infrastructure vs Configuration Management
Jenkins Docker Setup
Jenkins Plugins
Configuration as Code Repository
Secret Management
Jenkins Job DSL
Authentication & Authorization