IaC の分岐戦略

一般的な Git 手法では、本番稼働用のプライマリトランクベース ( などmain) ブランチ、開発ブランチ、機能ブランチを使用します。多くの組織は、Infrastructure as Code (IaC) にこの同じ設計をすぐに採用しています。ただし、Git の手法は、一般的なインフラストラクチャ設計パターンと直接互換性がありません。次の点を考慮してください。

• アプリケーションには複数の環境があります。

  • 環境の例には、サンドボックス、開発、ステージング、本番環境などがあります。

• 環境は緊密に結合されていません。

  • 本番環境は、多くの場合、ステージングデプロイの成功と密接に結びついています。

  • 本番環境とステージングは通常、開発環境から完全に切り離されます。

  • 開発は通常、サンドボックス環境から完全にデカップリングされます。

• 各アプリケーションには、独自の環境標準セットがあります。

  • 多くのアプリケーションはサンドボックス環境を使用しません。

  • 一部のアプリケーションはステージング環境を必要とせず、代わりに Blue/Green デプロイ戦略を使用します。

アプリケーションリポジトリが、トランクベースの方法論を使用する 3 つの環境を配信するシナリオを想像してみてください。開発環境は、 develop ブランチ、 stagingブランチへのステージング、および mainブランチへの本番稼働に関連付けられています。このアプリケーションでは、ソリューション内のトランジットゲートウェイを接続するために新機能が必要です。このトランジットゲートウェイは、別のチームやリポジトリによって管理されます。開発者は、機能ブランチにインフラストラクチャコードを書き込み、準備ができたらdevelopブランチにマージします。すべて正常に表示されます。

ただし、チャレンジが発生します。別の開発者には、別の機能用の個別のユーザーストーリーがあり、それを機能ブランチに書き込み、developブランチにマージします。2 番目の機能は、ステージングと本番稼働にマージする準備が整いました。ただし、組織内のリスク基準のため、元のトランジットゲートウェイ機能は準備ができていません。これで、すべての機能が本番環境への昇格をブロックされ、アプリケーションコードは事実上フリーズまたは破損します。

このシナリオでは、次の潜在的な解決策を検討してください。

• 最も一般的な解決策： リポジトリに個別の./environmentsフォルダを設定することで、ターゲットのコード構造の場所でコードの繰り返しを増やす (DRY を減らす) ことができます。これにより、環境のコードは同じリポジトリにありますが、分離されます。

• 複雑な変数管理を使用して CI/CD プロセスを設定します。

• 環境を別々のリポジトリに分割します。

• 最も一般的な解決策： 複数のトランクブランチを使用します。