以幹線為基礎的方法的環境完整性優勢

如同許多開發人員所知道的，程式碼中的一個變更有時可以建立浮水印效果 （美國科學家文章），其中看似無關的小偏差會引發鏈式反應，從而導致非預期的結果。開發人員接著必須進行完整調查，以探索根本原因。

當科學家進行實驗時，他們會將測試主體分成兩個群組：實驗群組和控制群組。目的是讓實驗群組和控制群組完全相同，但實驗中測試的物件除外。當實驗群組中發生未發生在控制群組中的事件時，唯一原因可能是要測試的物件。

將部署中的變更視為實驗群組，並將每個環境視為個別的控制群組。只有在控制項與上層環境相同時，在較低環境中進行測試的結果才可靠。環境越偏離，在上層環境中發現瑕疵的機率就越高。換句話說，如果程式碼變更將在生產環境中失敗，我們寧願它們先在 Beta 版中失敗，使其永遠不會進入生產環境。因此，應盡一切努力讓每個環境，從最低的測試環境到生產本身保持同步。這稱為環境完整性。

任何完整 CI/CD 程序的目標是儘早發現問題。使用以幹線為基礎的方法來保留環境完整性，實際上可以消除對 Hotfix 的需求。在以幹線為基礎的工作流程中，問題很少會先出現在生產環境中。

在 Gitflow 方法中，在 Hotfix 直接部署到上層環境之後，它會新增至開發分支。這會保留未來版本的修正。不過，Hotfix 是直接在應用程式的目前狀態之外開發和測試。即使 Hotfix 在生產環境中完美運作，當它與開發分支中較新的功能互動時，仍可能會出現問題。由於通常不需要部署 Hotfix，這會導致開發人員花費額外的時間嘗試將 Hotfix 改造到開發環境中。在許多情況下，這可能會導致重大的技術負債，並減少開發環境的整體穩定性。

當 環境中發生故障時，所有變更都會復原，讓環境回到其先前的狀態。程式碼庫的任何變更都應該從第一個階段再次啟動管道。當生產環境中確實發生問題時，修正也應通過整個管道。與使用此方法避免的問題相比，通過較低環境所需的額外時間通常可忽略。由於較低環境的整個目的是在到達生產環境之前攔截錯誤，因此透過 Gitflow 方法繞過這些環境是效率低且不必要的風險。