本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 為多帳戶 DevOps 環境實作 GitHub 流程分支策略
*Mike Stephens 和 Abhilash Vinod，Amazon Web Services*
## 總結
管理原始程式碼儲存庫時，不同的分支策略會影響開發團隊使用的軟體開發和發行程序。常見的分支策略範例包括主體、GitHub Flow 和 Gitflow。這些策略使用不同的分支，而且每個環境中執行的活動都不同。實作 DevOps 程序的組織將受益於視覺化指南，以協助他們了解這些分支策略之間的差異。在您的組織中使用此視覺效果有助於開發團隊協調工作並遵循組織標準。此模式提供此視覺化效果，並說明在您的組織中實作 GitHub Flow 分支策略的程序。
此模式是文件系列的一部分，旨在為具有多個 的組織選擇和實作 DevOps 分支策略 AWS 帳戶。此系列旨在協助您從一開始就套用正確的策略和最佳實務，以簡化雲端體驗。GitHub Flow 只是您的組織可以使用的一個可能分支策略。此文件系列也涵蓋[了主體](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html)和 [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) 分支模型。如果您尚未這麼做，我們建議您在實作此模式中的指引之前，先檢閱[為多帳戶 DevOps 環境選擇 Git 分支策略](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)。請使用盡職調查來為您的組織選擇正確的分支策略。
本指南提供圖表，說明組織如何實作 GitHub 流程策略。建議您檢閱 [AWS Well-Architected DevOps 指南](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)，以檢閱最佳實務。此模式包含 DevOps 程序中每個步驟的建議任務、步驟和限制。
## 先決條件和限制
**先決條件**
+ Git，[已安裝](https://git-scm.com/downloads)。這用作原始程式碼儲存庫工具。
+ Draw.io，[已安裝](https://github.com/jgraph/drawio-desktop/releases)。此應用程式用於檢視和編輯圖表。
## Architecture
**目標架構**
下圖可以像 [Punnett 方形](https://en.wikipedia.org/wiki/Punnett_square) （維基百科） 一樣使用。您可以將垂直軸上的分支與水平軸上的 AWS 環境對齊，以決定在每個案例中要執行的動作。這些數字表示工作流程中動作的序列。此範例會帶您從`feature`分支到生產環境中的部署。
如需 GitHub Flow 方法中 AWS 帳戶、 環境和分支的詳細資訊，請參閱[為多帳戶 DevOps 環境選擇 Git 分支策略](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach)。
**自動化和擴展**
持續整合和持續交付 (CI/CD) 是自動化軟體版本生命週期的程序。它會自動化傳統上需要的許多或所有手動程序，從初始遞交取得新的程式碼到生產環境。CI/CD 管道包含沙盒、開發、測試、預備和生產環境。在每個環境中，CI/CD 管道會佈建部署或測試程式碼所需的任何基礎設施。透過使用 CI/CD，開發團隊可以對程式碼進行變更，然後自動測試和部署。CI/CD 管道也透過強制執行一致性、標準、最佳實務和最低接受度來為開發團隊提供控管和防護。如需詳細資訊，請參閱[實作持續整合和持續交付 AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)。
AWS 提供一套開發人員服務，旨在協助您建置 CI/CD 管道。例如， [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)是一種全受管的持續交付服務，可協助您自動化發行管道，以取得快速且可靠的應用程式和基礎設施更新。 會[AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)編譯原始程式碼、執行測試，並產生ready-to-deploy的軟體套件。如需詳細資訊，請參閱 [上的開發人員工具 AWS](https://aws.amazon.com/products/developer-tools/)。
## 工具
**AWS 服務和工具**
AWS 提供一套開發人員服務，您可以用來實作此模式：
+ [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html) 是一種高度可擴展的受管成品儲存庫服務，可協助您存放和共用應用程式開發的軟體套件。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 是一種全受管建置服務，可協助您編譯原始程式碼、執行單元測試，並產生準備好部署的成品。
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 會自動部署到 Amazon Elastic Compute Cloud (Amazon EC2) 或內部部署執行個體、 AWS Lambda 函數或 Amazon Elastic Container Service (Amazon ECS) 服務。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 可協助您快速建模和設定軟體版本的不同階段，並自動化持續發行軟體變更所需的步驟。
**其他工具**
+ [Draw.io Desktop](https://github.com/jgraph/drawio-desktop/releases) 是製作流程圖和圖表的應用程式。程式碼儲存庫包含 Draw.io 的 .drawio 格式範本。
+ [Figma](https://www.figma.com/design-overview/) 是一種線上設計工具，專為協同合作而設計。程式碼儲存庫包含 Figma 的 .fig 格式範本。
**程式碼儲存庫**
此模式中圖表的這個來源檔案可在 GitHub [Flow 儲存庫的 GitHub Git 分支策略](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/github-flow)中使用。它包含 PNG、draw.io 和 Figma 格式的檔案。您可以修改這些圖表以支援組織的程序。
## 最佳實務
遵循 [AWS Well-Architected DevOps 指南](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)中的最佳實務和建議[，並為多帳戶 DevOps 環境選擇 Git 分支策略](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)。這些可協助您有效地實作 GitHub Flow 型開發、促進協作、改善程式碼品質，以及簡化開發程序。
## 史詩
### 檢閱 GitHub 流程工作流程
| 任務 | Description | 所需的技能 |
| --- | --- | --- |
| 檢閱標準 GitHub 流程。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps 工程師 |
| 檢閱錯誤修正 GitHub 流程程序。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps 工程師 |
| 檢閱 Hotfix GitHub Flow 程序。 | GitHub Flow 旨在啟用持續交付，其中程式碼變更經常且可靠地部署到更高的環境。關鍵在於，每個`feature`分支都可以隨時部署。
`Hotfix` 分支與 `feature`或 `bugfix` 分支類似，可以遵循與這些其他分支相同的程序。不過，考慮到其緊迫性，修正程式通常具有較高的優先順序。根據團隊的政策和情況的緊迫性，程序中的某些步驟可能會加快。例如，可能會快速追蹤 Hotfix 的程式碼檢閱。因此，當 Hotfix 程序平行處理特徵或錯誤修正程序時，圍繞 Hotfix 的緊迫性可能需要修改程序遵循。請務必建立有關管理 Hotfix 的準則，以確保有效且安全地處理它們。 | DevOps 工程師 |
## 疑難排解
| 問題 | 解決方案 |
| --- | --- |
| 分支衝突 | GitHub Flow 模型可能發生的常見問題是，Hotfix 需要發生在生產環境中`feature`，但對應的變更需要發生在正在修改相同資源的 `bugfix`、 或 `hotfix`分支中。我們建議您經常將變更從 合併`main`到較低的分支，以避免合併到 時發生重大衝突`main`。 |
| 團隊成熟度 | GitHub Flow 鼓勵每日部署到更高的環境，採用真正的持續整合和持續交付 (CI/CD)。團隊必須具備工程成熟度，才能建置功能並為其建立自動化測試。團隊必須先執行詳盡的合併請求檢閱，才能核准變更。這可培養強大的工程文化，在開發過程中提升品質、責任和效率。 |
## 相關資源
本指南不包含 Git 的訓練；不過，如果您需要此訓練，網際網路上有許多可用的高品質資源。我們建議您從 [Git 文件](https://git-scm.com/doc)網站開始。
下列資源可協助您在 中完成 GitHub Flow 分支旅程 AWS 雲端。
**AWS DevOps 指引**
+ [AWS DevOps 指引](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
+ [AWS 部署管道參考架構](https://pipelines.devops.aws.dev/)
+ [什麼是 DevOps？](https://aws.amazon.com/devops/what-is-devops/)
+ [DevOps 資源](https://aws.amazon.com/devops/resources/)
**GitHub 流程指引**
+ [GitHub 流程快速入門教學課程 ](https://docs.github.com/en/get-started/using-github/github-flow)(GitHub)
+ [為什麼選擇 GitHub 流程？](https://githubflow.github.io/)
**其他資源**
+ [十二因素應用程式方法 ](https://12factor.net/)(12factor.net：//)