@calm.com we have developed pipelines as shared libraries for our CI/CD which has increased developer velocity and reduced DevOps shoulder taps.
Jenkins pipelines are not new and they have become a staple for many teams that use Jenkins for their CI/CD needs. Today we are going to discuss how we @calm use predefined pipelines that complete the expected tasks based on input from local config for our continuous integration and deployment needs across different repositories.
Motivation behind this
- Increase development velocity by providing templates for builds and deployments.
- Reduce variation in how different code bases are released to production.
- Centralized and versioned pipelines for use across engineering.
- Improvements made in one location can help everyone.
- Customize pipeline steps based on input from a local configuration.
- Reduce time to production.
- Reduce shoulder taps for DevOps
We store all our pipeline and module code for Jenkins in one repository. This repository contains all the shared libraries and pipelines that we have developed for our CI and CD needs. The repository follows the structure of Jenkins Shared Libraries.
Structure of Jenkins Shared Library repository
(root)+- src # Groovy source files
| +- calm_one.groovy # one pipeline
| +- calm_two.groovy # second pipeline
| +- get_config.groovy # reads local configuration files
| +- build.groovy # groovy var builds
| +- deploy.groovy # groovy for deploys
Each of the pipelines is
- Independent of each other
- Pipelines call other vars from the Jenkins shared library repo
- Each pipeline provides customization on different steps based on the local config file
The service repository contains two files
parallel_groups: 20…and many other options…
which are defined in template Jenkinsfile.yaml file.
When a new repository is created, developers can place these two files in the repository and Jenkins will automatically scan our GitHub organization for any new repository with Jenkinsfile and automatically start building the code as well as deploy to appropriate environments.
Developers also have an opportunity to lock down which Jenkins library version they want to use by locking the version of the Jenkins shared library repository
This approach has allowed us to scale quickly and increased developer velocity and reduced DevOps shoulder taps. If you have any other ideas on top of this we’d love to hear from you!
@calm our mission is to make the world happier and healthier and DevOps is always trying to do the same internally for our developers by making an ecosystem where they can use our self-service tools to accomplish their tasks.