解释持续集成与交付流程
学习目标
描述 CI/CD 流程。
在本课中，你将研究持续集成与交付流程是如何运作的。
CI/CD 流程概览
步骤 |
说明 |
|---|---|
1. 代码变更 |
基于源代码主线的最新版本创建一个代码变更。 |
2. Voter 构建与测试 |
在将每个代码变更与主线合并之前，对其进行构建和测试。 |
3. 合并到主线 |
将你的代码变更集成到主线中，为进一步开发创建新的基础。 |
4. CI 构建与测试 |
构建你的代码变更，以检查主线的构建完整性。 |
5. 验收测试 |
执行验收测试，以确保你的软件可以随时部署到生产环境。 |
6. 手动部署到生产环境 |
有意识地决定何时发布某个特定的软件版本。 |
注意
请记住：
持续交付概念是对持续集成概念的扩展。它补充说明：任何已成功通过测试的变更，无论从技术角度还是质量角度，都立即可以部署到生产环境。
1. 代码变更
CI/CD 流程的第一步建立在使用版本控制原则之上：源代码管理系统管理不同版本并定义一条主线。
视频：本节含 SAP 官方视频（视频 ID
1_9c8chs8y），需在 learning.sap.com 在线观看。
2. Voter 构建与测试
CI/CD 流程的第二步基于构建每个变更原则：使用所谓的 voter 构建来自动构建和测试进入主线的每个变更。
合并到主线中的每个变更都可能破坏其稳定性，并影响依赖其完整性的其他开发者。为保护主线免受错误代码的影响，你可以使用所谓的 voter 构建，它会自动构建提议的变更、对其进行验证，并反馈结果。它们为允许进入主代码的变更“投票”。
视频：本节含 SAP 官方视频（视频 ID
1_svl8rpai），需在 learning.sap.com 在线观看。
3. 合并到主线
如果代码变更成功通过了 voter 构建和测试，并满足你定义的所有其他前提条件，就可以合并到主线中。根据开发团队内的策略，此过程可以自动或手动触发，例如由负责的开发者、审查者或团队架构师触发。
视频：本节含 SAP 官方视频（视频 ID
1_dr2bad5r），需在 learning.sap.com 在线观看。
注意
协作工具（例如 GitHub、GitLab 或 Gerrit Code Review）会收集人工代码审查者的反馈，以及 voter 构建和测试结果。
集成一个代码变更会产生新的主线版本，它是进一步开发的基础。请遵循尽早且频繁提交原则：频繁地、以小批量方式将你的变更集成到主线中。
4. CI 构建与测试
在 CI/CD 流程的第四步中，你通过自动化构建来测试你的变更。
将代码变更合并到主线会自动触发 CI 构建。从技术角度看，构建过程与 voter 构建相同：对变更进行适当程度的构建和测试，以检查主线的构建完整性。此步骤之后，该变更就成功集成到主线中了。
下图说明了此过程：
现在，开发团队可以采取以下两种选择之一：
遵循持续集成的概念：流程重新开始。
遵循持续交付的概念：你可以运行额外的测试，并在需要时手动将新的主线版本部署到生产环境。请参见以下步骤。
5. 验收测试
在持续交付场景中，变更不仅必须成功集成到主线中，而且还必须具有足够高的质量，以便在每次变更后都能发布并部署到生产环境。为确保这一质量，变更首先会被部署到与生产环境镜像的验收测试系统。
验收测试相当耗时，并且在执行期间，系统必须保持稳定，不受任何额外变更的干扰。因此，并非所有变更都会进行验收测试。相反，有两种方式可以决定检查哪些变更：
实施自动化，在固定时间测试每个日期最后一次成功的 CI 构建。
质量经理（或其他负责人）有意识地选择测试候选对象，并手动触发其验收测试。
提示
尽管应尽可能自动化测试，但请确保包含一些手动测试。
6. 手动部署到生产环境
如果变更已成功通过所有验收测试，就可以将其部署到生产系统。与大多数情况一样，必须由人（例如发布经理或应用运维人员）对交付承担责任，并明确决定是否发布，因此部署到生产环境是手动触发的。不过，你可以使用自动化框架来支持这一手动步骤。
小结
你现在能够描述 CI/CD 流程的六个步骤，并选择不同的方式来应用它们。
延伸阅读
本课其余配图
