Deployment

As your pipeline grows to accommodate deployment, you will have multiple stages. You have likely already seen stages in use in some examples:

Multiple stages

<<<<<<< HEAD Adding more stages makes clear what your pipeline is doing.

Adding more stages makes clear what your pipeline is doing.

origin/master

pipeline {
     agent docker:'node'
     stages {
         stage('build') {
             steps {
                 sh 'echo building...'
             }
         }
         stage('test') {
             steps {
                 sh 'echo testing...'
             }
         }
         stage('deploy') {
             steps {
                 retry(3) {
                     sh 'echo deploying...'
                 }
             }
         }
     }
}

<<<<<<< HEAD This is a pipeline of build->test->deploy. The deploy stage, actually retries a script 3 times.

This is a pipeline of build->test->deploy. The deploy stage actually retries a script 3 times.

origin/master

Retrying things, with a timeout, is a pretty common pattern in deployment:

   timeout(time: 3, unit: 'MINUTES') {
       retry(5) {    
           sh 'echo deploying'
       }
   }

<<<<<<< HEAD This gives it 5 chances to get it right, but in 3 minutes (if your app isn't deployed in 3 minutes, it's free!).

This gives it 5 chances to get it right, but in 3 minutes (if your app isn't deployed in 3 minutes), it's free!

origin/master

You can also sleep between steps:

    stage('deploy') {
        steps {
            sh 'echo deploying...'
            sleep 30
            sh 'echo 30 seconds should be long enough'
        }
    }

Default is in seconds.

Stages as deploy environments

One useful way to use stages is to have them represent deployment environments:

pipeline {
     agent any
     stages {
         stage('Build') {
             steps {
                 sh 'echo building...'
             }
         }
         stage('Test') {
             steps {
                 sh 'echo testing...'
             }
         }
         stage('Deploy - Staging') {
             steps {
                 sh 'echo deploying to staging...'
                 sh 'echo smoke tests...'
             }
         }
         stage('Deploy - Production') {
             steps {
                 sh 'echo deploying to production...'
             }
         }
     }
}

The final 2 stages represent staging and production environments. Typically you would want to run some smoke tests before things are promoted to the production environment.

Asking for human input to proceed

<<<<<<< HEAD Often when passing between stages, especially environment stages, you may want a human to judge whether the application is in a good enough state to promote (you can also ask for input parameters too, but I won't show that here):

Often when passing between stages, especially environment stages, you may want a human to judge whether the application is in a good enough state to promote (you can also ask for input parameters too, but I won't show that here):

origin/master

pipeline {
     agent none
     stages {

         stage('Deploy - Staging') {
             agent label:'master'
             steps {
                checkout scm
                sh 'echo deploying $APP_NAME to staging...'
             }             
         }

         stage('Sanity check') {
             steps {
                 input "Does the staging environment for ${env.APP_NAME} look ok?"
             }
         }

         stage('Deploy - Production') {
             agent label:'master'
             steps {
                 sh 'echo deploying $APP_NAME to production'
             }             
         }
     }

     environment {
        APP_NAME = 'my-app'
     }
}

<<<<<<< HEAD In this example, the "Sanity check" stage actually blocks for input and won't proceed without a person allowing it to. You may want to do this as you don't trust your test suite, but don't tell anyone that, it can be our secret.

There are also a few other things going on in the human input example above: i.e. agent none means that is is up to each stage to get its own node to run steps on. This also means that when it is waiting for input from a person, it isn't keeping an agent running (ie it can wait for hours or days, with no harm done).

In this example, the "Sanity check" stage actually blocks for input and won't proceed without a person allowing it to. You may want to do this if you don't trust your test suite, but don't tell anyone that, it can be our secret.

There are also a few other things going on in the human input example above: i.e., agent none means that is is up to each stage to get its own node to run steps on. This also means that when it is waiting for input from a person, it isn't keeping an agent running (i.e., it can wait for hours or days, with no harm done).

origin/master

Deployment targets and techniques

[COMING SOON]