CI/CD 实施：5 个常见错误以及如何避免它们

在技术行业，你可能已经注意到软件开发方法正在向流程自动化和 DevOps 实践转变。

根据2020 年 DevOps 趋势调查，99% 使用 DevOps 并实施 CI/CD 流水线的公司都取得了重大改进，例如更快的发布周期和更高的软件质量。然而，根据同一份报告，85% 的团队在实施 DevOps 实践的早期存在困难。

大约四年前，我们的团队开始转向 CI/CD 方法。目前, 我们已经从团队合作和业务成果的持续改进中获益，但一开始，我们和大多数团队一样，面临着挫折和障碍，这让我们怀疑是否需要 CI/CD。

今天，我们已经克服了这些困难，并在大多数项目中成功地使用了 CI/CD。根据以往的经验，让我们探索这种方法的好处，以及最常见的错误和如何避免它们。

为什么要转向 CI/CD？

CI/CD（持续集成和持续交付）方法基于短而快速的迭代，以最大限度地减少错误、加快开发过程并提高产品质量。

下面的信息图显示了 CI/CD 流水线的工作原理。

转向 CI/CD，团队获得以下好处：

1. 由于减少了人为因素，并且验证阶段是自动化的，因此增加了流程的可靠性。
2. 支持发布小块功能，使团队能够首先发布重要的东西。
3. 减少频繁发布对 QA 团队的压力。
4. 降低同一项目中跨团队发布的复杂性。自动化有助于避免多个团队工作中的潜在冲突，并在出现冲突时提供工具。
5. 提高重新发布的安全性。
6. 提高所有发布过程中出现问题的可见性，并且会自动在正确的时间将问题通知正确的人。

接下来，让我们谈一谈软件工程团队在实施 CI/CD 流水线时可能会面临哪些问题。

使用 CI/CD 的 5 个错误以及如何避免它们

尽管 CI/CD具有优势，但 它是一个相当复杂的多步骤过程。这些步骤中的每一个都可能带来困难和障碍。以下是迁移到 CI/CD 的团队最常遇到的五个主要错误。

1. 在不稳定 的CI 上构建 CD

要构建 CD，你需要有一个已存在于项目中的可靠 CI 流。这样，你将确保：

• 每个释放单元不破坏系统性能；
• 构建应用程序的过程非常自动化且可重复（即重新构建相同的代码将导致完全相同的结果）。

如果你不确定这些要点，请做好应对故障的准备， 如CD 流程中断等。

如何避免： 确保 CI 流程的所有阶段都得到实施，团队对 CI 工作的结果有信心。例如，编译并通过测试的代码。

2. 自动化带来的高成本和潜在风险

在自动化流程时，考虑自动化成本与将获得的收益的比率至关重要。

让我们看一个例子：

我们有一个项目，每两周发布一次更新版本。为了使其自动化，QA 团队需要花费两个月的时间编写自动测试（手动测试，耗时不超过四个小时）。很明显，这样的自动化过程回报率很低。

相反，如果团队的目标是不断致力于减少代码交付时间，那么 CD 可以显著地节省 QA 团队的时间，并保证应用程序可靠性的增加。

如何避免： 在开始 实施CI/CD之前，我们需要认真地分析自动化的收益和成本。

这里有一些问题可以帮助你进行评估：

1. 这个过程多久重复一次？
2. 花费多长时间？
3. 需要多少人力和资源？
4. 缺乏自动化会导致流程出错吗？
5. 为什么这个过程现在需要自动化？

根据答案，确定此过程需要自动化的紧迫程度，以及是否需要自动化。

如果项目当前不需要完整的 CI/CD 流程，那么考虑迭代实施 CI/CD 的可能性很重要，但各个阶段的自动化将有助于解决紧迫的问题。此外，你可以只自动化产品的一部分：例如，在后端实现 CI/CD，而无需涉及移动应用程序。

3. 将持续部署等同于持续交付

持续部署是将代码库中的任何更改都应该自动且快速地投入生产环境。

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。

持续部署（continuous deployment）则是持续交付的下一步，代码通过评审，自动化部署到生产环境。其目的是可以随时部署，迅速投入生产阶段。持续部署这一步，意味着产品和观众见面，但是要通过重重考验，测试、构建、部署等步骤，而且每一步都是自动的。

持续部署是一种独立的机制，是持续交付的附加组件，不会取代它。在实施 CI/CD 过程时，将持续部署视为每个特定项目中可能需要也可能不需要的单独功能。

如何避免： 如果你决定使用持续部署，请提前准备你的项目，以避免影响用户体验。当应用程序更新对用户隐藏但对产品团队仍然可见时，可以采用功能标志方法，这样，你可以在正确的时间为某些用户组打开和关闭它。

4. 不可靠的测试系统

可靠的测试是 CI/CD 的基础。它们保证代码正常工作，并允许你进一步发布流程。如果不信任自动化测试，团队要么需要大量重复性的手动测试工作（这贬低了自动化测试的工作），要么在生产阶段面临大量错误（这将直接损害产品）。

如何避免：确保你使用的测试系统足够可靠。检查它们是否满足两个关键要求：

1. 测试用例充分覆盖了所有功能：所有应用程序模块和所有主要流程都被测试覆盖。
2. 每个单独测试的结果都是可信的：测试不会自己崩溃，如果测试通过，那么这部分功能就真的测试过了。

5. 缺乏有意义的仪表盘和指标

有时，敏捷团队根本没有跟踪重要的指标，并且将大量时间花在记录不会带来任何好处的指标上。

尽管敏捷和 CI/CD 的目标不同，但它们应该互相帮助。这两种方法都基于持续改进的实践。实现它的最简单方法是使用指标和仪表板很好地覆盖所有流程。团队必须能够看到和跟踪当前状态，及时发现问题。

此外，任何问题都应尽早发现并解决。这同样适用于敏捷和 CI/CD。例如，从事 SCRUM 的团队需要了解他们的性能和消耗率，以及他们的交付时间，以查看发布流程中可能存在的瓶颈。如果没有这种理解，那么团队就不会知道系统的哪一部分是无效的，因此也不会专注于改进。

如何避免： 设置CI/CD 过程的指标，设置流程，使团队能够看到任何问题并主动响应。

总结

CI/CD 是一种可靠的方法，可帮助团队提高工作效率，同时提高产品质量和发布速度。尽管如此，只有在正确构建流程时，才会带来可观的效果。不仅CI/CD 工具可以带来积极作用，而且团队文化变化也有帮助。

译文链接: https://dzone.com/articles/common-mistakes-in-ci-cd-implementation