部署
最基本的持续交付管道至少有三个阶段,应该在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博客,了解最新的事件、教程和更新。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。