Jenkins Pipeline - methods to define Jenkins pipeline

I'm using a sample GitHub repository to explain the software build

GitHub Repository: https://github.com/rrajaravi/anyserv

Let us look at the Jenkins Pipeline definition for continuous delivery of the software anyserv

A continuous delivery pipeline is an automated expression of your process for getting software from version control right through to your users and customers.

There are several ways to define Jenkins Pipeline, totally three methods are explained below:

• Creating pipeline entirely through Jenkins UI
• In this method, the pipeline is created via Jenkins UI, the code to build software (pipeline script) also provided in the UI itself 

• Defining Jenkins Pipeline as a Code using Groovy language
• In this method, the pipeline script to build software is checked into project source control repository, hence making the pipeline script also version controlled

• Defining Jenkins Pipeline as a declarative statements
• In this method, the pipeline script is written as declarative statement in a text file usually named as Jenkinsfile. The Jenkinsfile checked into project source control repository, hence it is version controlled

The last two methods are good as the pipeline definition is checked into a project’s source control repository and resides along with the software.

• It makes easier for developers to change the pipeline script according to the newer changes introduces in the software
• The pipeline definition is portable to different Jenkins systems as the pipeline script is available along with the software rather than with in a Jenkins system
• The pipeline definition is version controlled

In this example, defining Jenkins Pipeline as a declarative statement has been used

URL to the Jenkinsfile containing the declarative Jenkins Pipeline:
https://github.com/rrajaravi/anyserv/blob/master/Jenkinsfile

Content of the Jenkinsfile:

pipeline {
    agent {
        docker {
            image 'python:3.5.1'
        }
    }
    stages {
        stage('build') {
            steps {
                sh 'python --version'
            }
        }
        stage('package') {
            steps {
                sh '''
                echo $PWD
                ls -ltrh
                zip ${JOB_NAME}.zip -r .
                '''
            }
        }
    }
    post {
        success {
            archiveArtifacts artifacts: '${JOB_NAME}.zip', fingerprint: true
        }
    }
}

Agent Section:

agent section mentions the agent being used for this pipe line. docker agent is being used with docker image of python:3.5.1. This is nothing but the pipeline environment. All the commands executed part of the defined stages get executed with in this environment.

Advantage of using docker agent is that the host operating system need not be installed with Python version 3.5.1 and any other software's needed by the pipeline. Rather the docker container with the defined docker image (having Python 3.5.1) will be spin off by this pipe line and the container would have all other required software's by the pipeline.

Using docker agent provides convenient as it spin off the docker image containing all the pipeline dependencies to execute the pipeline, thus the environment can be portable to any other system running with docker engine. It also keeps the host operating system clean by not bloating with the pipeline requirements.

A pipeline can have multiple stages and it can have post actions defined such as actions that needs to be executed when the pipeline success or failure or always..etc.

Stages:

As per the above example Jenkinsfile, there are two stages:

• build

It just execute a command to print python version. In this case, the python version would be Python 3.5.1 as the pipeline uses the respective docker image

• package 

In this stage, there are commands executed to print the present working directory, list the directory, then finally it compresses the current directory files - (anyserv) repository files and creates a zip file

Post section:

The post section allows to execute commands necessary for the each build state. For example, always post section can be defined with a clean up steps needs to be performed after build execution and no matter whether the build is success or failure.  

As per the above example Jenkinsfile, post section has success call defined with archiveArtifacts

statement to make the software package developed part of package stage be available to download for users via Jenkins UI. So any users can login to Jenkins and download the software package from a successful build of this pipeline.

You can choose a suitable method from the three methods discussed above to define your Jenkins Pipeline