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

# IaC の分岐戦略
<a name="branching-strategies"></a>

一般的な Git 手法では、本番稼働用のプライマリトランクベース ( など`main`) ブランチ、開発ブランチ、機能ブランチを使用します。多くの組織は、Infrastructure as Code (IaC) にこの同じ設計をすぐに採用しています。ただし、Git の手法は、一般的なインフラストラクチャ設計パターンと直接互換性がありません。次の点を考慮してください。
+ アプリケーションには複数の環境があります。
  + 環境の例には、サンドボックス、開発、ステージング、本番環境などがあります。
+ 環境は緊密に結合されていません。
  + 本番環境は、多くの場合、ステージングデプロイの成功と密接に結びついています。
  + 本番環境とステージングは通常、開発環境から完全に切り離されます。
  + 開発は通常、サンドボックス環境から完全に切り離されます。
+ 各アプリケーションには、独自の環境標準セットがあります。
  + 多くのアプリケーションはサンドボックス環境を使用しません。
  + 一部のアプリケーションはステージング環境を必要とせず、代わりに Blue/Green デプロイ戦略を使用します。

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

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

このシナリオでは、次の潜在的な解決策を検討してください。
+ *最も一般的な解決策:* リポジトリに個別の`./environments`フォルダを設定することで、ターゲットのコード構造の場所におけるコードの繰り返しを増やす ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) を減らす) ことができます。これにより、環境のコードは同じリポジトリにありますが、分離されます。
+ 複雑な変数管理を使用して CI/CD プロセスを設定します。
+ 環境を別々のリポジトリに分割します。
+ *最小共通ソリューション:* 複数のトランクブランチを使用します。