CI/CD with Jenkins Pipelines as Shared Libraries

Image for post
Image for post
Photo by tian kuan on Unsplash

@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
+- vars
| +- 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 (Jenkinsfile.yaml)

The service repository contains two files Jenkinsfile and Jenkinsfile.yaml

Jenkinsfile

#!groovy
@Library(‘jenkins-module-repo’) _
calm_one {}

Jenkinsfile.yaml

---
test:
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

Jenkinsfile

#!groovy
@Library(‘jenkins-module-repo@RELEASE_TAG’) _
calm {}

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.

DevOps, Meditation, Bhakti

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store