持续集成/持续交付 (CI/CD) 工作流的扩展与优化
在当今的软件开发领域，实施 CI/CD 工作流程已成为一种日益流行的实践。然而，随着 CI/CD 的普及，如何有效地扩展和优化这些流程也变得至关重要，这其中也伴随着一些挑战。
本文将深入探讨这些挑战，并探讨如何成功地扩展和优化 CI/CD 流程，以满足不断变化的软件开发需求。让我们一同探索！
现代应用程序开发往往由多个开发人员组成的团队协作完成。每个开发人员或团队专注于项目的特定部分，共同推动项目进展。
因此，在项目后期，我们需要集成来自不同开发人员的多个代码片段。这种集成管理，如果方法不当，可能会导致大量的时间浪费。
为了解决这个问题，并确保在更新发布时避免不必要的延迟和冲突，CI/CD（持续集成和持续交付/部署）应运而生。让我们深入了解这一过程。
持续集成
持续集成 (CI) 是一种将代码更改频繁地集成到项目共享分支的实践。它允许对代码进行实时测试，并及时进行改进和调整。其核心目标是通过创建自动化测试来验证代码的每个部分。
这种持续集成的做法避免了在最后阶段一次性检查所有代码，从而避免了同时处理大量元素的复杂性。单元测试对于确保代码的每个部分都经过彻底验证至关重要。通过确保代码编译良好且不会引入回归错误，我们可以更容易地检测到潜在的问题。
持续交付
持续交付 (CD) 将持续集成和测试结合在一起，可以将代码打包成容器并准备投入生产。 也就是说，它将已测试的代码通过自动化方式部署到准生产或生产环境。
即使有时可能需要人工干预，持续交付通过自动化已经完成的工作的“发布”来简化流程。简而言之，在持续交付的实践下，我们的应用程序能够随时部署到生产环境。
持续部署
尽管持续交付和持续部署的概念相似，但它们之间存在关键差异。尽管它们的目标都是将应用程序部署到生产环境，但实现目标的方式有所不同。 持续交付和持续部署之间的区别在于最终部署的执行方式。
在持续部署中，每个代码修改都会直接通过管道的不同阶段部署到生产环境。而在持续交付中，通常需要一个人工验证步骤才能进行部署。
扩展 CI/CD
随着微服务数量的增长，扩展 CI/CD 几乎是不可避免的。 微服务数量的增加会导致多个管道连接到同一个 Git 存储库，从而加重 CI 服务器的负担并降低性能。
为了有效扩展 CI/CD，为所有团队创建标准化和自动化的开发管道至关重要。这有助于确保单个开发人员和团队交付的代码质量，并简化管道管理。
扩展可以通过定义 CI 流程来实现，该流程负责执行单元测试和验证交付代码的质量。随后是 CD 流程，该流程负责构建镜像并将其连续部署到各个环境，最终部署到生产环境。
扩展 CI/CD 的步骤
第一步是让管道与架构师，包括团队领导保持一致。它遵循 Git 分支到环境的映射（开发 -> 开发和主 -> [同构和生产]）。 然后，CI 作业在每个 Pull Request 处触发，而 CD 作业在映射分支中的每次更改时触发。
可以为要遵循的 CI 和 CD 创建作业流。
CI 作业流程分为 7 个步骤：
- 检查拉取请求的源分支和目标分支；
- 检查合并是否没有需要手动解决的冲突；
- 运行单元测试；
- 构建包以验证完整性以及代码是否可编译；
- 触发代码质量验证；
- 增加项目版本并将其提交到源分支；
- 通过 Webhook 或 Rest API 调用（Git 存储库）通知 Pull Request Git 存储库成功或失败。
CD 作业流程遵循以下路径：
- 通知的分支已签出。
- 该工件是使用正在处理的项目的特定构建工具构建的。
- 工件来后，将库项目发送到 Nexus 进行工件存储，流程结束。
然后执行以下操作：
第 1 步：为生成的工件创建 Docker 镜像，并将工件版本应用于 Docker 镜像。
第 2 步：将镜像上传到 Docker 注册表。
第 3 步：通过 Kubernetes 发布镜像进行部署。
对于处于审批/生产环境中的应用项目，请执行上述步骤 1 和 2，然后执行以下操作：
- 在审批环境中通过 Kubernetes 镜像 rollout 进行部署；
- 该工作需要暂停，以等待部署被批准用于生产；
- 如果获得批准，则将正在批准的图像推广用于生产；
- 否则，它会在批准后回滚图像。
CI/CD 优化
CI/CD 显著改善了应用程序开发周期，解决了集成新代码和提高交付频率所面临的挑战。
以下是一些进一步优化 CI/CD 使用的方法：
优先修复损坏的构建
当构建失败时，修复它应是团队的首要任务。如果无法在短时间内修复构建，团队需要决定是删除代码还是禁用功能标志。
修复损坏构建的目的是确保构建始终产生可发布的工作代码。
小而频繁的部署
应用程序的稳定性通常会在每次部署时受到威胁。因此，我们倾向于减少部署频率。这种方法的缺陷在于，我们会累积大量的更改。任何一个更改都可能出错，导致我们回滚其他正在工作的更改。
我们应该采用扼杀者模式，将复杂的更改分解成小而简单的更改。如果更频繁地进行小批量部署，则部署风险会显著降低。
自动化 QA 测试以降低风险
我们都可能遇到过“在我本地机器上可以正常运行”的情况，因为本地开发环境通常与生产环境有所不同。本地环境和生产环境之间可能存在许多差异。通过自动化质量保证 (QA) 任务（例如浏览器测试），我们可以优化 CI/CD，降低错误进入生产环境的风险。
信任自动化测试
为了验证开发人员何时集成新代码，CI 依赖于自动化且可靠的测试套件。如果需要编译代码，第一个测试就是验证其是否可以编译。然后，您可以根据需要添加关键测试。
应该添加多少测试？要确定这一点，请记住 CI 的目标是尽快提供反馈。如果开发人员必须等待一个小时才能获得反馈，那效率就太低了。 我们不可能捕获所有错误，但当我们在生产环境中发现错误时，我们应该创建一个测试用例，并将其包含在 CI 循环中。
始终考虑安全性
在配置和环境中集成 CI/CD 工具时，务必考虑安全性。CI/CD 需要以编程方式调用所有安全测试工具，并将结果汇总到一个位置。 寻找具有用于自动安全审计的 API 的工具。
扩展和优化 CI/CD 的好处
除了提高开发团队的效率之外，扩展和优化 CI/CD 还具有其他好处，其中包括：
减少开销
开发时间通常是按小时计费的，但手动部署代码或文件所花费的时间呢？自动化大部分流程可以为计费工作节省时间，这是大家都乐见的。自动化测试还可以让您更快地发现错误，避免在 QA 或生产中发现错误，甚至更糟，客户发现错误。在相同时间内修复更多错误是一种明显的优势。
以更少的错误和更低的风险交付
通过更频繁地发布小的更改，可以在开发过程的早期发现错误。当在开发的所有阶段实施自动化测试时，您不会将错误代码传递到下一个阶段。 在需要时更容易回滚微小的更改。
更快地响应市场状况
市场条件不断变化。 假设您发现某个产品正在失去收入，或者更多客户通过智能手机而非笔记本电脑访问您的网站。 在这种情况下，如果优化了持续交付，那么进行快速更改会容易得多。
信心
如果优化了 CI/CD，这意味着您拥有一个强大的测试套件，您提交错误代码的信心会大大增强。 如果您对流程保持透明，并对团队的其他成员和客户进行教育，那么他们对您作为开发团队的信任也会提高。
最后的话
CI/CD 使集成和交付过程更快。但是，重要的是扩展和优化 CI/CD，以避免因复杂性增加而导致过程适得其反。
您还可以查看一些优秀的 CI 工具。