Why you need a Shared Library if you use Jenkins ?

In today’s world, where loose coupling services and software components are adopted as the main architectural style for building software applications, it’s inevitable that some parts of your CI/CD pipelines are identical between your numerous projects.

Hence, if you use Jenkins as your continuous integration / continuous delivery and deployment automatic software DevOps tool, you will need at some point to setup a Jenkins Shared Library.

What is exactly a Jenkins Shared Library ?

While working on pipelines, you find yourself duplicating code throughout multiple projects, which violates one of the key principles in software development : DRY (Don’t Repeat Yourself).

Here are some examples or use cases where you can find yourself duplicating some of the scripts and methods in your pipelines :

• packaging a maven project into a Jar file
• deploying the artifact into a remote repository
• deploying a java application into an environment
• running sonar analysis and checking the code quality
• …

Consequently the shared library was created, it allowed developers to share code between multiple Jenkins files.

This shared library will hold a collection or a set of common groovy scripts and methods that are shared among independent projects.

Let’s take an example of a simple CI/CD pipeline that package and deploy a maven project into a remote nexus repository :

Diagram flow of the pipeline

pipeline { 
    agent any  
    stages { 
        stage('Run unit test cases') { 
            steps { 
               sh 'mvn clean test' 
            }
        }
        stage('Package into a Jar file') { 
            steps { 
               sh 'mvn package' 
            }
        }
        stage('Deploy to a nexus repository') { 
            steps { 
               sh 'mvn deploy' 
            }
        }
    }
}

Let’s say you have multiple maven projects, this Jenkinsfile will be duplicated throughout those multiple projects, which make it harder to maintain it. So in case future changes comes up, like adding a new stage or modifying an existing one, … you will end up modifying endless Jenkinsfile in different repositories.

So with a Jenkins Shared Library, you will expose this Jenkinsfile as a global variable (more on that later). Hence, your Jenkins file in each project will call that same new global variable.

For instance, if you create a new Shared library called ‘jenkins-shared-library’ and exposed a new global variable ‘deployMavenProject’, it will allow you to have more simplified Jenkinsfile like this :

@Library('jenkins-shared-library') _
deployMavenProject()

How can you create your own Jenkins Shared Library ?

1. Create the project

• Create a new git repository
• Structure your shared library

| 
| src
|--- com
|------ devt
|--------- MavenUtility.groovy
|
| vars
|--- deployMavenProject.groovy
|

The src folder will contain groovy class (just like the standard java source directory folder).

So in this structure the class MavenUtility can be accessed by importing the package com.devt.MavenUtility, and then you can access all of it methods.

The vars folder will contains script files which will be exposed as variable and can be used in pipelines. So in our case, the variable deployMavenProject will be accessible in pipeline.

2. Configure it in your Jenkins Instance

• Click on Manage Jenkins → Configure System
• Scroll until Global Pipeline library
• Add the library

Adding Global Pipeline Libraries

And now you can finally use the library in your Jenkins files.

Hopefully this article helped you understand the benefits of having a Jenkins Shared Library and how you can create your own shared library.