Jenkins - 部署

大多数最基本的持续交付 Pipeline 至少会有三个阶段：构建、测试和部署，这些阶段被定义在 Jenkinsfile 中。 这一小节我们将主要关注部署阶段，但应该指出稳定的构建和测试阶段是任何部署活动的重要前提。

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying'
            }
        }
    }
}

阶段即为部署环境

一个常见的模式是扩展阶段的数量以获取额外的部署环境信息， 如 “staging” 或者 “production”，如下例所示。

stage('Deploy - Staging') {
    steps {
        sh './deploy staging'
        sh './run-smoke-tests'
    }
}
stage('Deploy - Production') {
    steps {
        sh './deploy production'
    }
}

在这个示例中，我们假定 ./run-smoke-tests 脚本所运行的冒烟测试足以保证或者验证可以发布到生产环境。 这种可以自动部署代码一直到生产环境的 Pipeline 可以认为是“持续部署”的一种实现。 虽然这是一个伟大的想法，但是有很多理由表明“持续部署”不是一种很好的实践， 即便如此，这种方式仍然可以享有“持续交付”带来的好处。 [1] Jenkins Pipeline可以很容易支持两者。

人工确认

通常在阶段之间，特别是不同环境阶段之间，您可能需要人工确认是否可以继续运行。 例如，判断应用程序是否在一个足够好的状态可以进入到生产环境阶段。 这可以使用 input 步骤完成。 在下面的例子中，“Sanity check” 阶段会等待人工确认，并且在没有人工确认的情况下不会继续执行。

pipeline {
    agent any
    stages {
        /* "Build" and "Test" stages omitted */

        stage('Deploy - Staging') {
            steps {
                sh './deploy staging'
                sh './run-smoke-tests'
            }
        }

        stage('Sanity check') {
            steps {
                input "Does the staging environment look ok?"
            }
        }

        stage('Deploy - Production') {
            steps {
                sh './deploy production'
            }
        }
    }
}