如果您正在寻找一个基于拉取请求或分支的自动化 Jenkins 持续集成和交付 (CI/CD) 流水线,本指南将帮助您全面了解如何使用 Jenkins 多分支流水线实现它。
Jenkins 的多分支流水线是设计 CI/CD 工作流的最佳方式之一,因为它完全基于 git(源代码管理)的流水线即代码。本指南将讨论 Jenkins 多分支流水线设置中涉及的所有关键概念。
多分支流水线是如何工作的?
我将带您了解一个基于 git-flow 的基本构建和部署工作流程,以便更好地理解多分支流水线。本例中提供的分支策略仅供参考。
假设我想要一个 Jenkins 流水线来构建和部署一个应用程序,并满足以下条件。
- 应用程序仓库有两个分支(主分支和开发分支)。
- 开发从开发人员分叉应用程序仓库并在分叉的仓库中创建一个分支开始。开发人员将代码提交到功能分支。代码在本地测试完毕并准备好集成后,他们将从分叉的仓库向主仓库的开发分支提交一个 PR。
- 每当开发人员从分叉仓库的功能分支向开发分支提交 PR 时,Jenkins 流水线都会触发合并源分支和目标分支的操作,然后运行单元测试和静态代码分析。我们称之为 PR 构建。
- 代码通过 PR 构建中的测试后,开发人员或审阅者将 PR 合并到开发分支。
- 代码合并到开发分支后,应该触发一个流水线,该流水线将运行相关测试并将代码部署到相关环境(例如,开发、质量保证等)。
- 当代码准备好发布时,开发人员会从开发分支向主分支提交 PR。这将触发一个 PR 构建流水线,该流水线将合并源分支和目标分支、运行单元测试、执行代码分析、构建工件(Docker 镜像、jar 文件等)、进行漏洞测试等。
- 如果测试通过,PR 将被审核并合并到主分支。
- 合并完成后,Jenkins 应该触发一个构建,该构建将编译代码、创建发布工件并将其部署到暂存环境和预生产环境。
从以上情况可以看出,Jenkins 作业无需手动触发,每当有分支的拉取请求时,流水线都需要自动触发并运行该分支所需的步骤。
此工作流程为工程师构建了良好的反馈循环,避免了依赖 DevOps 团队在非生产环境中进行构建和部署。
开发人员可以在 Github 上查看构建状态,并决定下一步操作。
此工作流程可以通过 Jenkins 多分支流水线轻松实现。
下图展示了上述示例构建过程的多分支流水线工作流程。
多分支流水线的工作原理如下。
- 当开发者从 fork 仓库的功能分支创建 PR 以开发分支时,Github 会向 Jenkins 发送一个包含 PR 信息的 Webhook。
- Jenkins 接收 PR 并找到相关的多分支流水线,然后自动创建 PR 构建流水线。然后,它会按照 Jenkinsfile 中提到的步骤运行作业。在签出 (checkout) 期间,PR 中的源分支和目标分支会被合并。PR 合并将在 Github 上被阻止,直到 Jenkins 返回构建状态(如果已配置 Github 规则集)。
- 构建完成后,Jenkins 会将状态更新为 Github PR。现在,您可以合并代码了。如果您想查看 Jenkins 构建日志,可以在 PR 状态中找到 Jenkins 构建状态和日志链接(如果已配置 Github App forJenkins)
首先,在使用多分支流水线之前,我使用了一个简单的流水线,并结合了 GitHub Webhook。
我遇到的问题是,我团队的项目使用 Git 工作流作为开发分支,当我或我的团队推送或合并 PR 时,Webhook 会向我的 Jenkins 流水线发送请求,无论哪个分支,该请求都会立即启动工作。因此,多分支流水线可以帮助解决这个问题。
多分支流水线 Jenkinsfile
在开始实现之前,让我们先看一下可以在流水线中使用的多分支流水线 Jenkins 示例 Jenkinsfile。
要使多分支流水线正常工作,您需要在 SCM 仓库中拥有 Jenkinsfile。
如果您正在学习/测试,可以使用下面提供的多分支流水线 Jenkinsfile。它包含一个检出阶段和其他虚拟阶段,用于回显消息。
注意:将代理标签 agent-01 替换为您的 Jenkins 代理名称。
pipeline {
agent {
node {
label 'agent-01'
}
}
options {
buildDiscarder logRotator(
daysToKeepStr: '16',
numToKeepStr: '10'
)
}
stages {
stage('Cleanup Workspace') {
steps {
cleanWs()
sh """
echo "Cleaned Up Workspace For Project"
"""
}
}
stage('Code Checkout') {
steps {
checkout([
$class: 'GitSCM',
branches: [[name: '*/main']],
userRemoteConfigs: [[url: 'https://github.com/spring-projects/spring-petclinic.git']]
])
}
}
stage('Unit Testing') {
steps {
sh """
echo "Running Unit Tests"
"""
}
}
stage('Code Analysis') {
steps {
sh """
echo "Running Code Analysis"
"""
}
}
stage('Deploy To Dev & QA') {
when {
branch 'develop'
}
steps {
sh """
echo "Building Artifact for Dev Environment"
"""
sh """
echo "Deploying to Dev Environment"
"""
sh """
echo "Deploying to QA Environment"
"""
}
}
stage('Deploy To Staging and Pre-Prod Code') {
when {
branch 'master'
}
steps {
sh """
echo "Building Artifact for Staging and Pre-Prod Environments"
"""
sh """
echo "Deploying to Staging Environment"
"""
sh """
echo "Deploying to Pre-Prod Environment"
"""
}
}
}
}
创建多分支流水线
步骤 1:在 Jenkins 主页创建一个“新项目”。
Jenkins 新项目 - 多分支
步骤 2:从选项中选择“多分支流水线”,然后点击“确定”。
步骤 3:点击“添加源”,然后选择 Github。
步骤 4:在“凭据”字段下,选择 Jenkins,并使用您的 Github 用户名和密码创建凭据。
步骤 5:选择已创建的凭据,并提供您的 Github 仓库以验证凭据,如下所示。验证多分支流水线凭据
步骤 6:在“行为”下,选择符合您需求的选项。您可以选择发现仓库中的所有分支,也可以仅发现包含拉取请求的分支。
您可以从“添加”按钮中选择其他行为。
例如,如果您选择不发现代码库中的所有分支,则可以选择正则表达式或通配符方法来发现代码库中的分支,如下所示。
步骤 7:如果您选择为 Jenkinsfile 设置不同的名称,可以在构建配置中指定。
在“脚本路径”选项中,您可以提供所需的名称。请确保 Jenkinsfile 存在于代码库中,并且名称与您在流水线配置中提供的名称相同。
另外,启用“丢弃旧构建”以仅保留所需的构建日志,如下所示。
步骤 8:保存所有作业配置。
Jenkins 会根据我们的配置扫描已配置的 Github 仓库,查找所有分支和 PR 请求。
下图展示了扫描三个分支的作业。由于我尚未发起任何拉取请求,因此 Jenkins 不会创建任何基于分支的流水线。我将演示如何在设置 Webhook 后测试自动创建流水线。
步骤1: 登录github, 找到repo,点击设置,添加webhook,输入你的jenkins 的URL
您应该会在成功的 Webhook 配置上看到一个绿色勾号,如下所示。Jenkins - Github Webhook 交付成功
如果您没有看到绿色勾号或警告标志,请点击 Webhook 链接,向下滚动到“最近交付”,然后点击最后一个 Webhook。您应该能够通过状态代码查看 Webhook 交付失败的原因。
现在,我们已经完成了多分支流水线所需的所有配置。下一步是测试多分支流水线工作流触发器。
测试多分支流水线
我使用的这个仓库有两个分支:main 和 develop。
更新 develop分支中 README 文件的部分内容,并向 main 提交 PR。您也可以从 fork 的仓库中执行此操作。
它会向 Jenkins 发送一个 Webhook,并为提交的 PR 创建流水线并开始构建。
现在,如果您检查 Jenkins,您会在 Jenkins 中找到一个用于 PR 的流水线,如下所示。
如果构建失败,您可以将更改提交到开发分支,只要 PR 处于打开状态,它就会触发 PR 流水线。
我在 Jenkinfile 中添加了一个条件:如果分支是开发分支,则跳过部署阶段;如果是 PR 构建分支,则跳过主分支。您可以在 Jenkins 构建阶段中检查这一点。如果您检查这些阶段,可以清楚地看到跳过的部署阶段,如下所示。
启用拉取请求状态检查
在多分支流水线中,您可以启用状态检查。这意味着 Jenkins 会将结果以状态检查的形式报告给 GitHub。它会显示在 PR 页面上,如下所示。
例如,开发人员可能需要进行以下状态检查。
常见的状态检查可能包括:
- 构建验证
- 单元测试
- 代码风格检查
- 安全扫描
要在 Github PR 中启用这些状态检查,您需要创建一个适用于 Jenkins 的 Github App。
您可以按照 Github App for Jenkins 详细指南进行创建。
然后在多分支流水线配置中,您需要使用 Github App 凭据,而不是用户名和密码。