Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

マルチアカウント DevOps 環境に GitHub Flow 分岐戦略を実装する - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

マルチアカウント DevOps 環境に GitHub Flow 分岐戦略を実装する

作成者: Mike Stephens (AWS) と Abhilash Vinod (AWS)

概要

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

このパターンは、複数の を持つ組織の DevOps 分岐戦略の選択と実装に関するドキュメントシリーズの一部です AWS アカウント。このシリーズは、クラウドでのエクスペリエンスを効率化するために、最初から正しい戦略とベストプラクティスを適用するのに役立つように設計されています。GitHub Flow は、組織が使用できる分岐戦略の 1 つにすぎません。このドキュメントシリーズでは、Trunk および Gitflow 分岐モデルについても説明します。まだ行っていない場合は、このパターンのガイダンスを実装する前に、マルチアカウント DevOps 環境の Git 分岐戦略の選択を確認することをお勧めします。デューデリジェンスを使用して、組織に適した分岐戦略を選択してください。

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

前提条件と制限

前提条件

  • Git、インストール済み。これはソースコードリポジトリツールとして使用されます。

  • Draw.io、インストール済み。このアプリケーションは、図を表示および編集するために使用されます。

アーキテクチャ

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

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

各ブランチと環境における GitHub Flow アクティビティの Punnett 二乗。

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

自動化とスケール

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

AWS は、CI/CD パイプラインの構築を支援するように設計された一連の開発者サービスを提供します。例えば、 AWS CodePipelineは、リリースパイプラインを自動化してアプリケーションとインフラストラクチャを迅速かつ確実に更新できるようにするフルマネージド型の継続的デリバリーサービスです。 は、ソースコードをAWS CodeBuildコンパイルし、テストを実行し、ready-to-deployソフトウェアパッケージを生成します。詳細については、「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 形式のテンプレートが含まれています。

  • Figurema は、コラボレーション用に設計されたオンライン設計ツールです。コードリポジトリには、Gimma の .fig 形式のテンプレートが含まれています。

コードリポジトリ

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

ベストプラクティス

AWS Well-Architected DevOps ガイダンスのベストプラクティスと推奨事項に従い、マルチアカウント DevOps 環境の Git 分岐戦略を選択します。これらは、GitHub フローベースの開発の効果的な実装、コラボレーションの促進、コード品質の向上、開発プロセスの合理化に役立ちます。

エピック

タスク説明必要なスキル

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

  1. サンドボックス環境では、開発者はfeatureブランチからmainブランチを作成し、命名パターン を使用しますfeature/<ticket>_<initials>_<short description>

  2. デベロッパーは、featureブランチに 1 つ以上のコミットを追加します。各コミットは個別の変更または改善を表します。

  3. 開発者はマージリクエスト (MR) を開き、変更をmainブランチにマージします。これにより、レビュープロセスが開始されます。

  4. レビュープロセス中に、デベロッパーはコードの変更について話し合い、フィードバックを提供します。目標は、変更が高品質で、プロジェクトの標準を確実に満たすことです。

  5. デベロッパーがマージリクエストを作成すると、自動ビルドプロセスが開始され、featureブランチの変更が開発環境にデプロイされます。

  6. 自動テストでは、マージリクエストにカプセル化された変更の整合性と品質を検証します。マージリクエストを完了するには、ビルドの成功、デプロイの成功、テストの成功が必要です。

  7. レビュープロセスが完了すると、変更はmainブランチにマージされます。

  8. 承認者は、テスト環境へのリリースアーティファクトのデプロイを手動で承認します。

  9. 承認者は、リリースアーティファクトのステージング環境へのデプロイを手動で承認します。

  10. 承認者は、リリースアーティファクトの本番環境へのデプロイを手動で承認します。

DevOps エンジニア

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

  1. 開発者はbugfixブランチからmainブランチを作成し、命名パターン を使用しますbugfix/<ticket number>_<developer initials>_<descriptor>

  2. 開発者は問題を修正し、修正をコミットして、bugfixブランチを構築します。

  3. デベロッパーはマージリクエストを開き、bugfixブランチをmainブランチにマージします。これにより、レビュープロセスが開始されます。

  4. レビュープロセス中に、デベロッパーはコードの変更について話し合い、フィードバックを提供します。

  5. レビューが完了し、承認されると、デベロッパーはbugfixブランチのマージリクエストをmainブランチに完了します。

  6. 承認者は、リリースアーティファクトの上位環境へのデプロイを手動で承認します。

DevOps エンジニア

修正プログラム GitHub フロープロセスを確認します。

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

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

DevOps エンジニア

GitHub Flow ワークフローの確認

タスク説明必要なスキル

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

  1. サンドボックス環境では、開発者はfeatureブランチからmainブランチを作成し、命名パターン を使用しますfeature/<ticket>_<initials>_<short description>

  2. デベロッパーは、featureブランチに 1 つ以上のコミットを追加します。各コミットは個別の変更または改善を表します。

  3. 開発者はマージリクエスト (MR) を開き、変更をmainブランチにマージします。これにより、レビュープロセスが開始されます。

  4. レビュープロセス中に、デベロッパーはコードの変更について話し合い、フィードバックを提供します。目標は、変更が高品質で、プロジェクトの標準を確実に満たすことです。

  5. デベロッパーがマージリクエストを作成すると、自動ビルドプロセスが開始され、featureブランチの変更が開発環境にデプロイされます。

  6. 自動テストでは、マージリクエストにカプセル化された変更の整合性と品質を検証します。マージリクエストを完了するには、ビルドの成功、デプロイの成功、テストの成功が必要です。

  7. レビュープロセスが完了すると、変更はmainブランチにマージされます。

  8. 承認者は、テスト環境へのリリースアーティファクトのデプロイを手動で承認します。

  9. 承認者は、リリースアーティファクトのステージング環境へのデプロイを手動で承認します。

  10. 承認者は、リリースアーティファクトの本番環境へのデプロイを手動で承認します。

DevOps エンジニア

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

  1. 開発者はbugfixブランチからmainブランチを作成し、命名パターン を使用しますbugfix/<ticket number>_<developer initials>_<descriptor>

  2. 開発者は問題を修正し、修正をコミットして、bugfixブランチを構築します。

  3. デベロッパーはマージリクエストを開き、bugfixブランチをmainブランチにマージします。これにより、レビュープロセスが開始されます。

  4. レビュープロセス中に、デベロッパーはコードの変更について話し合い、フィードバックを提供します。

  5. レビューが完了し、承認されると、デベロッパーはbugfixブランチのマージリクエストをmainブランチに完了します。

  6. 承認者は、リリースアーティファクトの上位環境へのデプロイを手動で承認します。

DevOps エンジニア

修正プログラム GitHub フロープロセスを確認します。

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

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

DevOps エンジニア

トラブルシューティング

問題ソリューション

ブランチの競合

GitHub Flow モデルで発生する可能性がある一般的な問題は、本番環境で修正プログラムを行う必要があるが、同じリソースが変更されている featurebugfix、または hotfixブランチで対応する変更を行う必要があることです。へのマージ時に大きな競合を避けるためmain、 からの変更を頻繁に下位ブランチにマージすることをお勧めしますmain

チーム成熟度

GitHub Flow は、真の継続的インテグレーションと継続的デリバリー (CI/CD) を採用して、より高い環境への毎日のデプロイを促進します。機能を構築し、自動化テストを作成するには、チームがエンジニアリングの成熟度を持っていることが不可欠です。チームは、変更が承認される前に、完全なマージリクエストのレビューを実行する必要があります。これにより、開発プロセスの品質、説明責任、効率を高める強固なエンジニアリング文化が促進されます。

関連リソース

このガイドには Git のトレーニングは含まれていませんが、このトレーニングが必要な場合は、インターネットで利用できる高品質のリソースが多数あります。Git ドキュメントサイトから始めることをお勧めします。

以下のリソースは、 の GitHub Flow 分岐ジャーニーに役立ちます AWS クラウド。

AWS DevOps ガイダンス

GitHub フローガイダンス

その他のリソース

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.