模板
教程
環境
性能
功能
管理
持續集成實踐成熟度模型
1 概述
持續集成從“配置管理”、“構建”、“測試”、“部署及發布”及“團隊習慣”5個緯度考察其成熟度，每個維度都有5個級別，分別是“入門”、“新手”、“中等”、“進階”和“瘋狂”。目前在各個維度上，行業的平均水平集中在“入門”和“新手”兩個級別。
評估時各級別之間不能越級，就是說即使“新手”中個別條目已經做到了，但如果“入門”中有條目沒有做到，也只能評為“入門”級。
該模型的主要目的是為了更好地幫助團隊認識現狀，同時了解改進的方向。該模型是對持續集成主要維度的簡單衡量，背后可能有一些并不適合團隊的假設，且并未對每個條目做細致解釋，為獲得團隊持續集成工作的有針對性的全面評估，請聯系PMO部門。
由于技術和項目的差異性，不同團隊達到同一級別需要付出的努力可能差異很大，獲得的收益也有區別，因此不適宜利用此模型在團隊間進行比較。
2 配置管理維度
入門：
使用版本管理工具
使用私有分支
功能測試Case在本地管理
生產代碼被版本管理
每天提交代碼，并寫Comment。
新手：
應用在最小工作單元完成后即可集成的分支策略
所有構建、測試及部署腳本都被版本管理
所有測試代碼和數據被集中管理
測試環境中的應用配置被版本管理
代碼簽入的Comment清楚達意，含有必要的Metadata，比如Bug號等。
RD使用完全標準的開發環境，沒有僅供自己使用的腳本、數據或測試環境等。
中等：
測試代碼與生產代碼同源
生產環境中的應用配置被版本管理
持續集成平臺運行的腳本被版本管理，無需登錄平臺修改腳本。
每次構建均有版本追溯，無需重新從源碼構建歷史版本。
Qa使用標準的開發測試環境
數據庫被版本管理
功能測試數據被版本管理
進階：
沒有僅在團隊成員本地保存的任何項目資產。
RD和QA使用一致的開發測試環境。
瘋狂：
開發、測試、生產環境被版本管理，可以一鍵克隆。
所有測試數據被版本管理
通過下面問題進一步了解團隊的配置管理現狀：
使用何種分支管理策略?
團隊成員簽入代碼的頻率和內容，Comment的質量如何?
一個RD在全新的機器上建立完整的工作環境要經歷那些步驟?
一個QA在全新的機器上建立完整的工作環境要經歷那些步驟?
RD和QA的工作環境有什么區別?
RD之間的工作環境有什么區別?
Qa之間的工作環境有什么區別?
測試數據是怎么管理的?
RD是否在沙盒中開發?如果不是，有那些依賴?
本地和平臺構建腳本是如何管理的?
測試環境和生產環境的應用配置是如何管理的?
測試工具和測試Case是如何管理的?
測試運行的環境依賴有那些?是否每個人在自己的工作環境中都可以方便運行?
所有團隊成員是否使用相同的腳本做本地構建?
團隊成員有那些私有的代碼，腳本和預先部署的環境?
3 構建維度
入門：
有幫助腳本分別執行各構建步驟
階段構建，例如Nightly Build或Weekly Build。
Shell腳本作為自動化構建開發腳本
新手：
代碼簽入后即運行包含自動化測試的構建過程
構建結果被有效通知團隊
所有人都知道如何運行本地構建
基礎構建過程不再有突出的環境問題
通過自動化構建腳本完成自動化構建任務。
專人維護構建環境。
中等
在本地和平臺中運行自動化冒煙測試
在平臺中運行功能測試全集和性能測試。
充分利用多臺機器運行多個構建。
構建過程集成了詳細的報告。
能夠靈活配置各構建階段的具體任務。
通過腳本同步及升級各個構建機器中的環境依賴
進階
構建步驟被充分優化
構建過程可以對報告做分析，并記錄關鍵指標的趨勢，并進行改進。
充分利用多臺機器做單個構建任務。
在全新的開發環境中簽出項目，通過一個腳本即可構建完整的開發和測試環境并成功產出部署包。
瘋狂
運行時間超過限制即失敗。
通過下面問題進一步了解團隊的構建現狀：
如何管理編譯依賴?
如何管理模塊版本依賴?
編譯的時間是多長?
每個人的構建環境和方法是否一致?
自動化構建的具體步驟?
自動化構建失敗的主要原因是什么?
是否使用了Build Grid?如何用的?
如何管理Grid中的各臺機器?如何同步和更新環境?
本地構建的內容?什么時候運行?要多長時間?
使用那個CI平臺?如何配置的?
如何調整構建中包含的內容?
4 測試維度
在其它緯度中也有一些與測試相關的條目，可參考。
入門：
有部分自動化功能測試
在項目后期集中測試
僅有少量的單元測試，尚未發揮明顯作用。
新手：
最小工作單元包含手工測試。
積累一定量的單元測試，團隊已從中受益。
構建時運行自動回歸測試。
原文轉自：http://www.anti-gravitydesign.com
