什么是 CI/CD？它如何帮助我们更快地发布？它值得麻烦吗？在本期文章中，我们将研究持续集成和持续部署，简称 CI/CD。CI/CD 帮助自动化软件开发过程，从初始代码提交到部署。它消除了传统上将代码发布到生产所需的大量人工干预。
CI/CD 流程构建、测试和部署代码到生产。承诺是它使软件团队能够更快地部署更高质量的软件。这听起来都很好，但它在现实生活中有效吗？答案是——视情况而定。
让我们将 CI/CD 分解为它们的部分并分别讨论它们。
持续集成（CI）
持续集成（CI）是一种开发实践，许多人认为他们在工作中使用它，但他们并没有完全理解它。
在 CI 出现之前，开发团队通常在孤岛中运作，单个开发者独立地在不同的功能上工作很长时间。他们的工作最终需要合并到共享代码库中，通常会导致合并冲突和数百个文件及贡献者之间的兼容性问题。这种困境，通常被称为”合并地狱”，代表了传统开发方法面临的困难。
让我们考虑一个有两个开发者 Alice 和 Bob 的场景。Alice 编写她的代码，并一有功能版本就分享，即使它没有完全完成，也不会引起任何问题。她将代码上传到中央仓库。Bob 遵循相同的方法，总是在开始工作之前获取最新版本的代码。随着 Alice 继续更新她的代码，Bob 也这样做。如果 Bob 进行更改，Alice 将这些问题合并到她的作品中，没有任何问题。他们顺利协作，干扰彼此的机会很低，因为他们总是使用最新的代码工作。如果他们遇到冲突，通常是在他们最近都进行的更改上，所以他们可以坐下来一起解决问题，然后继续前进。
然而，有这么多人不断贡献代码，问题不可避免。事情可能不会总是顺利进行，新的错误可能出现。那么，解决方案是什么？
解决方案是自动化。它就像一个警惕的看门狗，不断监控代码。每当发生变化时，它就会行动起来，获取代码、构建它并运行测试。如果在这个过程中有任何失败，团队会收到警报，确保每个人都知道问题。有了这个安全网，持续集成就成为现实。
那么，持续集成（CI）到底是什么？
持续集成涉及自动化构建、执行测试，并将来自单个开发者的代码合并到共享仓库中。持续集成的主要目标是有效地将源代码集成到共享仓库中。一旦更改提交到版本控制系统，就会执行自动化构建和测试用例，以确保代码的功能和有效性。这些过程验证源代码如何编译以及测试用例在执行期间如何执行。
CI 常用工具
- 源代码管理：GitHub（基础）
- CI 流程管理：GitHub Actions、Buildkite（现代）、Jenkins、CircleCI、TravisCI
- 测试工具：Jest（JavaScript 单元测试）、Playwright、Cypress（Web 应用集成测试）
- 构建工具：Gradle（Java）、Webpack（JavaScript）
持续集成有几个重要原因。下表展示了一些 CI 的主要优势。
持续部署（CD）
持续部署（CD）是 CI/CD 管道中 CI 之后的下一步。CD 是自动将通过自动化测试阶段的每个代码更改部署到生产的实践。
虽然真正的持续部署具有挑战性且不如 CI 那样广泛采用，但更常见的做法是持续交付，它类似但有细微差别，如下所述。
持续交付专注于将代码更改快速部署到生产环境。它的根源可以追溯到敏捷宣言，强调”早期和持续交付有价值的软件”以满足客户。
持续交付的目标是有效地将有价值的代码更改过渡到生产。第一步涉及通过构建过程将代码转换为可部署软件。一旦软件准备就绪，下一步似乎是直接将其部署到生产。然而，实际做法涉及严格测试，以确保只有稳定的软件进入生产环境。
通常，组织维护多个测试环境，如”QA”、“性能”或”暂存”。这些环境作为在部署到生产之前验证软件的检查点。软件在每个环境中进行测试，以确保其准备就绪部署。
本质上，持续交付中的生产之旅涉及在各种测试环境之间过渡软件，然后部署到生产环境。
持续交付的一个关键方面是确保代码始终保持可部署状态。一旦交付过程完成，代码就准备好部署到任何所需环境。这个端到端过程包括构建源代码、执行测试用例、生成工件（如 WAR 或 JAR 文件），并将它们交付到特定环境。
回到持续部署（CD），它涉及将代码更改自动部署到生产环境。本质上，CD 代表开发管道中的最后阶段。在这个阶段，不仅准备工件并执行测试用例，而且过程进一步扩展到将工件部署到生产环境。持续部署确保对代码进行的任何更改都立即部署到生产环境，无需人工干预。
持续部署和持续交付是相关概念，但它们有明显的区别。这里，我们列出一些区别：
虽然持续部署可能适合某些组织，但持续交付是许多人努力实现的方法，因为它提供了一种谨慎但自动化的软件交付方法。
我们之前提到的工具，如 GitHub Actions、Buildkite 和 Jenkins，通常用于处理 CD 任务。特定于基础设施的工具也使 CD 更容易维护。例如，ArgoCD 在 Kubernetes 上很流行。
CI/CD 是一种强大的软件开发实践，可以帮助团队更快地发布更高质量的软件。然而，它不是一刀切的解决方案，其实现可能因系统的复杂性而异。
持续部署为组织提供了许多好处。这里，我们列出其中一些。
没有什么比看到我们的代码上线给数百万用户使用更令人满意的了。看到它总是令人兴奋的。但到达那里并不总是容易的。让我们探索一些常见的部署策略。
最早的将更改部署到生产的方法之一是大爆炸部署。想象一下像撕掉创可贴一样。我们一次性推送所有更改，导致一些停机时间，因为我们必须关闭旧系统以开启新系统。停机时间通常很短，但要小心——如果事情没有按计划进行，它可能会刺痛。准备和测试是关键。如果事情出错，我们回滚到以前的版本。然而，回滚并不总是无痛的。我们可能仍然会干扰用户，并且可能有数据影响。我们需要有一个坚实的回滚计划。
本文为学习目的的个人翻译，译文仅供参考。
原文链接：A Crash Course in CI/CD。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。