如何扩展及优化CI/CD流水线？

如今应用程序的开发通常由多个开发人员组成的团队完成。每个人或团队在项目中发挥自己的作用，然后我们发现在项目的末尾总是有几段代码需要编译，根据每个人的工作方法，管理这种集成可能会浪费很多时间。持续集成和持续交付/部署（CI/CD）便用来解决该问题，确保发布更新顺利进行，避免不必要的延迟和冲突。
 

因此为应用程序开发和实施 CI/CD 工作流程越来越普遍，与此同时，实施 CI/CD 时也面临许多挑战。在今天的文章中我们将一同探讨这些挑战具体是什么，以及我们应当如何对 CI/CD 进行扩展和优化。
 

CI/CD 流程中的挑战

CI/CD 过程缓慢

速度是任何 CI/CD 过程的重要因素之一。如果您的 CI 服务器和部署需要半小时才能完成该过程，并且您有多个团队，每个团队计划每天部署几次，那么您的 CI/CD 流水线确实会被阻塞。开发人员必须在队列中等待 CI/CD 可用。一些企业限制了可以在给定时间运行的流水线，但这样依旧无法有效提供现代企业所需的快速发布。
 

设置新流水线很复杂

当今 CI/CD 流水线使用的基础设施复杂且难以设置。大多数新应用程序都使用微服务，这会频繁触发新的 CI/CD 流水线启动。但是当您扩展现有的 CI/CD 基础架构时，必须处理与云基础架构相关的许多复杂问题。如果流水线和基础设施管理不是自动化的，这将浪费许多时间在为新流水线配置基础设施和配置上。
 

单个 CI 服务器产生阻塞

在基于微服务的应用程序部署中，CI 服务器是平稳发布工作流程的关键点。如前所述，微服务快速触发 CI 服务器，CI 服务器由于请求过多而阻塞是很常见的。您可以垂直扩展 CI 服务器，这将暂时解决问题，但最终您将需要创建多个具有独立职责的 CI 服务器。即使是一个整体但不断增长的应用程序也会在冲刺结束时阻塞你的 CI 服务器，因为在最后一分钟有太多的代码更改，并且平均每 30 分钟就会有不同的开发人员进行部署。
 

扩展 CI/CD

当微服务数量增加时，对 CI/CD 进行扩展是不可避免的。微服务数量的增加导致不同的流水线连接到单个 git 存储库，这增加了 CI 服务器的负载并降低了性能。要扩展 CI/CD，为所有团队创建一个标准化和自动化的开发流水线，确保开发人员交付和团队交付的质量，同时还让流水线的管理变得容易。
 

可以通过定义用于执行单元测试和验证交付代码质量的CI 流程来实现扩展，随后是用于构建镜像并将它们持续部署到环境中的 CD 过程，最后定义用于构建镜像并将它们部署到生产环境中的过程。接下来我们将按步骤来讲解如何对 CI/CD 进行扩展。
 

扩展 CI/CD 的步骤

流水线遵循 Git 分支到环境的映射（开发 ➡️ 开发和主控 ➡️ 批准和生产）。然后在每次拉取请求时触发 CI 作业，在映射分支中的每次更改时触发 CD 作业。可以按照以下步骤来创建 CI 和 CD 工作流。
 

CI 工作流程分为 7 个步骤：

• 查看 Pull Request 源和目标分支；

• 检查合并是否没有需要手动解决的问题；

• 运行单元测试；

• 构建包以验证完整性和代码可编译性；

• 触发代码质量验证；

• 增加并提交项目版本到源分支；

• 通过 Webhook 或 Rest API 调用（Git 存储库）通知 Pull Request Git 存储库成功或失败。

 
CD 作业流程遵循以下路径：

• 通知的分支被签出。

• 工使用正在处理的项目的特定构建工具构建工件。

• 工件构建好后，将库项目发送到 Nexus 工件存储，流程结束。

 
然后执行以下操作：

• 第 1 步：为生成的工件创建 Docker 镜像，将工件版本应用到 Docker 镜像。

• 第 2 步：镜像上传到 Docker registry。

• 第 3 步：通过 Kubernetes 通过镜像部署进行部署。

 
对于审批/生产环境中的应用程序项目，请按照上面的步骤 1 和 2，然后执行以下操作：

• 在审批环境中通过 Kubernetes 通过 image rollout 进行部署；

• 作业暂停等待 rollout 被批准用于生产；

• 如果通过，则将正在通过的镜像进行生产；

• 如果不通过，它则会回滚批准的镜像。

CI/CD 优化

CI/CD 改善了应用开发周期，解决了集成新代码和增加交付频率带来的问题。接下来我们会一起探讨如何进一步优化 CI/CD 的使用。
 

优先修复损坏的构建

当构建出现故障时，修复故障应该是团队的首要任务。如果构建不能在几分钟内修复，团队必须决定是删除代码还是禁用功能标志。修复损坏的构建背后的主要思想是构建始终生成可以发布的工作代码。
 

小批量频繁部署

通常只要部署发生，应用程序的稳定性就会受到威胁。因此我们倾向于将部署分开，但这种方法的问题是部署中积累的变化太多，如果其中一项更改出错，将会迫使我们回滚其他正在运行的更改。因此请将复杂的变化分解成小而简单的变化，如果更频繁地部署并小批量工作，则部署的风险更低。
 

自动化 QA 测试以降低风险

您的本地环境与投入生产的环境之间可能存在许多不同之处，可以通过自动化 QA 任务（例如浏览器测试）来优化 CI/CD，从而降低错误影响实时应用程序的风险。
 

信任自动化测试

为了验证开发人员何时集成新代码，CI 依赖于自动化且可靠的测试套件。如果需要编译代码，第一个测试是编译，然后您可以添加您认为关键的任意数量的测试。
 

那么应该包括多少个测试？请记住 CI 的目标是尽快提供反馈。如果开发人员必须等待一个小时才能获得反馈是行不通的。错误难以避免，当你发现生产中的错误时，可以创建一个测试用例并将其包含在 CI 循环中。
 

始终考虑安全性

始终考虑 CI/CD 工具在集成到现有配置或环境中时的安全性。CI/CD 要求以编程方式调用所有安全测试工具，并将它们的结果聚合在一个地方。请寻找具有用于自动加密审计的 API 的工具。
 

扩展和优化 CI/CD 的好处

减少开销

当您通过自动化测试、自动交付和自动回滚来扩展 CI/CD 流程时，您可以减少流程中涉及的手动工作。手动操作会浪费很多时间并且容易出错。自动化大部分 CI/CD 流程将节省时间，这些时间可用于修复生产错误等有价值的活动。
 

以更少的错误和更低的风险交付

当您的 CI/CD 通过自动化扩展时，通过更频繁地发布较小的更改，您可以在开发过程中更早地发现错误。当您在开发的所有阶段实施自动化测试时，可以更频繁地发布修复程序，而不必担心 CI/CD 所花费的时间。自动化集成测试是构建运行状况的关键点，您可以安全地将代码移至下一阶段。如果需要，自动化管道可以更轻松地回滚更改。
 

最大限度地提高开发人员的生产力

当您的 CI/CD 流程被扩展时，您的开发人员可以专注于业务需求并监控产品的行为。他们可以在不依赖运营团队的情况下自行自助服务任何产品部署。自助服务功能还使他们能够尝试创新的产品解决方案。这种自主和自力更生的感觉造就了一款非常精致的产品。
 

总结

CI/CD 使您的集成和交付更快。但是，重要的是根据企业的需求和市场变化对其进行扩展和优化，以避免该过程因复杂性增加而拖延产品交付的速度。