マルチアカウント DevOps 環境に Gitflow ブランチ戦略を実装する - AWS 規範ガイダンス

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

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

Amazon Web Services、Mike Stephens、Stephen DiCato、Abhilash Vinod、Tim Wondergem

概要

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

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

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

前提条件と制限事項

前提条件

アーキテクチャ

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

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

各ブランチと環境での Gitflow アクティビティのパネットスクエア。

Gitflow アプローチの 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 形式のテンプレートが格納されています。

  • (オプション) Gitflow プラグインは、Gitflow ブランチモデルの高レベルのリポジトリオペレーションを提供する Git 拡張機能のコレクションです。

コードリポジトリ

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

ベストプラクティス

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

エピック

タスク説明必要なスキル

標準の Gitflow プロセスを確認します。

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

  2. 開発者が、チケットを完了するためにコードを開発し、サンドボックス環境にコードを反復的にデプロイします。

    注記

    開発者は、オプションで sandbox ブランチを作成して、サンドボックス環境で自動ビルドまたはデプロイパイプラインを実行することもできます。

  3. 開発者がスカッシュマージを使用して、feature ブランチから develop ブランチへのマージリクエストを作成します。

  4. 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインは、develop ブランチを自動的に構築し、開発環境にデプロイします。

  5. (オプション) 開発者が、リリースアクティビティを続行する前に、追加の feature ブランチを develop ブランチに統合します。

  6. develop ブランチの機能をリリースする準備ができたら、開発者は develop ブランチから release/v<number> という名前の release ブランチを作成します。

  7. 開発者が release ブランチを構築します。これは、アーティファクトを公開して他の環境間で再利用できるようにするものです。

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

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

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

  11. 開発者が release ブランチを main ブランチにマージします。可能であれば、自動スクリプトを使用して早送りマージを実行してください。スカッシュマージは使用しないでください。

  12. 開発者が release ブランチを develop ブランチにマージします。可能であれば、自動スクリプトを使用して早送りマージを実行してください。スカッシュマージは使用しないでください。

DevOps エンジニア

ホットフィックス Gitflow プロセスを確認します。

  1. 開発者が main ブランチから hotfix ブランチを作成します。命名パターンは hotfix/<ticket>_<initials>_<short description> を使用します。

  2. 開発者が main ブランチから release ブランチを作成し、release/v<number> という名前を付けます。

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

  4. 開発者がスカッシュマージを使用して、hotfix ブランチから release/v<number> ブランチへのマージリクエストを作成します。

  5. 開発者が release ブランチを構築します。これは、アーティファクトを公開して他の環境間で再利用できるようにするものです。

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

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

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

  9. 開発者が release ブランチを main ブランチにマージします。可能であれば、自動スクリプトを使用して早送りマージを実行してください。スカッシュマージは使用しないでください。

  10. 開発者が release ブランチを develop ブランチにマージします。可能であれば、自動スクリプトを使用して早送りマージを実行してください。スカッシュマージは使用しないでください。

  11. 競合が検出されると、開発者はアラートを受け取り、マージリクエストにより競合を解決します。

DevOps エンジニア

バグ修正 Gitflow プロセスを確認します。

  1. 開発者が現在の release/v<number> ブランチから bugfix ブランチを作成します。命名パターンは bugfix/<ticket number>_<developer initials>_<descriptor> を使用します。

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

  3. 開発者がスカッシュマージを使用して、bugfix ブランチから release/v<number> ブランチへのマージリクエストを作成します。

  4. 開発者が release ブランチを構築します。これは、アーティファクトを公開して他の環境間で再利用できるようにするものです。

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

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

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

  8. 開発者が release ブランチを main ブランチにマージします。可能であれば、自動スクリプトを使用して早送りマージを実行してください。スカッシュマージは使用しないでください。

  9. 開発者が release ブランチを develop ブランチにマージします。可能であれば、自動スクリプトを使用して早送りマージを実行してください。スカッシュマージは使用しないでください。

  10. 競合が検出されると、開発者はアラートを受け取り、マージリクエストにより競合を解決します。

DevOps エンジニア

トラブルシューティング

問題ソリューション

ブランチの競合

Gitflow モデルで発生する可能性がある一般的な問題は、ホットフィックスを本番環境に適用する必要がある場合に、別のブランチによって同じリソースが変更されている下位環境でもそれに対応する変更を適用する必要があるという状況です。有効にする release ブランチは一度に 1 つだけにすることをお勧めします。複数のブランチが同時に有効になっている場合、環境内での変更が衝突し、ブランチを本番環境に移行できない可能性があります。

マージ

リリースをメインにマージし、できるだけ早く開発して、作業をプライマリブランチに統合する必要があります。

スカッシュマージ

スカッシュマージは、feature ブランチから develop ブランチにマージする場合にのみ使用します。上位のブランチでスカッシュマージを使用すると、変更を下位のブランチに戻してマージする際に問題が発生します。

関連リソース

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

以下のリソースは、 AWS クラウドで Gitflow ブランチを利用する際に役立ちます。

AWS DevOps ガイダンス

Gitflow ガイダンス

その他のリソース

Twelve-factor app methodology (12factor.net)