所有團隊在四個維度都達到統一的企業持續整合成熟度 是很困難的。企業持續整合在不同的條件和狀態下，應該考慮選擇不同的方向來實現或加強。為了表明這一點，下面是乙個企業的例子，提供了企業持續整合混合成熟度的解決方法。
emeno 投資公司：平衡敏捷與控制
現狀分析：
emeno採納企業持續整合的最高優先順序是部署的自動化和可追蹤性。在有安全和審計保障的前提下，安全且按鍵即可的部署將大幅加快部署過程。所以，emeno以最快的速度達到了中級部署能力，從而減少了發布環節的壓力。即他們實現了測試環境的自動化部署。
下一步是將這種自動化擴充套件到生產環境的發布。由於這種發布非常敏感，最初進展緩慢。後來，基於業務方面的速度和審計要求，建立了乙個應用軟體，該軟體可以指定某個授權的人員來部署生產環境，因此，運營團隊被說服了。達到高階級部署成熟度後就很好地解決了問題，因為產生的錯誤少了，而且可以更快速地部署到生產環境中了。另一些中級構建的實現（比如依賴管理庫、專用的構建網格以及持續構建）不在關鍵路徑上，因些決定以後再考慮。而新手級的構建成熟度加上乙個持久的工件倉庫是個不錯的起點。當使用者和審計人員都沒有認真地對待測試質量時，一旦出現錯誤，那麼修改它的代價非常高。一旦部署被流程化後，團隊就可以根據測試的基本框架來排定構建的優先順序了。每個構建之後就進行基本的自動化回歸測試，讓測試人員有更多的時間做探索性測試，從而在更短的時間裡發現更多的問題。有了企業持續整合系統後，團隊認為，應該更早期來解決軟體安全問題。在建立企業持續整合環境之前，每個週期的後期，所有的發布都要有乙個安全檢查。由於看到自動化功能測試已經讓他們更早地發現了缺陷，他們決定，讓他們的安全檢查工具也做同樣的事情。現在，他們自己的靜態分析工作每天都做這種掃瞄。儘管安全掃瞄常常被認為是高階級技術，但對於emeno公司來說，由於他們的領域是金融，所以也是應當的。
對於emeno來說，通過維護部署的歷史資訊提供審計日誌，變更的歷史記錄以及測試結果是其最高優先順序。在建立企業持續整合環境之前，這種資訊也是有的，但分布在不同角色手中。而且由於使用的工具不同，所有的資料都是與工具相關的。emeno發現通過企業持續整合環境將這些孤立的資訊整合在一起，他們的工作更有效了。在第一次使用這個系統做演示時，他們可以直接向審計主管展示任意乙個部署的所有日誌資訊，同時還包括相關聯的修改、自動化測試結果和靜態安全分析資料。審計主管非常高興。
總之，emeno想要在受控的同時敏捷起來。對於他們來說，持續整合可以將他們端到端的構建週期做到了全過程跟蹤的環境中。這並不需要非常複雜的構建自動化，但卻需要成熟的部署和報告能力。
企業持續整合成熟度模型簡介之三 測試
測試 持續整合一直同自動化測試相關聯。這在馬丁福勒的文章或更早期steven mcconnell對日構建和冒煙測試的相關實踐描述中都有提及。而且在企業持續整合的領域中，我們會考慮很多種型別的自動化測試和手工測試。儘管如些，很多團隊在測試方面還是比較弱。很常見的乙個版本發布場景就是 某個團隊完成乙個版...
企業持續整合成熟度模型簡介之四 報告
報告 企業持續整合成熟度模型簡介之四 持續整合工具一直以來就負責報告最近一次構建的狀態。報告是持續整合的乙個至關重要的元素。在企業持續整合中，報告應包含所做軟體的相關質量和內容方面的資訊，以及與企業持續整合過程有關的度量資訊。沒有報告的團隊就象乙個沒有雷達的飛機在飛行。如果沒有人看測試結果的話，所有...
企業持續整合成熟度模型簡介之二 部署
出差在外，沒有及時更新blog。繼 構建 之後，今天再說一下企業持續整合成熟度模型的另乙個維度 部署 在正文之前，還想再強調一點，即 這個模型本身是是工具箱裡的一件工具，並不一稱個斤兩的量器。部署 對於團隊來說，拋棄完全的手工過程，使用一些輔助指令碼或全過程指令碼化是乙個非常巨大的進步。縱觀整個行業...