Pipeline as Code

Learn how to create pipelines as code in Jenkins

Pipeline

One of the key ideas of DevOps is infrastructure-as-code which is the management of infrastructure in a descriptive model using the same versioning control that is used for source code.

Infrastructure as Code enables DevOps teams to test applications in production-like environments early in the development cycle

Pipelines as code is a technique that emphasises on the configuration of delivery pipelines that build, test and deploy applications or infrastructure should be treated as code; they should be kept under source control and modularised in reusable components with automated testing and deployment.

Jenkins Pipeline

Jenkins Pipeline (or simply “Pipeline”) is a suite of plugins which supports implementing and integrating continuous delivery pipelines into Jenkins. A continuous delivery pipeline is an automated expression of your process for getting software from version control right through to your users and customers.

Jenkins Pipeline provides an extensible set of tools for modeling simple-to-complex delivery pipelines “as code”. The definition of a Jenkins Pipeline is typically written into a text file (called a Jenkinsfile) which in turn is checked into a project’s source control repository.

Types of Jenkins Pipeline
There are two types of Jenkins pipeline code.

• Declarative Pipeline
• Scripted Pipeline

For writing complex pipeline scripts we can use Scripted Pipeline. In this blog we will go through a sample scripted pipeline code which is generic and reusable.

The pipeline script is written in groovy and should be committed into a source control repository.

Jenkins pipeline job is created and the script is referenced in the job like shown below

The job name is given the same name as the application to be built/deployed. This lets the script be generic and can reuse the same script for another component by just creating a new job for a different component.

Pipeline Stages

The build and deploy pipeline stages will look something like this

Following can be the different stages for a pipeline:

• Input Stage — If you wish to request some inputs for the pipeline like credentials for running a prod pipeline or the version number to be deployed or application name and other details.
• Source Repository — In this stage connect to the source repository and checkout the project.
• Compile — Running maven commands to compile the checked out source code.
• Integration Test — Running maven goals for Junits and Cucumber tests
• Sonar Checks — Once the integration tests pass run the sonar checks and upload the details on SonarQube
• Merge Code — Merge the code into development branch using Git Api
• Nexus Upload — Upload the artefact created onto Nexus server
• Deployment — Deploying the jar/artefact onto the deployment server
• Starting the app — Start the application after deploying the jar file by triggering a script on the server or running the shell script in groovy.

If any of the above stage fails, the entire pipeline will fail and not proceed further. This behaviour can be controlled by adding a try catch in each stage if you still want the pipeline to continue in case of a stage failure.

In the input stage you can also give the developer flexibility by providing an option for which stage to run. For example, you may want to skip the deployment while running the pipeline. You can ask user the input for a deployment flag which by default can be true , if the developer wishes deploy later she/he can set the flag as false. Similarly this can be done for any other stages if required. This is achieved by using the input function provided by Jenkins. This helps in building more interactive pipelines.

Input stage once the pipeline is triggered:

Build/Deploy Pipeline Input Stage

You can give the user an option to skip few stages of the pipeline in this step .This gives the user a control what steps to run or skip when the code is still in development phase.

Groovy code for the Input stage

Groovy code for the remaining stages

The job name should be the same as the application project name. This ways the scripts knows which application to checkout from the source control, (check the Input Stage above). This makes the application reusable for any other component.

You can also configure email alerts by using “mail to “ command for any completed stage like Sonar results available or pipeline process completed or failed. Example :

For triggering the pipeline you can add a web hook into Git when a pull request is approved after code review the corresponding pipeline should get triggered.

Accessing the pipeline script

The script should be committed to a source control repository. While creating the job few parameters can be set at the Jenkins job level such as:

• Server name to where the application will be deployed as it may be different for different applications.
• Nexus username and passwords or Git credentials
• Application start scripts if any

After setting the above parameters the pipeline script is referenced by the Jenkins job as shown below :

This script once created can be used by other applications with just a few config parameter changes and the new application build/deploy pipeline job can be created within a few minutes!