出差在外，沒有及時更新blog。繼「構建」之後，今天再說一下企業持續整合成熟度模型的另乙個維度「部署」。在正文之前，還想再強調一點，即「這個模型本身是是工具箱裡的一件工具，並不一稱個斤兩的量器。」
部署
對於團隊來說，拋棄完全的手工過程，使用一些輔助指令碼或全過程指令碼化是乙個非常巨大的進步。縱觀整個行業，大多數團隊都會有一些輔助性指令碼，但有完全指令碼化部署方式的團隊較少，特別是在受控環境中（如試執行環境或生產環境）。因此，業內在這方面的平均水平應該是在入門級。
而中級團隊善於進行測試環境上的自動化部署。他們完全通過指令碼以一鍵部署的方式在部分或全部的測試環境中進行部署。這大大解放了部署工程師，而且減少了測試人員因等待部署而浪費的時間。就像持續構建是中級構建團隊的的特徵一樣，自動地部署到第乙個測試環境是在部署這一維度上中級成熟度的標誌。根據團隊的動態性，在不打斷測試人員工作的情況下，這種測試環境的自動部署應該發生在任何一次成功的持續構建之後或一天內的週期性部署。中級團隊的最後乙個特徵是：建立標準化的各種環境部署順序。雖然可能還會有一些環境變數，或兩種部署方式，但在某個版本的全生命週期中（即從生產到部署上線），越早地成功部署，就意味著後續部署成功的可能性更大。達到這個級別是很多團隊的目標。而高階團隊則把視線轉到受控環境或生產環境上。部署到生產環境（或發布）只要按一下滑鼠就行，生產環境發布就被自動觸發，並有相應的發布版本可以進行災難恢復。那些已經部署到內部測試環境的團隊應該將目標定位到「高階」：如果在所有環境中進行完全一致的部署過程，那麼在生產環境部署時，會極大地減少最後一刻失敗的可能性。高階級團隊的另乙個特徵是：將通過前面通過質量測試檢驗的版本全部自動地部署到部分或全部測試環境中。例如，得到測試經理的批准後，讓某個構建版本自動地安裝到壓力測試環境中。
而瘋狂級的團隊的目標是「持續部署」，即自動部署到生產環境中而無需手工干預：得到乙個版本後，自動部署到一系列的測試環境中。經過整個構建管道中的所有階段，並且能通過所有的測試後，自動部署該版本到生產環境中。某些.com應用可以在乙個小時之內就完成從原始檔控制到發布的整個過程。顯然，此時的自動化測試必須非常成熟，而且具有自動回滾和相應的監控手段。但是，在快節奏的競爭環境下，極其迅速地部署新功能也是乙個核心競爭力，可以減輕大規模功能變更的風險。
企業持續整合成熟度模型簡介之三 測試
測試 持續整合一直同自動化測試相關聯。這在馬丁福勒的文章或更早期steven mcconnell對日構建和冒煙測試的相關實踐描述中都有提及。而且在企業持續整合的領域中，我們會考慮很多種型別的自動化測試和手工測試。儘管如些，很多團隊在測試方面還是比較弱。很常見的乙個版本發布場景就是 某個團隊完成乙個版...
企業持續整合成熟度模型簡介之四 報告
報告 企業持續整合成熟度模型簡介之四 持續整合工具一直以來就負責報告最近一次構建的狀態。報告是持續整合的乙個至關重要的元素。在企業持續整合中，報告應包含所做軟體的相關質量和內容方面的資訊，以及與企業持續整合過程有關的度量資訊。沒有報告的團隊就象乙個沒有雷達的飛機在飛行。如果沒有人看測試結果的話，所有...
如何使用企業持續整合成熟度模型？
所有團隊在四個維度都達到統一的企業持續整合成熟度 是很困難的。企業持續整合在不同的條件和狀態下，應該考慮選擇不同的方向來實現或加強。為了表明這一點，下面是乙個企業的例子，提供了企業持續整合混合成熟度的解決方法。emeno 投資公司 平衡敏捷與控制 現狀分析 emeno採納企業持續整合的最高優先順序是...