本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
以管道为例，两阶段 DevOps 管道可能有一个名为 Source 的源阶段和一个名为 Pro d 的第二阶段。在此示例中，管道使用最新更改来更新应用程序，并持续部署最新结果。在部署最新的应用程序之前，管道会构建并测试 Web 应用程序。在此示例中，一组开发人员在名为的 GitHub 存储库中设置了基础架构模板和一个 Web 应用程序的源代码 MyRepository。
例如，开发人员将修复推送到 Web 应用程序的索引页面，并将发生以下情况：
-
应用程序源代码保存在配置为管道中 GitHub 源操作的存储库中。当开发者将提交推送到存储库时， CodePipeline 会检测到推送的更改，然后从源阶段开始执行管道。
-
GitHub 源操作成功完成（也就是说，最新更改已下载并存储到该执行所特有的构件存储桶中）。然后， GitHub 源操作生成的输出构件（即存储库中的应用程序文件）将用作输入工件，供下一阶段的操作处理。
-
管道执行从源阶段转换到生产阶段。Prod Stag e 中的第一个操作运行在管道中创建 CodeBuild 并配置为生成操作的生成项目。构建任务提取构建环境映像，然后在虚拟容器中构建 Web 应用程序。
-
Prod Stag e的下一个操作是在管道中创建 CodeBuild 并配置为测试操作的单元测试项目。
-
单元测试的代码接下来由生产阶段中的部署操作处理，该操作将应用程序部署到生产环境。部署操作成功完成后，该阶段的最后一个操作是在管道中创建 CodeBuild 并配置为测试操作的集成测试项目。测试操作调用在 Web 应用程序上安装和运行测试工具（如链接检查器）的 shell 脚本。成功完成后，输出是一个构建 Web 应用程序和一组测试结果。
开发人员可以向管道添加操作，以便在构建并针对每个更改测试应用程序后，对其进行部署或进一步测试。
有关更多信息，请参阅 管道执行的工作原理。
