共计 2763 个字符，预计需要花费 7 分钟才能阅读完成。
现在应用程序的开发通常由多个开发人员组成的团队实现。每个人或团队在我的项目中施展本人的作用，而后咱们发现在我的项目的开端总是有几段代码须要编译，依据每个人的工作办法，治理这种集成可能会节约很多工夫。继续集成和继续交付 / 部署（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 使您的集成和交付更快。然而，重要的是依据企业的需要和市场变动对其进行扩大和优化，以防止该过程因复杂性减少而迁延产品交付的速度。
