Jenkins Configuration as Code Sandbox
This is an example of Jenkins Configuration as Code with GitLab.
This is a fully working CI/CD setup with Jenkins and GitLab where everything is put under version control:
- Global Jenkins settings - With Jenkins Configuration as Code.
- Jenkins job configurations - With Job DSL.
- Jenkins build process - With Pipelines and Shared Library.
- Application source code - With GitLab.
This allows for you to:
- Do local development of the CI/CD setup. Giving self confidence to do refactorings and keep all the scripts clean.
- Allow code review of changes to the installation. Enable anyone to contribute to an innovative build CI/CD process.
- Manage different installations in different branches. Push to the branch of installation X and X will automatically be re-configured.
It also demonstrates a pattern where a "contract" is established between application repositories and the infrastructure. A
jenkins-settings.json-file is created in the application repositories to tweak the build process. This means:
- The pipeline code can be developed generically. Pipelines are not created to take care of a specific repo. Generic features are created, and documented, and the application developers chooses what features that should apply to thir repo. By editing
/jenkins-settings.jsonin their repo. A default set of settings are derived and applied if no properties found in the repo.
- The solution becomes scalable and can handle a vast amount of application repositories. With low effort needed for support.
docker-compose up -d
Jenkins now available on: http://localhost:8080/
JobDSL docs available at: http://localhost:8080/plugin/job-dsl/api-viewer/index.html
docker-compose down -v --rmi local
all services are down and data lost