持續交付成熟度模型-讓構建成熟

讓構建成熟，首先要作的就是讓構建流程標準化而且不要在開發的機器上執行官方構建。不使用開發的機器作構建，意味着開發環境的改變不會對構建形成一些不可預料的污染。由於構建再也不在開發人員的工做空間執行，標準構建流程會有一部分定義怎樣從版本控制系統獲取源代碼以用來構建。這些用來構建的代碼可能來自於某個分支的最新代碼，或者某個打標籤的源代碼，或者其餘。最重要的是這個約定會一直被執行。有了這些實踐，團隊就達到了構建能力的 Base 級別。

任何一個開始標準持續集成的團隊都會再往前一步，將執行構建的步驟自動化，做爲自助構建或者每晚構建的一部分。構建服務器會描述構建機器，源代碼規則以及執行這些構建步驟，提供一個Beginner級別的受控的構建流程。一般這些自動構建被配置爲天天執行，但也有部分團隊會配置爲天天兩次或者更多。

在Intermediate 級別，團隊開始管理其餘軟件的依賴，例如子工程和三方庫。團隊再在使用約定的地方，取而代之的是使用依賴管理庫來管理這些工程依賴包，供每一次構建使用。一樣的，其餘構建依賴的構建產物也會放在依賴庫中，以便依賴管理工具能夠訪問到。全部的構建產物都會被存儲起來（在網盤上或者就在CI服務器上）按期清理，編號，以便於識別。

達到這種程度的控制，自動構建便很容易達到並且能夠提供有效的反饋。達到Intermediate的團隊採起持續編譯，自動構建會在開發提交代碼或者當依賴發生改變的時候被執行。較大的團隊會使用分佈式基礎設施來處理大量的併發構建。

更加規範的團隊將控制他們的構建流程。在這種環境下團隊將跟蹤構建流程的改動和源代碼及依賴的改動。修改構建流程須要批准，所以訪問官方構建機器和構建服務器的配置是受限的。在那些須要遵照制度或者企業持續交付變成了成產系統的團隊中，中級控制構建流程應該做爲其目標；對於其餘團隊而言，配置的安全性是可選的。

更大的組織或者那些尋找更快集成測試的團隊會期待作到Advanced級別。隨着天天構建次數的增長以及團隊的多樣化（例如須要Linux 和Windows構建機器），一個單獨的構建機器再也不夠用。能夠自動選擇機器和負載平衡的集羣就是必須的。At scale, traditional polling of source control systems looking for changes may place a performance strain on the ECD server as well as the source control system.在這種狀況下輪詢就應該被SCM在企業持續交付服務器上觸發構建的事件來代替，也可能經過webservice來觸發。

一些規範性規則更加嚴格而且指出組織必須可以執行之前版本的完美重建。這些組織將使用多樣的技術來保證精確的環境複製。有些當心翼翼的將準備編譯機器的腳本用版本管理起來,這些腳本所作的事情包括了從操做系統一直到運行構建以前。另一些使用基於虛擬機的快照，這些快照是實例化的，而且有本身的時鐘修改直到運行某個版本的構建的過程。咱們將這種級別的構建流程控制歸類爲Extreme級別。在某些管理級別，團隊會極力作到這些。然而，這些沒有提供太多價值的步驟對大多數團隊來講將會是痛苦的負擔.

另一些公司致力於使某些開發流不被「破壞」。他們使用封閉的提交策略來執行構建和測試任何提交源代碼的機會。若是有改變會致使build失敗，他們會拒絕這些提交。這種極端策略能夠提供一個穩定的簽出區域，可是也減緩了集成，同時引入了提交隊列和競態條件.