持續集成成熟度模型

參考原文: http://my.oschina.net/u/134516/blog/495477

 成熟度模型的級別

1. Base： 在Base這個級別，咱們剛剛跟「模型」沾邊，咱們的團隊再也不是全部的流程都要手動去操做。

2. Beginner: 團隊開始認真採用一些企業持續交付的實踐，可是仍是在剛起步的水平

3. Intermediate: 實踐已經多少成熟一些，會發布更少的錯誤，而且更加高效。 對於大多數團隊來講，這個基本的實踐可能已經足夠了

4. Advanced：團隊所作的已經遠遠超出同行業其餘團隊，並且效率很是高，可以預防錯誤的發生。

5. Extreme: 要達到這個級別裏的要求，其代價是很是昂貴的，但對某些團隊來講，這是他們的目標。換句話說，大多數組織認爲除非瘋了纔會實現到這個級別，然而另外一少部分則認爲不實現到這個級別纔是瘋了呢。

構建，部署，測試和報告

這幾個主題覆蓋了端到端的構建生命週期的基本要素，從源代碼到生成環境的軟件的過程。

構建

  已開發人員爲中心的持續集成，其關鍵在於構建軟件的快速反饋。在企業開發中，構建管理和可控的構建流程是很是關鍵的因素。一個可控的構建流程規範了獲取源代碼，編譯，打包以及存儲等一系列步驟。

大多數工程開始的時候是在開發的機器上去進行構建，並無一個規範的流程。這個開發用IDE來構建，而另外一個則用構建腳本。一些極不成熟的團隊會用這些構建結果來測試甚至發佈到生產環境。這樣缺乏控制致使的結果在不少團隊迅速顯現，他們開始尋找更好的選擇。

    咱們的目標應該是：基於提交的構建，有依賴倉庫，安全的配置。

    詳見：http://my.oschina.net/u/134516/blog/496267

部署

發佈是將軟件挪到一個可測試，用戶能夠訪問，或者準備發送給客戶的地方。對於Web應用來講，這可能意味着將應用安裝在一系列web服務器上，同事更新數據庫或者靜態存儲服務器。對於視頻遊戲控制端，一次部署應該是將遊戲安裝到測試機器上，而生產環境的部署還可能涉及到「stamping a gold ISO to deliver to the publisher」（不太懂遊戲的發佈沒法正確翻譯出來...）

部署一開始大多數是手動的流程。將構建的地址發送給部署工程師，而後部署工程師將構建結果挪到目標機器，經過執行安裝程序完成部署。這樣將致使部署過程慢而且部署失敗率高。工程師經常被迫在晚上和週末在生產系統和測試系統執行有風險的部署，這個過程當中，系統是不能別其餘人用的，然而極可能就有測試正在使用該系統。更糟糕的是，不一樣環境的部署可能有不一樣的流程，這樣很難保證在一個環境的成功部署能夠在下一個環境中一樣成功。

部署自動化的目標：Test Gated Automation Promotions，Database Deployments，Coordinated SOA/multi-tier deploys.

測試

持續集成和交付長時間來已經某種程度上和自動化測試聯繫在一塊兒。這個在Martin Fowler的開創性文章和Steve McConnell對每日構建和冒煙測試的早期實踐描述中被證明。事實上，這主要是咱們想在執行常規構建和部署的時候可以很快提供質量問題的反饋。企業持續交付的範圍內,多種類型的自動化測試和手工測試都被考慮到了。

諷刺的是，不少擅長構建和部署的團隊，在測試上卻很弱。他們執行構建，使其經過一些基本的手動測試，而後就發佈出去。應用的某些部分常常被破壞，而新的功能也沒能被充分測試。隨着團隊在測試領域的逐漸成熟，他們能夠很快返現問題，提升了生產力和信心。

測試自動化目標：Some Static Analysis（靜態分析），Automated Functional Tests run nightly（每晚執行自動化功能測試）

報告

從歷史上看，持續集成工具主要關注於報告最近構建的狀態。更普遍的觀點上來看，報告是企業持續交付的關鍵因素。企業持續交付的報告涵蓋了軟件質量和內容信息以及企業持續發佈流程的相關指標。

沒有報告的團隊是盲目的前進。若是沒有人能審查結果，那麼全部的測試都是無用的。一樣，沒有被提煉成易理解信息的堆積數據也是沒有用的。成熟的團隊的報告會愈來愈可視化，會暴露出愈來愈多的有用信息。

報告成熟度的目標：Report Trending（報告趨勢）