本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# IaC 的分支策略
<a name="branching-strategies"></a>

典型的 Git 方法使用主要幹線基礎 （例如 `main`) 分支進行生產、開發分支和功能分支。許多組織會立即為基礎設施採用與程式碼 (IaC) 相同的設計。不過，Git 方法與常見的基礎設施設計模式不直接相容。請考慮下列幾點：
+ 應用程式有數個環境。
  + 環境範例包括沙盒、開發、預備和生產。
+ 環境未緊密耦合。
  + 生產通常會與成功的預備部署緊密結合。
  + 生產和預備通常完全與開發環境分離。
  + 開發通常完全與沙盒環境分離。
+ 每個應用程式都有自己的一組環境標準。
  + 許多應用程式不使用沙盒環境。
  + 有些應用程式不需要預備環境，而是改用藍/綠部署策略。

假設應用程式儲存庫提供三個使用幹線型方法的環境。開發環境會繫結至`develop`分支、預備至`staging`分支，以及生產至`main`分支。對於此應用程式，需要新功能才能連接解決方案中的傳輸閘道，該閘道由另一個團隊和儲存庫管理。開發人員會在功能分支中寫入基礎設施程式碼，並在準備好時將其合併到`develop`分支。全部顯示良好。

不過，會出現挑戰。另一個開發人員有單獨的使用者案例，用於單獨的功能，將其寫入功能分支，並將其合併到`develop`分支。第二個功能現在已準備好合併為預備和生產。不過，由於組織中的風險條件，原始傳輸閘道功能尚未就緒。現在所有功能都會遭到封鎖，無法提升至生產環境，而且應用程式程式碼會有效凍結或損壞。

在此案例中，請考慮下列潛在解決方案：
+ *最常見的解決方案：*透過在儲存庫中設定個別`./environments`資料夾，在目標程式碼結構位置增加程式碼重複 （減少 [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself))。這可讓環境的程式碼位於相同的儲存庫中，但會解耦。
+ 設定具有複雜變數管理的 CI/CD 程序。
+ 將環境分隔為不同的儲存庫。
+ *最不常見的解決方案：*使用多個幹線分支。