Search
  • DevOps, Agile, Digital Transformation
  • Twitter: @ZenDevOpsIO
Search Menu

Using Jenkins Global Pipeline Libraries

With Pipeline as Code becoming a way to provide continuous deployment and/or continuous integration patterns, Jenkins has furthered this pattern with Jenkins Pipelines. Furthermore, by utilizing global pipelines, we can further abstract a pipeline away from a developer and ensure that everyone on your team is building the same way.

Why Build the Same Way?

By enforcing common pipelines and using shared components, a team or even a collection of teams can be building the same way. This provides unity and if a change is needed or a new pipeline feature comes along, the team can reap the benefits. Another advantage is that it can prevent snowflake applications from making their way into your organization. If someone wants to introduce an application stack that can’t follow your agreed upon pipeline as code, then it will be identified early to minimize technical debt.

Tools used in this Article

  • Jenkins
  • Git
  • Groovy Scripting

Jenkins Global Pipelines

To use Jenkins Global Pipelines, there are a couple of things that need to be set up. First, have a running instance of Jenkins. Second, have a source code repository available to your Jenkins master instance (we will use git).

Configure Jenkins Global Pipeline Libraries

Click on the ‘Manage Jenkins’ link to then get to the configuration section of Jenkins.

From the Global Pipeline Libraries section, we can add the name, the default version (which is a branch), leave the checkboxes as they are defaults, and it will load automatically on jobs. Then fill in the Source Code Management section to point to your repository.

 

Jenkins Pipelines Organization

The folder structure of your global pipelines is defined by Jenkins. It can contain, at a minimum, a single directory named vars. In addition, you can have a src directory containing Groovy classes and a resources directory for containing configurations for your pipelines. Here, we will only have a vars directory. Within this folder, static methods can live and be invoked from the Jenkinsfile in your individual jobs.

Using the Jenkins call method for Inversion of Control

It’s possible to just make some files here, make some methods, then invoke these static methods from various locations within your Jenkinsfiles. This can work, but it the long run, you will find that others pipelines begin to get bloated and we lose uniformity. Your Global Pipeline Library may also become difficult to maintain as different Jenkisnfiles start to introduce new use cases and requirements on the Global Pipeline Library. This is where the call method comes into play. By defining the call in our file, we create a new method that’s the same name as the file. To learn about Pipeline Syntax go here.

In this example, we create a DeliveryPipeline.groovy which defines the call method:

def call(Map pipelineParams) {
    pipeline {
        agent {
            node {
                label pipelineParams.nodeLabel
            }
        }

        stages {
            stage('Build and push to Repository') {
                steps {
                    sh 'chmod +x mvnw'
                    sh './mvnw -s .mvn/settings.xml clean package rpm:version deploy:deploy-file -Dbuild.number=.'\
                     + pipelineParams.buildNumber + ' -Dcommitid=.' + pipelineParams.commitId
                }
            }
        }
    }
}

Now we can invoke ‘DeliveryPipeline’ from the Jenkinsfile which lives in the root of each project:

DeliveryPipeline(
	nodeLabel: 'webapps', 
	buildNumber: '${BUILD_NUMBER}', 
	commitId: '${GIT_COMMIT}',
	server: 'example.com',
	artifact: 'landview'
)

For more information on Jenkinsfile click here.

We have abstracted the pipeline away from the developer and thus protected our pipeline interests. It can be used across different builds. In addition, since the method DeliveryPipeline takes a Map of arguments, it’s flexible enough as your pipelines evolve over time.

 

Author:

Ed Briggler

As a passionate software developer, Ed can be found most days trying to better the world through technology. He loves spending time with family and playing guitar.

Leave a Reply

avatar
  Subscribe  
Notify of