CloasGao 2019-06-29
最基本的持续交付管道至少有三个阶段,应该在Jenkinsfile
中定义:Build
、Test
和Deploy
,对于本节,我们将主要关注部署阶段,但应注意稳定的构建和测试阶段是任何部署活动的重要前提。
Jenkinsfile (Declarative Pipeline) pipeline { agent any stages { stage('Build') { steps { echo 'Building' } } stage('Test') { steps { echo 'Testing' } } stage('Deploy') { steps { echo 'Deploying' } } } }
脚本管道(高级):
Jenkinsfile (Scripted Pipeline) node { stage('Build') { echo 'Building' } stage('Test') { echo 'Testing' } stage('Deploy') { 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
脚本运行的任何“烟雾测试”都足以对产品环境的发布进行限定或验证,这种自动将代码一直部署到生产的管道可以被视为“持续部署”的实现。虽然这是一个崇高的理想,但对于许多人而言,有充分理由说明为什么持续部署可能不切实际,但仍然可以享受持续交付带来的好处,Jenkins管道很容易同时支持这两种方法。
通常在阶段之间传递,特别是环境阶段,你可能需要在继续之前人工输入,例如,判断应用程序是否处于足够好的状态以“促进”生产环境,这可以通过input
步骤完成。在下面的示例中,“Sanity check”阶段实际上阻塞了输入,并且在没有人确认进度的情况下不会进行。
Jenkinsfile (Declarative Pipeline) 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' } } } }
脚本管道(高级):
Jenkinsfile (Scripted Pipeline) node { /* "Build" and "Test" stages omitted */ stage('Deploy - Staging') { sh './deploy staging' sh './run-smoke-tests' } stage('Sanity check') { input "Does the staging environment look ok?" } stage('Deploy - Production') { sh './deploy production' } }
本指南向你介绍了使用Jenkins和Jenkins管道的基础知识,由于Jenkins具有极高的可扩展性,因此可以对其进行修改和配置,以处理几乎任何自动化方面,要了解有关Jenkins可以执行的操作的更多信息,请查看用户手册或Jenkins博客,了解最新的事件、教程和更新。