翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# マルチアカウント DevOps 環境の Git 分岐戦略の選択
*Amazon Web Services* ([寄稿者](contributors.md))
*2024 年 2* 月 ([ドキュメント履歴](doc-history.md))
クラウドベースのアプローチに移行し、 でソフトウェアソリューションを提供することは、変革をもたらす AWS 可能性があります。これには、ソフトウェア開発ライフサイクルプロセスの変更が必要になる場合があります。通常、 の開発プロセスでは複数の AWS アカウント が使用されます AWS クラウド。DevOps プロセスとペアリングする互換性のある Git 分岐戦略を選択することは、成功するために不可欠です。組織に適した Git ブランチ戦略を選択すると、開発チーム全体で DevOps 標準とベストプラクティスを簡潔に伝達できます。Git 分岐は 1 つの環境で簡単にできますが、サンドボックス、開発、テスト、ステージング、本番環境など、複数の環境に適用すると混乱する可能性があります。複数の環境があると、DevOps 実装の複雑さが増します。
このガイドでは、組織がマルチアカウント DevOps プロセスを実装する方法を示す Git 分岐戦略のビジュアル図を提供します。ビジュアルガイドは、チームが Git 分岐戦略を DevOps プラクティスとマージする方法を理解するのに役立ちます。Gitflow、GitHub Flow、Trunk などの標準分岐モデルを使用してソースコードリポジトリを管理すると、開発チームが作業を調整するのに役立ちます。これらのチームは、インターネット上の標準の Git トレーニングリソースを使用して、これらのモデルと戦略を理解して実装することもできます。
DevOps の DevOps ベストプラクティスについては AWS、 AWS 「 Well-Architected」の[DevOps ガイダンス](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」を参照してください。このガイドを確認するときは、デューデリジェンスを使用して、組織に適した分岐戦略を選択します。一部の戦略は、他の戦略よりもユースケースに適している場合があります。
## 目的
このガイドは、複数の を持つ組織向けの DevOps ブランチ戦略の選択と実装に関するドキュメントシリーズの一部です AWS アカウント。このシリーズは、最初から要件、目標、ベストプラクティスに最適な戦略を適用して、 でのエクスペリエンスを合理化するのに役立つように設計されています AWS クラウド。このガイドには、組織が使用する継続的インテグレーションおよび継続的デリバリー (CI/CD) エンジンとテクノロジーフレームワークによって異なるため、DevOps 実行可能スクリプトは含まれていません。
このガイドでは、GitHub Flow、Gitflow、Trunk の 3 つの一般的な Git 分岐戦略の違いについて説明します。このガイドの推奨事項は、チームが組織の目標に沿った分岐戦略を特定するのに役立ちます。このガイドを読むと、組織の分岐戦略を選択できるようになります。戦略を選択したら、次のいずれかのパターンを使用して、開発チームでその戦略を実装できます。
+ [マルチアカウント DevOps 環境のトランク分岐戦略を実装する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html)
+ [マルチアカウント DevOps 環境に GitHub フロー分岐戦略を実装する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html)
+ [マルチアカウント DevOps 環境に Gitflow 分岐戦略を実装する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html)
ある組織、チーム、またはプロジェクトに何が適しているかは、他の組織、チーム、またはプロジェクトには適していない可能性があることに注意してください。Git 分岐戦略の選択は、チームサイズ、プロジェクト要件、コラボレーション、統合頻度、リリース管理の望ましいバランスなど、さまざまな要因によって異なります。
## CI/CD プラクティスの使用
AWS では、ソフトウェアリリースライフサイクルを自動化するプロセスである継続的インテグレーションと継続的デリバリー (CI/CD) を実装することをお勧めします。これにより、開発から本番環境に新しいコードを取得するために従来必要とされる手動 DevOps プロセスの多くまたはすべてが自動化されます。CI/CD パイプラインには、サンドボックス、開発、テスト、ステージング、および本番環境が含まれます。各環境では、CI/CD パイプラインはコードをデプロイまたはテストするために必要なインフラストラクチャをプロビジョニングします。CI/CD を使用することで、開発チームはコードを変更し、自動的にテストしてデプロイできます。CI/CD パイプラインは、開発チームのガバナンスとガードレールも提供します。機能の受け入れとデプロイには、一貫性、標準、ベストプラクティス、最小承認レベルが適用されます。詳細については、[「継続的インテグレーションと継続的デリバリーの実践 AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)」を参照してください。
このガイドで説明されているすべての分岐戦略は、CI/CD プラクティスに適しています。CI/CD パイプラインの複雑さは、分岐戦略の複雑さとともに増加します。例えば、Gitflow は、このガイドで説明されている最も複雑な分岐戦略です。この戦略の CI/CD パイプラインには、より多くのステップ (コンプライアンス上の理由など) が必要であり、複数の同時本番リリースをサポートする必要があります。CI/CD の使用は、分岐戦略の複雑さが増すにつれて、より重要になります。これは、CI/CD が開発チームのガードレールとメカニズムを確立し、開発者が定義されたプロセスを意図的または意図せずに回避できないためです。
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ソフトウェアパッケージを生成します。詳細については、「[Developer Tools on AWS](https://aws.amazon.com/products/developer-tools/)」を参照してください。