本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 理解 CI/CD
持续集成和持续交付 (CI/CD) 是软件发布生命周期自动化的过程。在某些情况下，“*D*” CI/CD 也可以表示*部署*。*持续交付*和*持续部署*之间的区别体现在发布对生产环境的变更时。对于持续交付，在推动对生产环境的变更之前需要手动批准。持续部署的特点是可以不间断地贯穿整个管线，不需要显式批准。由于此策略讨论的是一般 CI/CD 概念，因此所提供的建议和信息适用于持续交付和持续部署方法。
CI/CD 自动执行传统上将新代码从提交到生产环境所需的大部分或全部手动流程。 CI/CD 管道包括源代码、构建、测试、暂存和生产阶段。在每个阶段， CI/CD 管道都会提供部署或测试代码所需的任何基础架构。通过使用 CI/CD 管道，开发团队可以对代码进行更改，然后对其进行自动测试并推送到部署中。
让我们回顾一下基本 CI/CD 过程，然后再讨论一些有意或无意中可能完全偏离的方式。 CI/CD下图显示了每个 CI/CD 阶段的阶段和活动。
## 关于持续集成
持续集成在代码存储库中进行，例如 GitHub 中的 Git 存储库。您将一个主分支视为代码库的真实来源，为功能开发创建短期分支。当您准备好将功能部署到上层环境时，可以将该功能分支集成到主分支中。功能分支永远不会直接部署到上层环境。有关更多信息，请参阅本指南中的[Trunk-based 方法](fully-cicd-process-differences.md#trunk-based-approach)。
*持续集成流程*
1. 开发人员从主分支创建一个新分支。
1. 开发人员在本地进行更改、构建和测试。
1. 更改准备就绪后，开发人员会创建一个以主分支为目标的[拉取请求](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)（GitHub 文档）。
1. 代码将进行审查。
1. 当代码获得批准后，其会合并到主分支中。
## 关于持续交付
持续交付在开发环境和生产环境等隔离环境中进行。每种环境中进行的操作可能有所不同。通常，第一个阶段之一用于对管线本身进行更新，然后再继续。部署的最终结果是，每个环境均更新为最新的更改。用于构建和测试的开发环境的数量也各不相同，但我们建议您使用至少两个。在管线中，每个环境都按其重要性顺序进行更新，最后更新最重要的环境，即生产环境。
*持续交付流程*
管线的持续交付部分通过以下方式启动：从源存储库的主分支提取代码并将其传递到构建阶段。存储库的基础设施即代码（IaC）文档概述了在每个阶段执行的任务。尽管使用 IaC 文档并非强制要求，但强烈建议使用 IaC 服务或工具，例如 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 或 [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)。最常见的步骤包括：
1. 单元测试
1. 代码构建
1. 资源预调配
1. 集成测试
如果在管线的任何阶段出现任何错误或任何测试失败，则当前阶段将回滚到其之前的状态，并且管线将终止。后续的更改必须从代码存储库中开始并完成整个 CI/CD 过程。