Continuous Delivery With Jenkins Pipeline

Section 1

Jenkins Pipeline

Pipeline adds a powerful set of automation tools to Jenkins. It supports software delivery from simple continuous integration tasks to comprehensive continuous delivery pipelines. The steps to build, test, and deliver each application become part of the application itself, stored in a Jenkinsfile.

The Jenkins Pipeline provides a domain-specific language to create, edit, view, and run software delivery pipelines. Users of all experience levels can quickly create Jenkins Pipelines using interactive tools included with Jenkins.

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 2

Jenkins Pipeline Visualization

Jenkins Pipelines are best visualized through the Jenkins Blue Ocean user interface. The Jenkins Blue Ocean user interface is focused on continuous delivery pipelines and the expectations of modern development tools. With a simple click, users can switch between traditional Jenkins pages for administrative tasks and Blue Ocean to edit, monitor, and run their pipelines.

With the focus on new users and continuous delivery, Blue Ocean and Declarative Pipeline are designed to work together. They make the creation, review, and visualization of Pipelines accessible to all members of the DevOps team. Users can quickly see pipeline status, visually create and edit new Pipelines, and personalize their view of important Pipelines. They can easily collaborate on code changes with native integrations for branches and pull requests.

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 3

System Requirements

Declarative Pipeline and Blue Ocean are available with all Jenkins 2.x versions. This Refcard is known to work with:

Jenkins 2.204.5 or higher
Pipeline 2.6 or higher
Blue Ocean 1.22 or higher

To start a new Jenkins with Pipeline and Blue Ocean preinstalled:

Ensure Docker is installed
Run docker run -p 8888:8080 jenkinsci/ blueocean:latest
Browse to http://localhost:8888/blue

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 4

Creating a Jenkinsfile

The "Create Pipeline" experience in Blue Ocean helps users create a new Pipeline in clear, easy steps.

Figure 2: Creating a Pipeline

Pipeline Editor

The Blue Ocean Pipeline Editor allows users to quickly design and save a new Jenkinsfile in the selected repository. If a Jenkinsfile already exists in the repository, it will create a new Pipeline based on the existing Jenkinsfile instead. You can always edit this Jenkinsfile in the editor by selecting a branch and clicking on the pencil icon.

Branches and Pull Requests

When a new Pipeline is created in Blue Ocean, it also creates a new Multibranch Pipeline project for the repository. Jenkins monitors this repository and automatically creates a new Pipeline for each branch and pull request that contains a Jenkinsfile. Removing the branch, pull request, or Jenkinsfile will automatically remove the associated Pipeline.

Declarative Pipelines can adjust their execution based on a branch or pull request; adapt their execution based on user input; and publish test results and save artifacts.

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 5

Pipeline Fundamentals

Pipelines use the definition in the Jenkinsfile to check out code on an agent and run the defined stages and steps. All Declarative Pipelines must start with pipeline and include these four directives to be syntactically correct: agent, stages, stage, and steps. These will be described in further detail in the following sections. Here is an example of a minimal Pipeline:

    Java
   
xxxxxxxxxx

pipeline {
  agent any
    stages {
        stage('Build') {
            steps {
                sh 'npm -version'
            }
        }
    }
}

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 6

Steps and Stages

Steps

Pipelines are composed of multiple steps to build, test, and deploy applications. Think of a “step” as a single command that performs a single action. When a step succeeds, it moves onto the next step.

    Java
   
x

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        sh 'echo "Hello World"'
        sh '''
            echo "Multiline shell steps"
            ls -lah
            '''
            }
        }
    }
}

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 7

Agents

The agent directive tells Jenkins where to execute the Pipeline stage. Most Pipeline steps require an appropriately configured agent.

So far, all examples have used agent any, which allows the Pipeline stage to execute on any available agent. Underneath the hood, there are a few things the agent keyword causes to happen:

All the steps contained within the block are queued for execution by Jenkins. As soon as an executor is available, the steps will begin to execute.
A workspace is allocated which will contain files checked out from source control, as well as any additional working files for the Pipeline.

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 8

Environmental Variables and Credentials

Environment variables can be set globally, like the example below, or per stage. As you might expect, setting environment variables per stage means they will only apply to the stage in which they’re defined.

    Java
   
xxxxxxxxxx

pipeline {
    agent any
    environment {
        DISABLE_AUTH = 'true'
        DB_ENGINE = 'sqlite'
    }
    stages {
        stage('Build') {
            steps {
                sh 'printenv'
            }
        }
    }
}

Environment variables in the Jenkinsfile can be referenced in build scripts to alter the behavior of the script. A Makefile, an automated test, or a deployment script may use the value of the environment variable for its execution.

Another common use for environment variables is to set or override “dummy” credentials in build or test scripts. Pipeline allows users to quickly and safely access pre-defined credentials without knowing their values and without storing credentials in the Jenkinsfile.

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 9

Post Actions

The entire Pipeline and each Stage may optionally define a post section. This post section of the Pipeline runs at the end of the enclosing Pipeline or Stage. It is useful for removing files, archiving results, or sending notifications. A number of additional conditions blocks are supported within the post section: always, changed, failure, success, and unstable. They are executed at the end of a stage depending upon the status of the stage.

    Java
   
xxxxxxxxxx

pipeline {
    agent any
    stages {
        stage('No-op') {
            steps {
                sh 'ls'
            }
        }
    }
    post {
        always {
            echo 'Finished'
            deleteDir() // Clean the workspace
        }
        success {
            echo 'I succeeded!'
        }
        unstable {
            echo 'I am unstable :/'
        }
        failure {
            echo 'I failed :('
        }
        changed {
            echo 'Latest job status differs from previous job status'
job status'
        }
    }
}

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 10

Input

Often, when passing between stages, especially environment stages, you may want human input before continuing. For example, to judge if the application is in a good enough state to “promote” to the production environment, this can be accomplished with the input step. In the example below, the “Sanity check” stage blocks for input and won’t proceed without a person confirming the progress. The input step does not require an agent. It should always be run from a stage using agent none so that it does not reserve an agent unnecessarily.

    Java
   
xxxxxxxxxx

stage('Sanity Check') { 
    agent none 
    steps { 
        input 'Does the staging environment look ok?' 
    } 
}

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 11

Advanced Pipeline Settings

Refer to the Tutorials and Jenkins Handbook at jenkins.io/doc for more information on advanced topics such as Snippet Generator, Declarative Directive Generator, Shared Libraries, Script Blocks, Pipeline Options, and Parameterized Pipelines.

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 12

Additional Resources

This is a preview of the Continuous Delivery With Jenkins Pipeline Refcard. To read the entire Refcard, please download the PDF from the link above.