扩展和优化CI/CD

实施应用程序开发的CI/CD工作流越来越受欢迎。然而，扩展和优化CI/CD也带来了挑战。

今天我们将讨论这个挑战是什么，并探索如何扩展和优化CI/CD。所以，请跟随我们一起来学习！

现如今，应用程序开发通常由由几名开发人员组成的团队完成。每个人或团队都在项目中扮演着自己的角色，推动着他们专属部分的进展。

然后，我们在项目的末尾发现自己有几段要编译的代码。根据每个人的工作方法，管理这个集成可能会浪费很多时间。

CI/CD，即持续集成和持续交付/部署，是解决这个问题的一个方案，确保更新能够及时发布，避免不必要的延迟和冲突。让我们了解这个过程。

持续集成

CI或持续集成将旨在将代码更改和添加持续发布到项目的共享分支的过程组合在一起。它允许对代码进行测试，并实时进行改进和更改。目标是通过创建测试来测试每个元素。

这种持续的措施使得不必一次性检查所有东西并避免同时处理太多元素。因此，进行单元测试非常有用。这样，通过确保代码编译良好且不会产生回归，更容易检测错误。

持续交付

持续交付或CD将持续集成和testing整合在一起，并将其打包到容器中并进行部署。也就是说，它将这些代码和已执行的测试整合起来，并通过自动化将它们投入生产。

尽管需要人工操作，但通过将已完成的一切整合并以一种完整的方式“上线”，它变得自动化了。具体来说，通过持续交付，我们的应用程序开发成员可以随时将其投入生产。

持续部署

虽然持续交付和持续部署的概念相似，但存在差异。虽然它们的目标相同，即将应用程序部署到生产环境，但实现它们的方式不同。持续交付与持续部署之间的区别在于发布。

确实，持续部署可以直接部署通过不同阶段的每个修改。而在持续交付中，需要经过人工验证步骤才能进行部署。

扩展CI/CD

当微服务数量增加时，几乎无法避免扩展您的CI/CD。增加的微服务数量会导致与单个git存储库连接的不同流水线增加CI服务器的负载并降低性能。

要扩展CI/CD，需要为所有团队创建一个标准化和自动化的开发流水线，并从中确保个人开发人员和团队的交付质量。它还使得流水线的管理变得容易。

通过定义用于执行unit tests和验证交付代码质量的CI流程，可以实现扩展。

然后，通过CD流程构建图像并持续部署它们到环境中，最后定义一个构建图像并将其部署到生产环境的流程。

扩展CI/CD的步骤

第一步是与架构师对齐流水线，涉及团队负责人。然后将Git分支映射到环境（develop -> development和master -> [homologation和production]）。然后在每个Pull Request上触发CI作业，在映射的分支中的每个更改上触发CD作业。

可以创建CI和CD的作业流程进行跟踪。

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

检出Pull Request源和目标分支;
检查合并是否有需要手动解决的冲突;
运行单元测试;
构建软件包以验证完整性和代码可编译性;
触发代码质量验证;
增加并提交项目版本到源分支;
通过Webhook or Rest API调用（Git Repository）通知Pull Request Git库成功或失败。

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

检出通知的分支。
使用正在开发的项目的特定构建工具构建工件。
工件完成后，将库项目发送到Nexus以存储工件，然后完成流程。

执行以下操作：

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

步骤2：将镜像上传到Docker注册表。

步骤3：通过Kubernetes进行镜像滚动部署。

对于处于批准/生产环境的应用项目，请按照上述步骤1和2，然后执行以下步骤：

通过Kubernetes在批准环境中进行镜像滚动部署；
作业暂停等待批准进行生产；
如果获得批准，则将正在批准的镜像升级为生产；
否则，回滚批准的镜像。

CI/CD 优化

CI/CD 改进了应用程序开发周期，并解决了集成新代码和增加交付频率所带来的问题。

以下是进一步优化 CI/CD 使用的方法：

优先修复损坏的构建

当构建出现故障时，修复它应该是团队的首要任务。如果在几分钟内无法修复构建，团队必须决定是删除代码还是禁用功能标志。

修复损坏的构建的理念是构建始终会生成可发布的可工作代码。

小而频繁的部署

通常，每次部署都会给应用程序的稳定性带来风险。因此，我们倾向于将部署与彼此分开。这种方法的问题是我们累积了太多的变更。其中一个变更可能出错，迫使我们回滚其他正常工作的变更。

应用窒息模式，将复杂的更改分解为小而简单的更改。如果更频繁地部署并以小批量工作，部署的风险更低。

自动化 QA 测试以降低风险

我们可能都遇到过“在我的本地机器上工作”的情况，因为本地开发环境通常有所不同。您的本地环境与您进入生产的环境之间可能存在许多不同之处。通过自动化质量保证 (QA) 任务，例如浏览器测试，可以优化 CI/CD，降低错误到达实时应用程序的风险。

相信自动化测试

为了验证开发人员集成新代码的时间，CI 依赖于自动化和可靠的测试套件。如果需要compile code，第一个测试是编译。然后您可以根据需要添加尽可能多的关键测试。

应包括多少个测试？要确定这一点，要记住CI的目标是尽快提供反馈。如果开发人员必须等待一个小时才能得到反馈，那是行不通的。总会有遗漏的地方，但当您在生产中发现错误时，创建一个测试用例并将其包含在CI循环中。

始终考虑安全性

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