部署
大多数最基本的持续交付 Pipeline 至少会有三个阶段:构建、测试和部署,这些阶段被定义在 Jenkinsfile
中。这一小节我们将主要关注部署阶段,但应该指出稳定的构建和测试阶段是任何部署活动的重要前提。
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building'
}
}
stage('Test') {
steps {
echo 'Testing'
}
}
stage('Deploy') {
steps {
echo 'Deploying'
}
}
}
}
Toggle Scripted Pipeline(Advanced)
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
脚本所运行的冒烟测试足以保证或者验证可以发布到生产环境。这种可以自动部署代码一直到生产环境的 Pipeline 可以认为是“持续部署”的一种实现。虽然这是一个伟大的想法,但是有很多理由表明“持续部署”不是一种很好的实践,即便如此,这种方式仍然可以享有“持续交付”带来的好处。[1]Jenkins Pipeline可以很容易支持两者。
人工确认
通常在阶段之间,特别是不同环境阶段之间,您可能需要人工确认是否可以继续运行。例如,判断应用程序是否在一个足够好的状态可以进入到生产环境阶段。这可以使用 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'
}
}
}
}
Toggle Scripted Pipeline(Advanced)
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 Pipeline 的基本使用。由于 Jenkins 是非常容易扩展的,它可以被修改和配置去处理任何类型的自动化。关于 Jenkins 可以做什么的更多相关信息,可以参考用户手册,Jenkins 最新事件、教程和更新可以访问Jenkins 博客