Steve Freeman

為每個環境建置不同版本的問題#

作者見過許多專案在建置過程中，會為不同的目標環境重寫部分程式碼以產生客製化的 binary。這種做法帶來許多問題：

• 增加不必要的複雜度
• 團隊可能無法在每次安裝時確保版本一致
• 最少需要建置多個幾乎相同的軟體副本，每個都得部署到正確的位置
• 搬動的部件越多，犯錯的機會就越多

作者也曾在一個團隊工作，每次屬性變更都需要完整的建置週期，測試人員只能等待。另一個團隊中，系統管理員堅持從頭重新建置生產版本，導致無法證明生產環境中的版本與通過測試的版本一致。

核心原則#

建置一個可識別的單一 binary，並在發布流程的所有階段中推廣它。 將環境特定的細節放在環境本身，例如元件容器中的已知檔案或路徑中。

環境配置的處理#

如果你的團隊有一個會改寫程式碼的建置流程，或把所有目標設定存在程式碼中，這表示設計不夠周全——沒有充分區分應用程式的核心功能與平台特定功能。更糟糕的是，團隊可能知道該怎麼做，卻無法排定優先順序來改變。

例外情況#

• 為資源需求差異極大的不同目標平台建置
• 處理太難立即修復的 legacy 系統——但應盡快開始漸進式改善

環境資訊也要版本控制#

環境配置損壞卻無法追溯變更是非常危險的。環境資訊應與程式碼分開版本控制，因為兩者的變更頻率和原因不同。有些團隊使用分散式版本控制系統（如 Bazaar、Git）來方便將生產環境的變更推回儲存庫。