CI／CD流水线的 6 个设计策略

关注我，每天收获一个新技能!

在当今世界，对于任何希望快速构建和交付高质量软件的开发团队来说，经过良好调整的 CI/CD 管道都是至关重要的组成部分。但问题是：很少能找到两个完全相同的 CI/CD 管道。这是设计使然。每个 CI/CD 管道都应根据团队的特定需求进行构建。

尽管如此，构建 CI/CD 管道时，成熟度存在差异，从基本实施到更高级的自动化工作流程。但无论您在 CI/CD 旅程中处于什么阶段，您都可以做一些事情来升级您的 CI/CD 管道。

以下是我经常在 CI/CD 管道中发现的六个战略性事项，它们可以帮助任何开发人员或团队推进和改进他们的工作流程。

性能、设备兼容性和可访问性测试通常需要手动操作，而且有些团队只做了部分工作。

手动测试这些内容可能会减慢交付周期，因此许多团队要么承担成本，要么干脆不做。    

但如果这些事情对你来说很重要（而且应该如此），那么可以将一些工具包含在你的 CI/CD 管道中，以自动测试和发现任何问题。

1， 性能和设备兼容性测试   

例如，Playwright是一款可以进行端到端测试、自动化测试以及介于两者之间的所有测试的工具。您还可以使用它进行 UI 测试，以便发现产品中的问题。

2， 视觉回归测试 

还有另一类工具可以帮助您自动执行视觉回归测试，以确保您没有在无意的情况下更改 UI。这意味着您没有引入任何意外的 UI 更改。这对于设备兼容性测试也非常有用。如果某个设备上的某些东西看起来不好，您可以快速纠正它。

3， 可访问性测试 

这是另一类非常有效的自动化测试，可以添加到您的 CI/CD 管道中。为什么？因为您的每一位客户对您来说都应该是有价值的——即使只有一小部分客户在使用您的产品时遇到麻烦，这也很重要。    

有大量的可访问性测试工具可以告诉你一些信息，例如你的内容是否适合屏幕阅读器，或者你网站上的颜色是否对色盲人士有意义。一个很好的例子是Pa11y，这是一个开源工具，你可以使用它通过命令行或 Node.js 运行自动可访问性测试。

安全性应始终是软件交付流程的一部分，在当今的环境中，安全性至关重要。即便如此，我还是看到许多团队和公司没有将自动化安全测试纳入其 CI/CD 流程中，而是将安全性视为 DevOps 流程完成后才会发生的事情。

好消息是：有很多工具可以帮助您轻松完成此操作 - 包括 GitHub 原生工具，如Dependabot、代码扫描、秘密扫描，如果您是 GitHub Enterprise 用户，您可以将 GitHub 提供的所有安全功能以及更多功能与GitHub Advanced Security捆绑在一起。但即使使用免费的 GitHub 帐户，您仍然可以在任何公共或私有存储库上使用 Dependabot，并且代码扫描和秘密扫描也可用于所有公共存储库。    

例如，Dependabot 可以扫描依赖项中是否存在过期的软件包，并自动创建拉取请求以供团队修复，从而帮助您缓解依赖项中存在的任何潜在问题。它还可以配置为自动更新任何项目依赖项。

这影响巨大。开发人员和团队通常不会更新依赖项，因为更新依赖项需要时间 — 或者有时他们甚至只是忘记更新依赖项。依赖项是漏洞的合法来源，但经常被忽视。

此外，GitHub 平台还提供代码扫描和秘密扫描，可以将其内置到您的 CI/CD 管道中，以改善您的安全配置文件。代码扫描提供 SAST 功能，可显示您的代码本身是否包含任何已知漏洞，而秘密扫描可确保您不会将任何凭据泄露给您的存储库。如果有任何暴露的凭据，它还可用于阻止任何推送到您的存储库的操作。

最重要的是，团队应该将安全视为整个 SDLC 中要做的事情，而不仅仅是在投入生产之前和之后。当然，你应该始终检查安全问题。但越早发现问题越好（你好DevSecOps）。因此，在 CI/CD 管道中包含安全测试是一项必不可少的做法。    

GitHub 上自动化安全测试工作流程的屏幕截图。

分阶段测试是一种很好的策略，可以确保您能够快速大规模地交付安全软件。但它也需要时间来构建。因此，很多团队都没有这样做。

通常，开发人员会将所有或大部分自动化测试放在 CI/CD 管道的构建阶段。这意味着构建可能需要很长时间才能完成。虽然这没有什么不对，但您可能会发现需要更长时间才能获得代码反馈。   

通过分阶段测试，您可以尽早发现重大问题并更快地获得代码库的反馈。目标是快速构建，使用单元测试等简单测试快速测试基本功能。

在此之后，您可以将构建部署到测试环境中以执行其他测试，例如一些可访问性测试、用户测试和其他可能需要更长时间执行的测试。这意味着您正在从最关键的元素开始解决许多可能的问题。

随着分阶段测试模型越来越接近生产，您需要测试越来越多的内容。这可能包括关键项目，例如回归测试，以确保以前的错误不会再次出现在您的代码库中。在这个阶段，事情出错的可能性较小。但您需要尽早有效地发现重大问题，然后缩小测试范围，以确保您交付的是高质量的应用程序。

哦，当然，还有生产测试，这是它自己的事。但您可以将部署后测试纳入生产环境。您可能有一个假设，想要测试某些东西在生产中是否有效，并执行测试以找出答案。在 GitHub，我们经常这样做，方法是发布带有功能标志的新功能，然后为部分用户群启用该标志以收集反馈。

当谈到发布应用程序的新版本时，你会想到一个词是什么？对我来说，最重要的词是“压力”（尽管“兴奋”和“解脱”紧随其后）。蓝绿部署是改进在 CI/CD 管道中推出应用程序新版本的方式的一种方法，但它也可能更复杂一些。

简单来说，蓝绿部署涉及在生产环境中部署两个或更多版本的应用程序，并慢慢将用户从旧版本迁移到新版本。这意味着当您需要更新或部署应用程序的新版本时，它会进入“未使用”的生产环境，您可以慢慢安全地将用户迁移到新版本。

这样做的好处是，您可以通过将用户重定向到另一个生产环境来快速回滚任何更改。这还可以大大减少部署新应用程序版本时的停机时间。您可以在环境中设置好所有内容，然后将人们引导到新环境中。

当您拥有两个可互换的环境时，蓝绿部署是完美的选择。实际上，在大型系统中，您可能运行着一套 Web 服务器或多个无服务器应用程序。实际上，这意味着您可能正在使用可以在多个位置之间分配流量的负载均衡器。负载均衡器的典型示例是nginx —但每个云都有自己的产品（例如Azure Front Door或AWS 上的 Elastic Load Balancing）。   

这种策略在使用Kubernetes 的组织中很常见。您可能有许多正在运行的 Pod，当您进行部署时，Kubernetes 会将更新部署到新实例并重定向流量。管理哪些 Pod 已启动并正在运行遵循与蓝绿部署相同的原则 - 但您还需要浏览更复杂的架构。

基础设施配置是根据需要构建 IT 基础设施的实践——一些团队会在其 CI/CD 管道中采用基础设施即代码 (IaC)，以在管道中的特定点自动配置资源。

我强烈建议这样做。IaC 的目标是，当您部署应用程序时，您也会部署基础架构。这意味着您始终知道您的基础架构在生产中是什么样子，并且您的测试环境也可以复制到生产中。    

将 IaC 构建到 CI/CD 管道中有三个好处： 

1.可以帮助您确保您的应用程序及其运行的基础设施定期接受同步测试。传统的做法是说这是一台生产机器，它看起来是这样的——这是我们的测试机器，我们希望它尽可能接近生产环境。但几乎总是，你会发现生产环境会随着时间的推移而发生变化——这使得了解你的生产环境变得更加困难。

2.   它可以帮助您缓解基础设施的任何实时问题。这意味着，如果您的生产服务器出现故障，这并不是灾难 — 您可以重新部署它（甚至可以自动重新部署）。

3.  最后但同样重要的一点是：将 IaC 构建到您的 CI/CD 管道中意味着您可以更有效地执行蓝绿部署等操作。您可以部署应用程序的新版本（包括代码和基础架构），并重新路由 DNS 以转到该版本。如果它不起作用，那也没关系 - 您可以快速回滚到以前的版本。

理想情况下，您希望避免回滚软件版本。但说实话。我们都会犯错，有时在开发或测试环境中运行的代码在生产中无法完美运行。

当您需要将发布回滚到以前的应用程序版本时，自动化可以更轻松地快速完成此操作。

我认为回滚是一个通用术语，指的是通过恢复到以前的版本来缓解生产问题，无论是重新部署还是从备份中恢复。如果您拥有出色的 CI/CD 管道，那么理想情况下您可以解决问题并立即推出更新 - 这样您就可以避免不得不转到以前的应用程序版本。