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

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

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

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

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

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

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