{"id":1288,"date":"2019-09-04T19:48:00","date_gmt":"2019-09-04T14:18:00","guid":{"rendered":"http:\/\/blogs.opstree.com\/?p=1288"},"modified":"2020-02-17T19:58:23","modified_gmt":"2020-02-17T14:28:23","slug":"jenkins-pipeline-global-shared-libraries","status":"publish","type":"post","link":"https:\/\/opstree.com\/blog\/2019\/09\/04\/jenkins-pipeline-global-shared-libraries\/","title":{"rendered":"Jenkins Pipeline Global Shared Libraries"},"content":{"rendered":"\n
\"\"<\/a><\/figure>\n\n\n\n

When we say CI\/CD as code, it should have modularity and reusability which results in Reducing integration problems and allowing you to deliver software more rapidly.<\/p>\n\n\n\n

Jenkins\u00a0Shared library is the concept of having a common pipeline code in the version control system that can be used by any number of pipelines just by referencing it. In fact, multiple teams can use the same library for their pipelines.

Our thought is putting all pipeline functions in vars is much more practical approach, while there is no other good way to do inheritance, we wanted to use Jenkins Pipelines the right way but it has turned out to be far more practical\u00a0to use vars for global functions.<\/p>\n\n\n\n

Practical Strategy
As we know Jenkins Pipeline’s shared library support allows us to define and develop a set of shared pipeline helpers in this repository and provides a straightforward way of using those functions in a Jenkinsfile.This simple example will just illustrate how you can provide input to a pipeline with a simple YAML file so you can centralize all of your pipelines into one library. The Jenkins shared library example:And the example app that uses it:<\/p>\n\n\n\n

Directory Structure<\/h2>\n\n\n\n

You would have the following folder structure in a git repo:
<\/p>\n\n\n\n

\u2514\u2500\u2500 vars\n    \u251c\u2500\u2500 opstreePipeline.groovy\n    \u251c\u2500\u2500 opstreeStatefulPipeline.groovy\n    \u251c\u2500\u2500 opstreeStubsPipeline.groovy\n    \u2514\u2500\u2500 pipelineConfig.groovy\n<\/pre>\n\n\n\n
Setting up Library in Jenkins Console.<\/h2>\n\n\n\n
This repo would be configured in under Manage Jenkins<\/em> > Configure System<\/em> in the Global Pipeline Libraries<\/em> section. In that section Jenkins requires you give this library a Name. Example opstree-library<\/p>\n\n\n\n
<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
<\/p>\n\n\n\n
Pipeline.yaml<\/h2>\n\n\n\n
Let\u2019s assume that project repository would have a pipeline.yaml file in the project root that would provide input to the pipeline:Pipeline.yaml<\/strong><\/p>\n\n\n\n
ENVIRONMENT_NAME: test\nSERVICE_NAME: opstree-service\nDB_PORT: 3079\nREDIS_PORT: 6079<\/pre>\n\n\n\n
Jenkinsfile<\/h2>\n\n\n\n
Then, to utilize the shared pipeline library, the Jenkinsfile in the root of the project repo would look like:<\/p>\n\n\n\n
@Library ('opstree-library@master') _\nopstreePipeline()<\/pre>\n\n\n\n
PipelineConfig.groovy<\/h2>\n\n\n\n
So how does it all work? First, the following function is called to get all of the configuration data from the pipeline.yaml file:
<\/p>\n\n\n\n
def call() {\n  Map pipelineConfig = readYaml(file: \"${WORKSPACE}\/pipeline.yaml\")\n  return pipelineConfig\n}<\/pre>\n\n\n\n
opstreePipeline.groovy<\/h2>\n\n\n\n
You can see the call to this function in opstreePipeline(), which is called by the Jenkinsfile.
<\/p>\n\n\n\n
def call() {\n    node('Slave1') {\n\n        stage('Checkout') {\n            checkout scm\n        }\n\n         def p = pipelineConfig()\n\n        stage('Prerequistes'){\n            serviceName = sh (\n                    script: \"echo ${p.SERVICE_NAME}|cut -d '-' -f 1\",\n                    returnStdout: true\n                ).trim()\n        }\n\n        stage('Build & Test') {\n                sh \"mvn --version\"\n                sh \"mvn -Ddb_port=${p.DB_PORT} -Dredis_port=${p.REDIS_PORT} clean install\"\n        }\n\n        stage ('Push Docker Image') {\n            docker.withRegistry('https:\/\/registry-opstree.com', 'dockerhub') {\n                sh \"docker build -t opstree\/${p.SERVICE_NAME}:${BUILD_NUMBER} .\"\n                sh \"docker push opstree\/${p.SERVICE_NAME}:${BUILD_NUMBER}\"\n            }\n        }\n\n        stage ('Deploy') {\n            echo \"We are going to deploy ${p.SERVICE_NAME}\"\n            sh \"kubectl set image deployment\/${p.SERVICE_NAME} ${p.SERVICE_NAME}=opstree\/${p.SERVICE_NAME}:${BUILD_NUMBER} \"\n            sh \"kubectl rollout status deployment\/${p.SERVICE_NAME} -n ${p.ENVIRONMENT_NAME} \"\n\n    }\n}<\/pre>\n\n\n\n
You can see the logic easily here. The pipeline is checking if the developer wants to deploy on which environment what db_port needs to be there.<\/p>\n\n\n\n
Benefits<\/h2>\n\n\n\n
The benefits of this approach are many, some of them are as mentioned below:<\/p>\n\n\n\n