CI/CD 是软件开发中最流行的实践之一，但其实施的陷阱可能成为其收益的严重障碍。

如果您在技术行业工作，您可能已经注意到软件开发方法向流程自动化和 DevOps 实践化的重大转变。

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

大约四年前，我们 Techstack 开始将我们的团队转向 CI/CD 方法。我们已经看到团队合作和业务成果的持续改进，但一开始，我们和大多数团队一样，面临着陷阱和障碍，这让我们怀疑是否需要 CI/CD。

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

为什么要转向CI/CD？

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

下面的信息图显示了 CI/CD 管道的工作原理。

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

1、由于排除了人为因素，并且验证阶段是自动化的，因此增加了释放流程的可靠性。

2、发布小块工作的能力使团队能够首先发布重要的东西。

3、减少频繁发布对 QA 团队的压力。

4、降低涉及同一项目中多个团队工作的发布的复杂性。自动化有助于避免多个团队工作中的潜在冲突，并在出现冲突时提供工具。

5、改进所有发布停止的可见性，例如失败或非工作构建，因为自动系统会在正确的时间将问题通知正确的人。

但老实讲：CI/CD 的优点被谈论的比缺点多。

让我们弄清楚工程团队在实施 CI/CD 时可能会面临哪些问题。

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

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

1、在不稳定 CI 上构建CD

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

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

如果您不确定这些要点，请准备好应对持续不断的 CD 流程中断以及工程师需要查找和修复问题（例如新错误和崩溃构建）的需要。

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

2、自动化的好处值不值得其潜在的风险

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

让我们看一个例子：

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

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

如何避免：在开始 CI/CD 实施之前，清楚地比较这种自动化的收益和成本。

这里有一些问题可以帮助你做到这一点：

• 这个过程多久重复一次？
• 多久时间？
• 有多少人和资源参与其中？
• 缺乏自动化会导致流程出错吗？
• 为什么这个过程现在需要自动化？

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

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

3、将持续部署理解为持续交付

持续部署是一种特定的实践，代码库中的任何更改都应该自动且快速地投入生产。

一方面，大多数工程团队对此持谨慎态度，因为快速更改可能会使用户感到困惑。另一方面，他们可以通过不立即将更改启动到生产中，来确保不将 CD 成为方法论的一部分。事实上，他们只是将持续部署理解为持续交付。

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

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

4、 不可靠的测试系统

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

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

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

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

有时，敏捷团队甚至还没来得及了解哪些对他们来说真正有用的跟踪哪些不是，就收到了一个指标列表。结果，重要的指标根本没有被跟踪，大量的时间花在记录没有任何好处的指标上。

尽管敏捷和 CI/CD 的目标不同，但它们应该互相帮助。这两种方法都基于持续改进实践——对完成、修订和进步的不断分析。实现它的最简单方法是使用指标和仪表板很好地覆盖所有流程。团队必须能够看到当前状态以了解下一步该去哪里。

此外，任何问题都应尽早发现并解决。这同样适用于敏捷和 CI/CD。例如，从事 SCRUM 的团队需要了解他们的性能和消耗率，以及他们的交付时间，以查看发布流程中可能存在的瓶颈。

如果没有这种理解，那么团队将不知道系统的哪一部分是无效的，因此不会专注于改进。

如何避免：确保团队拥有显示 CI/CD 过程成功的指标。设置流程，使团队能够看到任何问题并主动做出响应。

CI/CD 的结果

CI/CD 是一种可靠的方法，可帮助团队提高工作效率，同时提高产品质量和发布速度。尽管如此，只有在正确构建流程时，单击鼠标的部署路径才会有效。不仅特殊工具可以在这方面有所帮助，而且每个团队成员的文化改变也有帮助。

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