Jenkins 管道
在前面的章节中, 我们成功地涵盖了以下主题:
- 在不同环境中安装和设置Jenkins
- 管理和保护 Jenkins 一旦安装在我们的环境中
- 创建自由式项目并自定义带有视图的 Jenkins 界面
- 使用参数化项目和生成触发器
在本章中, 我们将开始探索 Jenkins 的新功能, 并构建一个完整的管道, 以展示 CI 和自动化的强大功能.
到本章结束时, 您将能够:
- 确定能够实现 CI 并轻松集成到 Jenkins 中的 Git 工作流
- 演示具有多个分支的版本控制项目, 并将其构建在 Jenkins 上
- 演示如何使用声明性 Jenkins 管道并将管道添加到版本控制
The CI Workflow
在讨论 CI 工作流之前, 快速了解 Jenkins 中管道的更基本概念非常重要。管道一词是指将某物 (比如耗材) 从一个点移动到另一个点的机制或系统。在软件开发的背景下, 我们指的是将应用程序从开发到最终用户.
持续集成和交付管道可帮助软件开发将代码从开发迁移到不同的环境 (如暂存和生产)。管道为交付软件提供了快速、可重复和一致的过程。虽然管道因产品和方案而异, 但在每个管道上都有一些重要的通用步骤。CI 管道中的步骤取决于您正在运行的项目类型, 但在较高的级别上, 涉及到从源代码管理中提取代码、准备测试环境和运行测试。下文简要提到了这些问题:
Pulling Code from Source Control: 这里的期望是, 您有一个中央存储库, 每个开发人员都会定期在其中签入代码。管道配置为从一个集中的存储库主机 (如 GitHub 或 Bitbb) 提取最新的更改.
Preparing the Application Environment: 根据应用程序的不同, 此步骤是可选的, 但现在大多数应用程序都依赖于在运行应用程序之前必须安装的依赖项。例如, Python 应用程序可能需要 pip 包, 或者 node. js 应用程序可能有一些 npm 依赖关系.
Testing: 正如前面几章中所提到的, 测试驱动开发是持续集成的巨大推动因素;因此, 测试是管道中更重要的阶段之一。此阶段将运行应用程序中的所有测试, 并确保它们通过.
Building: 根据应用程序的交付方式或使用的编程语言, 此步骤可能具有不同的配置, 但此处的结果是生成工件。生成项目是应用程序的可移动文件。如果您使用的是 JAVA, 则项目可能是 jar 文件, 如果您使用的是 Docker, 则生成项目将是 Docker 映像.
Deployment: 根据设置的不同, 管道可能会继续部署应用程序, 或者等待团队成员的一些手动输入来部署应用程序.
请记住持续交付和持续部署之间的区别。持续集成本质上是在有人将代码推送到源存储库 (如 GitHub) 后立即在非开发人员系统上执行测试的做法。这种做法可帮助团队成员以这样一种方式集成他们的工作, 即通过自动生成对其进行验证, 以尽快识别错误。这将加快部署到生产环境.
本部分将进一步介绍这些知识, 并介绍一个分支工作流, 帮助您设置 CI 管道.
Git Branches
从官方的 Git 文档中, 术语分支被定义为指向提交的轻量级可移动指针。默认情况下, Git 中的主分支称为 master, 理想情况下, 此分支应该具有准备发布的最稳定的代码库。由于许多开发人员在处理项目时, 理想的工作流如下: 一个分支关闭主服务器 (因此是术语分支), 进行所需的更改, 例如添加功能和修复 bug, 然后, 在完成这些更改后, 他们提交这些更改并请求合并回到主分支, 在 GitHub 上被称为提出拉请求 (PR) 的过程。
回到我们对分支的定义, 我们可以看到, 在这样做的时候, 我们将此提交指针移动到主分支之外, 以免破坏我们的代码的稳定, 一旦我们的代码被认为是有价值的或没有错误的, 它就会被合并回来。
分支的最佳类比之一是在时间线上。将分支视为时间线。主时间线是主分支。创建分支时, 我们将从主时间线创建一个新的时间线, 并对代码库执行更改。当我们想要合并回主时间线时, 我们请求合并, 如果我们的更改没有引入任何错误或错误, 则允许合并。
对于前面的一些点 (如代码质量和代码覆盖率报告), 有软件即服务产品, 如 Codacy。虽然其中一些功能是内置到其他语言中的, 但 Golang 在该语言中内置了测试覆盖功能, 不需要第三方工具。
我们可以可视化我们的工作流程, 如下图所示:
Setting up our Repository
在本节中, 我们将设置我们的中央存储库, 并在将工作流合并到管道之前对其有一个感觉。本章假定您拥有 GitHub 帐户。请确保从 https://git-scm.com/downloads 下载并安装 Git, 然后再继续。任何最近发布的 Git 版本都应该有效。若要设置 GitHub 存储库, 请按照下列步骤操作:
- Navigate to https://github.com/<your-profile>.
- 在顶部导航栏上, 单击带有加号的下拉列表, 然后选择 "新建存储库", 如下面的屏幕截图所示:
Creating a GitHub Repository and Integrating Jenkins
假设您的任务是设置一个新的 GitHub 存储库并添加 Jenkins 服务集成 (您可以使用本节前面提供的相同代码文件)。确保您已启动并运行 Jenkins, 并且您已通过身份验证为管理员。要通过将 Jenkins 与 GitHub 存储库集成来创建管道项目, 请按照下列步骤操作:
- 转到 GitHub 仪表板并创建新的存储库.
- 在存储库配置页上, 使用 README 文件初始化项目.
- 在本地创建一个文件夹, 并使用 git init 命令对其进行初始化.
- 添加一个远程命名的原点, 并将其指向您刚刚创建的 GitHub 存储库.
- 将更改从远程存储库拉到本地存储库.
- 签出一个名为加载项代码文件的新分支。在此分支下将提供的代码示例添加到项目中, 并将更改推送到远程存储库.
- 创建从新分支到 master 的基本分支的拉请求.
- 转到存储库设置并添加 Jenkins github 插件集成。这是在设置-> 网络挂钩.
- 点击顶部的 "添加网络钩子" 按钮。这将为您提供以下形式:
对于有效负载 URL, 输入托管的 Jenkins 实例的 DNS 条目, 然后输入/github-webhokn/, 例如, http://your-jenkins-url/github-webhook/。保留窗体字段的其余部分, 然后使用 "仅推送" 事件触发 web 钩子。
成功集成詹金斯服务后, 您应该会看到它如下所示。请注意左侧的绿色刻度, 它验证集成是否按预期方式工作。
- Web 钩子配置仅适用于托管的 Jenkins 设置。或者, 您也可以手动启动生成, 具体取决于项目类型:
- 对于管道项目, 转到项目仪表板, 然后从左侧菜单中选择 "立即生成"。
- 对于将在本节的最后一个主题中显示的多分支管道项目, 请从左侧菜单中选择 "立即扫描存储库"。
在下一节中, 我们将在本练习的基础上, 为它创建一个管道与Jenkins。
The Jenkinsfile
Jenkins中的管道是使用名为 Jenkinsfile 的脚本定义的。这提供了更多的自动化, 允许将您的管道视为所有其他应用程序代码, 并可以存储在版本控制中。这为您的团队提供了更多好处, 因为您的管道可以像代码一样进行检查, 管道可以作为单一的真相来源。在本节中, 我们将介绍从 web UI 创建管道的两种方法, 并将其添加到源代码管理中。我们还将学习如何将 Jenkins 配置为从远程存储库中读取。
管道语法可以以两种形式呈现: 声明性和脚本化。声明性语法是编写管道的一种简单而固执己见的方法。脚本化管道是使用 Groovy 构建的, 通常是一种更灵活、更有表现力的方式来创建管道。在选择要使用的型号时, 这一切都取决于您的要求。声明性模型适用于简单的管道, 并且缺少脚本模型提供的大部分灵活性。本章中我们将使用脚本管道。
在上一节中, 我们了解了分支工作流, 它使我们能够充分利用 CI 设置, 并使我们的团队更轻松地在项目上进行协作。在本节中, 我们将为我们的项目创建管道脚本, 并提供运行项目所需的必要步骤。
在使用 Jenkins 脚本管道时, 我们使用标准 Groovy 语法。脚本化管道具有一些执行不同功能的特殊指令。让我们解释我们在管道脚本中看到的每个指令:
以前的清单并非详尽无遗。在 Jankinsfile 中可以使用不同的指令来实现很多事情。有关详尽的清单, 请参阅官方网站: https://jenkins.io/doc/。
此外, 请注意不同类型的管道, 即声明性管道与脚本式管道。这两者都有不同的语法, 它们不兼容。因此, 在查看文档时, 请注意在使用脚本化管道时不要使用声明性语法, 反之亦然。