概要前提条件と制限事項アーキテクチャツールベストプラクティスエピックトラブルシューティング関連リソース

マルチアカウント DevOps 環境に GitHub フローブランチ戦略を実装する

Amazon Web Services、Mike Stephens と Abhilash Vinod

概要

ソースコードリポジトリを管理する場合、さまざまな分岐戦略が、開発チームが使用するソフトウェア開発およびリリースプロセスに影響します。一般的な分岐戦略の例としては、Trunk、GitHub Flow、Gitflow などがあります。これらの戦略では異なるブランチが使用され、各環境で実行されるアクティビティは異なります。DevOps プロセスを実装している組織は、ビジュアルガイドを活用して、これらの分岐戦略の違いを理解できます。組織でこのビジュアルを使用すると、開発チームが作業を調整し、組織の標準に従うのに役立ちます。このパターンでは、このビジュアルを提供し、組織に GitHub フローブランチ戦略を実装するプロセスについて説明します。

このパターンは、複数のを持つ組織の DevOps ブランチ戦略の選択と実装に関するドキュメントシリーズの一部です AWS アカウント。このシリーズは、クラウドでのエクスペリエンスを効率化するために、最初から正しい戦略とベストプラクティスを適用するのに役立つように設計されています。GitHub フローは、組織で使用できるブランチ戦略の 1 つです。このドキュメントシリーズでは、トランクおよび Gitflow ブランチモデルについても説明します。まだ確認していない場合は、このパターンのガイダンスを実装する前に、「Choosing a Git branching strategy for multi-account DevOps environments」を確認することをお勧めします。デューデリジェンスを使用して、組織に適したブランチ戦略を選択してください。

このガイドでは、組織が GitHub フロー戦略を実装する方法を記した図を示します。「AWS Well-Architected DevOps Guidance」でベストプラクティスを確認することをお勧めします。このパターンには、DevOps プロセスの各段階に推奨されるタスク、ステップ、制限が含まれます。

前提条件と制限事項

前提条件

「インストール済み」Git これはソースコードリポジトリツールとして使用されます。
Draw.io がインストールされていること。このアプリケーションは、図の表示や編集のために使用されます。

アーキテクチャ

ターゲットアーキテクチャ

次の図は、パネットスクエア (Wikipedia) のように使用できます。垂直軸のブランチを水平軸の AWS 環境と並べて、各シナリオで実行するアクションを決定します。数字は、ワークフロー内のアクションのシーケンスを示します。この例では、feature ブランチから本番環境へのデプロイまでを示します。

GitHub Flow アプローチの AWS アカウント、環境、ブランチの詳細については、「マルチアカウント DevOps 環境の Git ブランチ戦略の選択」を参照してください。

自動化とスケール

継続的インテグレーションと継続的デリバリー (CI/CD) は、ソフトウェアリリースライフサイクルを自動化するプロセスです。CI/CD は、初期コミットから本番環境に新しいコードを移行するために従来必要とされていた手動プロセスの多く、またはすべてを自動化します。CI/CD パイプラインには、サンドボックス、開発、テスト、ステージング、および本番環境が含まれます。各環境で、CI/CD パイプラインはコードをデプロイまたはテストするために必要なインフラストラクチャをプロビジョニングします。CI/CD を使用することで、開発チームはコードを変更し、自動的にテストとデプロイを行うことができます。CI/CD パイプラインは、機能の受け入れとデプロイに一貫性、標準、ベストプラクティス、最小限の承認レベルを適用することで、開発チームのガバナンスとガードレールも提供します。詳細については、「AWSでの継続的インテグレーションと継続的デリバリーの実践」を参照してください。

AWS は、CI/CD パイプラインの構築を支援するように設計された一連の開発者サービスを提供します。例えば、AWS CodePipeline は完全マネージド型の継続的デリバリーサービスであり、リリースパイプラインを自動化して、迅速かつ信頼性の高いアプリケーションとインフラストラクチャの更新を実現します。AWS CodeBuild はソースコードをコンパイルし、テストを実行し、すぐにデプロイできるソフトウェアパッケージを生成します。詳細については、「Developer Tools on AWS」を参照してください。

ツール

AWS サービスとツール

AWS には、このパターンの実装に使用できる一連の開発者サービスが用意されています。

スケーラビリティが高く、フルマネージド型のアーティファクトリポジトリサービスである AWS CodeArtifact を使用すると、アプリケーション開発に使用するソフトウェアパッケージを保存および共有できます。
AWS CodeBuild は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
AWS CodeDeploy は、Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスインスタンス、 AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。
AWS CodePipeline は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。

その他のツール

Draw.io Desktop は、フローチャートと図を作成するためのアプリケーションです。コードリポジトリには、Draw.io 用の .drawio 形式のテンプレートが格納されています。
Figma は、コラボレーション用に設計されたオンライン設計ツールです。コードリポジトリには、Figma 用の .fig 形式のテンプレートが格納されています。

コードリポジトリ

このパターンにおける図のソースファイルは、Git Branching Strategy for GitHub Flow GitHub リポジトリで入手できます。ここには、PNG、draw.io、および Figma 形式のファイルが含まれます。これらの図は、組織のプロセスに対応するように変更できます。

ベストプラクティス

「AWS Well-Architected DevOps Guidance」と「Choosing a Git branching strategy for multi-account DevOps environments」のベストプラクティスと推奨事項に従ってください。これらは、GitHub フローベースの開発を効果的に実装し、コラボレーションを促進し、コード品質を高め、開発プロセスを合理化するのに役立ちます。

エピック

タスク説明必要なスキル

タスク	説明	必要なスキル
標準の GitHub フロープロセスを確認する。	サンドボックス環境で、開発者が `main` ブランチから `feature` ブランチを作成します。命名パターンは `feature/<ticket>_<initials>_<short description>` を使用します。開発者が `feature` ブランチに 1 つ以上のコミットを追加します。それぞれが個別の変更または改善を表します。開発者がマージリクエスト (MR) を開き、変更を `main` ブランチにマージします。これにより、レビュープロセスが開始されます。レビュープロセス中に、開発者はコードの変更について話し合い、フィードバックを提供します。レビュープロセスの目標として、変更が高品質でプロジェクトの基準を満たしていることを保証します。開発者がマージリクエストを作成すると、自動ビルドプロセスが開始され、`feature` ブランチの変更が開発環境にデプロイされます。自動テストにより、マージリクエストにカプセル化された変更の整合性と品質が検証されます。マージリクエストを完了するには、ビルドの成功、デプロイの成功、テストの成功が必要です。レビュープロセスが完了すると、変更が `main` ブランチにマージされます。承認者が、テスト環境へのリリースアーティファクトのデプロイを手動で承認します。承認者が、ステージ環境へのリリースアーティファクトのデプロイを手動で承認します。承認者が、本番環境へのリリースアーティファクトのデプロイを手動で承認します。	DevOps エンジニア
バグ修正 GitHub フロープロセスを確認する。	開発者が `main` ブランチから `bugfix` ブランチを作成します。命名パターンは `bugfix/<ticket number>_<developer initials>_<descriptor>` を使用します。開発者が問題を修正し、修正をコミットして、`bugfix` ブランチを構築します。開発者がマージリクエストを開き、`bugfix` ブランチを `main` ブランチにマージします。これにより、レビュープロセスが開始されます。レビュープロセス中に、開発者はコードの変更について話し合い、フィードバックを提供します。レビューが完了して承認されたら、開発者は `bugfix` ブランチから `main` ブランチへのマージリクエストを完了します。承認者が、リリースアーティファクトの上位環境へのデプロイを手動で承認します。	DevOps エンジニア
ホットフィックス GitHub フロープロセスを確認する。	GitHub フローは、継続的な配信が可能になり、コードの変更が上位環境に頻繁かつ確実にデプロイされるように設計されています。重要なのは、すべての `feature` ブランチがいつでもデプロイ可能であることです。 `Hotfix` ブランチは、`feature` ブランチや `bugfix` ブランチに似ていますが、これらの他のブランチと同じプロセスに従うことができます。ただし、緊急性を考慮すると、通常はホットフィックスの優先度が高くなります。チームのポリシーと状況の緊急性によっては、プロセスの特定のステップが迅速化される可能性があります。例えば、ホットフィックスのコードレビューは高速で追跡される場合があります。そのため、ホットフィックスプロセスでは機能プロセスとバグ修正プロセスが並列で扱われますが、ホットフィックスの緊急性により、手続きの遵守に変更が必要となる場合があります。ホットフィックスが効率的かつ安全に処理されるように、ホットフィックスの管理に関するガイドラインを確立することが重要です。	DevOps エンジニア

標準の GitHub フロープロセスを確認する。

サンドボックス環境で、開発者が main ブランチから feature ブランチを作成します。命名パターンは feature/<ticket>_<initials>_<short description> を使用します。
開発者が feature ブランチに 1 つ以上のコミットを追加します。それぞれが個別の変更または改善を表します。
開発者がマージリクエスト (MR) を開き、変更を main ブランチにマージします。これにより、レビュープロセスが開始されます。
レビュープロセス中に、開発者はコードの変更について話し合い、フィードバックを提供します。レビュープロセスの目標として、変更が高品質でプロジェクトの基準を満たしていることを保証します。
開発者がマージリクエストを作成すると、自動ビルドプロセスが開始され、feature ブランチの変更が開発環境にデプロイされます。
自動テストにより、マージリクエストにカプセル化された変更の整合性と品質が検証されます。マージリクエストを完了するには、ビルドの成功、デプロイの成功、テストの成功が必要です。
レビュープロセスが完了すると、変更が main ブランチにマージされます。
承認者が、テスト環境へのリリースアーティファクトのデプロイを手動で承認します。
承認者が、ステージ環境へのリリースアーティファクトのデプロイを手動で承認します。
承認者が、本番環境へのリリースアーティファクトのデプロイを手動で承認します。

DevOps エンジニア

バグ修正 GitHub フロープロセスを確認する。

開発者が main ブランチから bugfix ブランチを作成します。命名パターンは bugfix/<ticket number>_<developer initials>_<descriptor> を使用します。
開発者が問題を修正し、修正をコミットして、bugfix ブランチを構築します。
開発者がマージリクエストを開き、bugfix ブランチを main ブランチにマージします。これにより、レビュープロセスが開始されます。
レビュープロセス中に、開発者はコードの変更について話し合い、フィードバックを提供します。
レビューが完了して承認されたら、開発者は bugfix ブランチから main ブランチへのマージリクエストを完了します。
承認者が、リリースアーティファクトの上位環境へのデプロイを手動で承認します。

DevOps エンジニア

ホットフィックス GitHub フロープロセスを確認する。

GitHub フローは、継続的な配信が可能になり、コードの変更が上位環境に頻繁かつ確実にデプロイされるように設計されています。重要なのは、すべての feature ブランチがいつでもデプロイ可能であることです。

Hotfix ブランチは、feature ブランチや bugfix ブランチに似ていますが、これらの他のブランチと同じプロセスに従うことができます。ただし、緊急性を考慮すると、通常はホットフィックスの優先度が高くなります。チームのポリシーと状況の緊急性によっては、プロセスの特定のステップが迅速化される可能性があります。例えば、ホットフィックスのコードレビューは高速で追跡される場合があります。そのため、ホットフィックスプロセスでは機能プロセスとバグ修正プロセスが並列で扱われますが、ホットフィックスの緊急性により、手続きの遵守に変更が必要となる場合があります。ホットフィックスが効率的かつ安全に処理されるように、ホットフィックスの管理に関するガイドラインを確立することが重要です。

DevOps エンジニア

トラブルシューティング

問題ソリューション

問題	ソリューション
ブランチの競合	GitHub フローモデルで発生する可能性がある一般的な問題は、ホットフィックスを本番環境に適用する必要がある場合に、同じリソースが変更されている `feature`、`bugfix`、または `hotfix` ブランチでもそれに対応する変更を適用する必要があるという状況です。`main` へのマージ時に大きな競合が発生するのを避けるため、`main` の変更を下位ブランチに頻繁にマージすることをお勧めします。
チームの成熟度	GitHub フローは、真の継続的インテグレーションと継続的デリバリー (CI/CD) により、上位環境への日々のデプロイを促進します。機能を構築し、機能の自動化テストを作成するには、チームのエンジニアリングスキルが成熟している必要があります。チームは、変更が承認される前に、マージリクエストの詳細なレビューを実行する必要があります。これにより、開発プロセスの品質、説明責任、効率性を促進する堅牢なエンジニアリング文化が育まれます。

ブランチの競合

GitHub フローモデルで発生する可能性がある一般的な問題は、ホットフィックスを本番環境に適用する必要がある場合に、同じリソースが変更されている feature、bugfix、または hotfix ブランチでもそれに対応する変更を適用する必要があるという状況です。main へのマージ時に大きな競合が発生するのを避けるため、main の変更を下位ブランチに頻繁にマージすることをお勧めします。

チームの成熟度

GitHub フローは、真の継続的インテグレーションと継続的デリバリー (CI/CD) により、上位環境への日々のデプロイを促進します。機能を構築し、機能の自動化テストを作成するには、チームのエンジニアリングスキルが成熟している必要があります。チームは、変更が承認される前に、マージリクエストの詳細なレビューを実行する必要があります。これにより、開発プロセスの品質、説明責任、効率性を促進する堅牢なエンジニアリング文化が育まれます。