为多 DevOps 账户环境实施中继分支策略 - AWS 规范指引
Summary先决条件和限制架构工具最佳实践操作说明问题排查相关资源

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

为多 DevOps 账户环境实施中继分支策略

Mike Stephens 和 Rayjan Wilson，Amazon Web Services

Summary

管理源代码存储库时，不同的分支策略会影响开发团队使用的软件开发和发布流程。常见分支策略的示例包括 Trunk、 GitHub Flow 和 Gitflow。这些策略使用不同的分支，并且在每种环境中执行的活动也各不相同。正在实施 DevOps 流程的组织将受益于可视化指南，以帮助他们了解这些分支策略之间的区别。在组织中使用此视觉对象可以帮助开发团队协调工作并遵循组织标准。此模式提供了该视觉对象，并描述了在组织中实施中继分支策略的过程。

这种模式是关于为具有多个 AWS 账户分支机构的组织选择和实施 DevOps 分支策略的文档系列的一部分。该系列旨在帮助您从一开始就应用正确的策略和最佳实践，以简化您的云体验。中继只是您的组织可以使用的一种潜在分支策略。本文档系列还涵盖了 GitHub Flow 和 Gitflow 分支模型。如果你还没有这样做，我们建议你先查看为多账户 DevOps 环境选择 Git 分支策略，然后再按此模式实施指南。请务必谨慎选择适合组织的分支策略。

本指南提供了图表，其中显示了组织如何实施中继策略。建议您查看官方的《Well-Ar DevOps chitec AWS ted 指南》，以查看最佳实践。此模式包括 DevOps 流程中每个步骤的推荐任务、步骤和限制。

先决条件和限制

先决条件

  • Git，已安装。这可用作源代码存储库工具。

  • Draw.io，已安装。此应用程序可用于查看和编辑图表。

架构

目标架构

下图的使用方法与旁氏表类似（维基百科）。您可以将垂直轴上的分支与水平轴上的 AWS 环境对齐，以确定在每个场景中要执行的操作。这些数字表示工作流中各项操作的顺序。此示例可引导您了解从 feature 分支到在生产环境中部署的整个过程。

每个分支和环境中的中继活动的旁氏表

有关 Trunk 方法中的 AWS 账户、环境和分支的更多信息，请参阅为多账户 DevOps 环境选择 Git 分支策略。

自动化和扩展

持续集成和持续交付（CI/CD) is the process of automating the software release lifecycle. It automates much or all of the manual processes traditionally required to get new code from an initial commit into production. A CI/CD pipeline encompasses the sandbox, development, testing, staging, and production environments. In each environment, the CI/CD pipeline provisions any infrastructure that is needed to deploy or test the code. By using CI/CD, development teams can make changes to code that are then automatically tested and deployed. CI/CD管道）还通过强制执行一致性、标准、最佳实践以及功能接受和部署的最低接受程度，为开发团队提供管理和护栏。 有关更多信息，请参阅上的 “练习持续集成和持续交付” AWS。

AWS 提供了一套旨在帮助您构建 CI/CD 管道的开发人员服务。例如，AWS CodePipeline是一项完全托管的持续交付服务，可帮助您实现发布管道的自动化，从而实现快速可靠的应用程序和基础设施更新。 AWS CodeBuild编译源代码、运行测试和生成 ready-to-deploy软件包。有关更多信息，请参阅上的开发者工具 AWS。

工具

AWS 服务和工具

AWS 提供了一套开发者服务，你可以用它们来实现这种模式：

  • AWS CodeArtifact 是一项高度可扩展的托管式构件存储库服务，有助于您存储和共享用于应用程序开发的软件包。

  • AWS CodeBuild 是一项完全托管式构建服务，可编译源代码、运行单元测试和生成部署就绪的构件。

  • AWS CodeDeploy自动部署到亚马逊弹性计算云 (Amazon EC2)、本地实例、 AWS Lambda 函数或亚马逊弹性容器服务 (Amazon ECS) 服务。

  • AWS CodePipeline 可帮助您快速对软件发布过程的不同阶段进行建模和配置，并自动执行持续发布软件变更所需步骤。

其他工具

  • Draw.io 桌面 – 用于制作流程图和图表的应用程序。

  • Figma 是一款专为协作而打造的在线设计工具。代码存储库包含 Figma 的 .fig 格式模板。

代码存储库

此模式中图表的源文件可在中继的 GitHub Git 分支策略存储库中找到。其包括采用 PNG、draw.io 和 Figma 格式的文件。您可以修改这些图表，以为组织的流程提供支持。

最佳实践

遵循 Well-Architect AWS e DevOps d 指南和为多账户环境选择 Git 分支策略中的最佳实践和建议。 DevOps 这些最佳实践可以帮助您有效地实施基于中继的开发、促进协作、提高代码质量以及简化开发流程。

操作说明

Task说明所需技能

查看标准中继流程。

  1. 在沙盒环境中，开发人员从 main 分支创建 feature 分支并使用命名模式 feature/<ticket>_<initials>_<short description>。

  2. 开发人员开发代码，并以迭代方式将代码部署到沙盒环境中，进而完成票证。

    注意

    开发人员可以选择创建一个 sandbox 分支，在沙盒环境中运行自动构建或部署管道。

  3. 开发人员使用压缩合并创建从 feature 分支到 main 分支的合并请求。

  4. 持续集成和持续交付（CI/CD）管道可自动构建 main 分支中的构件并将其发布到开发环境。

  5. 审批者会手动批准将发布构件部署到开发环境。

  6. 审批者会手动批准将发布构件部署到测试环境。

  7. 审批者会手动批准将发布构件部署到暂存环境。

  8. 审批者会手动批准将发布构件部署到生产环境。

DevOps 工程师

问题排查

问题解决方案

分支冲突

中继模型可能出现的一个常见问题是，生产环境需要修补程序，但 feature 分支中也需要进行相应更改，因为该分支中同样存在要修改的资源。我们建议您经常将来自 main 更改合并到较低的分支中，以避免在合并到 main 时发生重大冲突。

相关资源

本指南不包括针对 Git 的培训；但是，如果您需要这种培训，则可以在互联网上找到许多可用的高质量的资源。我们建议从 Git 文档网站开始。

以下资源可以帮助您在 AWS Cloud中完成中继分支之旅。

AWS DevOps 指导

中继指引

其他资源