持續整合實踐成熟度模型

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 測試維度
在其它緯度中也有一些與測試相關的條目，可參考。

入門：

 有部分自動化功能測試

 在專案後期集中測試

 利用缺陷跟蹤系統管理缺陷

 僅有少量的單元測試，尚未發揮明顯作用。

新手：

 最小工作單元包含手工測試。

 積累一定量的單元測試，團隊已從中受益。

 構建時執行自動迴歸測試。

 有人工參與的提測過程。

 自動化功能測試具備一定數量並起到了一定保障作用。

 自動化功能測試全集頻繁執行，不少於一天一次。

中等：

 最小工作單元包含自動化測試工作。

 不同層級的自動化測試發揮質量保障作用。

 靜態程式碼檢查及相關舉措

 可以在構建中推薦提測版本

 自動化提測

進階：

 普遍的單元測試，發揮良好效果。

 自動化測試覆蓋率較高，測試工作被有效分散在開發階段。

 手工測試大部分屬於探索性測試。

瘋狂：

 100%單元測試覆蓋率。

 自動化測試提供信心十足的質量保證，構建成功後即自動部署。

通過下面問題進一步瞭解團隊的構建現狀：

 有那些級別的測試，現狀如何？

 提測流程是怎麼樣的？需要多長時間？有多少人工參與？

 集中的測試階段佔整個專案週期的比例？

 QA和RD的合作流程是怎麼樣的？

 有那些自動化測試，數量和質量分別如何？

 自動化測試一般是什麼時候寫的，誰維護，怎麼管理和執行的？

 什麼時間，如何做迴歸測試？

 自動化驗收測試、效能測試以及安全性測試現狀？

 應用了那些靜態程式碼檢查，怎麼用的？

 單元測試的覆蓋率如何？

 什麼時機，做那些人工測試？

 如何選擇對哪個構建做測試？
5 部署及釋出維度
入門：

 有輔助指令碼支援的手工部署

 依據文件的人工上線流程

新手：

 完整的部署指令碼支援

 向測試環境的標準化部署

 通過平臺的半自動上線流程

中等：

 選擇指定的構建產出進行自動部署

 可以推薦某個構建為上線候選版本

進階：

 向生產環境中一鍵釋出，一鍵回滾。

 向生產線部署後的自動化驗證。

瘋狂：

 一鍵恢復生產環境

通過下面問題進一步瞭解團隊的部署及釋出現狀：

 上線流程是什麼樣的？

 是否需要通過work文件，郵件或是一個線上系統傳遞上線步驟或引數？

 如何監測部署的質量？

 如何做回滾操作？

 如何向開發環境部署？有那些步驟？需要多少人工參與？

 如何向測試環境部署？有那些步驟？需要多少人工參與？

 有那些用於部署的指令碼？

 團隊成員各自的部署環境有什麼區別？

 如何選擇合適的構建做部署？
6 團隊習慣維度
入門：

 至少有一個人隨時知曉構建狀態

 階段性程式碼提交習慣

 專人維護持續整合平臺和指令碼

新手：

 專人看護平臺構建狀態

 最小工作單元完成後即時合併到目標分支

 所有人知曉當前的構建狀態

 構建失敗後被及時修復或回滾，失敗期間沒人提交與修復構建無關的程式碼。

 簽入前做本地自動化驗證

 團隊成員簽入程式碼前做相同的本地驗證

 失敗構建不過夜

中等：

 失敗構建修復時間少於半個小時。

 由提交人負責修復失敗構建，每個人都關注構建狀態。

 團隊成員都寫較為全面的單元測試

 每人每天向目標分支做至少一次對最小工作單元的有效提交。

 團隊清楚持續整合平臺和指令碼內容，每個人都可以維護。

進階：

 交付團隊全員對持續整合平臺的穩定構建負責。

 交付團隊全員負責持續整合指令碼開發。

瘋狂：

 1小時左右向目標分支做一次對最小工作單元的有效提交，且很少發現構建失敗。

通過下面問題進一步瞭解團隊的部署及釋出現狀：

 RD如何定義自己工作完成的含義？

 團隊簽入程式碼的規範是什麼？

 是否在簽入程式碼前執行本地構建？

 如何確保失敗的平臺構建有人處理？是簽入程式碼的人處理嗎？

 構建失敗的頻率是多少？

 團隊中誰維護自動化構建指令碼？

 團隊中誰維護CI平臺？CI平臺有那些許可權控制？

 團隊如何提高每個人的單元測試水平？

(作者：wenjian)