持续集成详解

持续集成支持迭代软件开发，降低缺陷风险并提高开发人员的工作效率。

什么是持续集成？

持续集成 (CI) 是一种软件开发实践，开发人员每天多次将更改合并到主分支。每次合并都会触发自动化代码构建和测试序列，理想情况下运行时间不超过 10 分钟。成功的 CI 构建可以引领持续交付的进一步发展。

如果构建失败，CI 系统会阻止其进入后续阶段。团队会收到报告并快速修复构建，通常在几分钟内即可完成。

如今，所有竞争激烈的科技公司都践行持续集成。通过小规模迭代，软件开发流程变得可预测且可靠。开发人员可以迭代构建新功能。产品经理可以更快地将合适的产品推向市场。开发人员可以快速修复错误，并且通常在错误到达用户手中之前就发现它们。

持续集成要求所有参与项目的开发人员都致力于此。开发结果需要透明地向所有团队成员公开，并在开发人员修改代码时向他们报告构建状态。如果主代码分支构建失败或测试失败，通常会向整个开发团队发出警报，并要求他们立即采取措施，使代码恢复到“绿色”状态。

为什么我们需要持续集成？

在商业领域，尤其是在新产品开发中，我们通常无法预先规划好一切。采取较小的步骤有助于我们更准确地估算并更频繁地验证。更短的反馈循环意味着更多的迭代。而推动学习的是迭代的次数，而不是投入的时间。

对于软件开发团队来说，在长反馈循环中工作是有风险的，因为它增加了出错的可能性以及将更改集成到工作版本软件所需的工作量。

小型、可控的变更可以安全地频繁进行。通过自动化所有集成步骤，开发人员可以避免重复性工作和人为错误。CI 工具无需人工决定何时以及如何运行测试，而是监控中央代码存储库，并在每次提交时运行所有自动化测试。根据测试的总体结果，CI 工具决定接受或拒绝代码提交。

持续交付扩展

一旦我们实现了软件的自动化构建和测试，发布就变得更容易了。因此，持续集成通常会扩展为持续交付，这是一个代码更改也会自动为发布做好准备的过程（CI/CD）。

在精细调整的 CI/CD 流程中，所有代码更改在 CI 阶段完成后都将部署到暂存环境、生产环境或两者。

持续交付可以是一个完全自动化的工作流程。在这种情况下，它通常被称为持续部署。或者，它可以在关键点通过手动步骤实现部分自动化。这两种场景的共同点是，开发人员始终拥有来自 CI 阶段的发布工件，该工件已经过标准化测试流程，可以随时部署。

CI 和 CD 管道

CI 和 CD 通常表示为一个管道，新代码从一端进入，经过一系列阶段（构建、测试、暂存、生产），然后作为新的生产版本在另一端发布给最终用户。

CI/CD 流水线的每个阶段都是交付过程中的一个逻辑单元。开发人员通常将每个单元划分为一系列顺序或并行运行的子单元。

我在 dev.to 上分享了有关 CI/CD 管道的更详细的帖子：

CI/CD 管道：简单介绍

Marko Anastasov ・ 19年5月8日

#cicd #devops #生产力 #初学者

进行持续集成的先决条件

实施持续集成的基本前提条件包括：

• 自动化构建；
• 自动化测试；
• 更频繁地提交到单个源代码存储库，并且
• 为团队提供流程可见性和 CI 状态的实时访问。

尚未实践 CI 的团队应该采取小步骤，不断改进，并以有助于组织成长的方式迭代代码和流程。

在迈向全面 CI/CD 的每一步中，开发团队的生产力都会提高，整个业务的速度也会提高。

典型的开发工作流程

您可以在大多数软件项目中应用持续集成，包括 Web 应用程序、云原生微服务、移动应用程序、系统软件、物联网/嵌入式系统等。

例如，Semaphore与 GitHub 集成，将 CI/CD 引入基于标准拉取请求的开发流程。

以下是 Semaphore 用户日常实践的典型持续集成工作流程：

• 开发人员在 GitHub 中创建一个新的代码分支，对代码进行更改并提交。
• 当开发人员将她的工作推送到 GitHub 时，Semaphore 会构建代码，然后运行自动化测试套件。
• 如果 Semaphore 在 CI 管道中检测到任何错误（状态：红色），开发人员会收到 Slack 通知或在 Semaphore 上的个人仪表板上看到一条消息。
  • 如果开发人员打开了拉取请求，Semaphore 还会在 GitHub 上的拉取请求页面上报告 CI 状态。
• 否则，用户会收到 CI 已通过的通知（状态为绿色）。Semaphore 会自动启动下一个流水线，将应用程序的新版本部署到暂存服务器。这允许 QA 或团队中的任何其他人员在类似生产的环境中测试更改。
• 一旦另一位开发人员在同行评审中验证了更改，作者就可以将新的代码分支合并到主分支中。
• Semaphore 在主分支上运行另一个构建和测试流水线，测试通过后，它会将新版本的代码部署到生产环境中。团队会通过 Slack 收到新版本的通知。

持续集成最佳实践

将主版本视为随时准备发布的版本。这意味着一些团队范围内的禁忌：

• 不要注释掉失败的测试。请提交问题并修复它们。
• 不要对损坏的构建进行签入，也不要对损坏的构建进行回家。

保持快速构建：最多10分钟。速度慢一点是好的，但无法实现足够快的反馈循环。

并行化测试。首先按类型（例如单元测试和集成测试）进行拆分，然后采用可以并行化每个测试的工具。

要求所有开发人员每天至少向 master 分支提交 10 次代码。避免长期运行的功能分支，以免造成大规模合并。以迭代方式构建新功能，并使用功能开关向最终用户隐藏正在进行的工作。

等待测试通过后再提交拉取请求。请记住，拉取请求的定义是请求其他开发人员审查你的代码。请注意他们的时间。

在生产环境的克隆版本中进行测试。例如，您可以使用 Docker 镜像定义您的 CI 环境，并使该 CI 环境 100% 与生产环境匹配。另一种方法是自定义 CI 环境，这样几乎不会发生因与生产环境的差异而导致的 bug。

使用 CI 维护您的代码。例如，运行计划的工作流程来检测库的较新版本并进行升级。

跟踪关键指标：总 CI 构建时间（包括排队时间，您的 CI 工具应将其维持为零）以及您的主控红色的频率。

你觉得这篇文章有用吗？请在下方点赞 ❤️ 或 🦄 告诉我！

接下来你想学习哪些关于 CI/CD 的知识？请在评论区留言告诉我。

谢谢阅读。🙏