持續集成實踐成熟度模型(2)

　　有人工參與的提測過程。

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

　　自動化功能測試全集頻繁運行，不少于一天一次。

　　中等：

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

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

　　靜態代碼檢查及相關舉措

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

　　自動化提測

　　進階：

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

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

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

　　瘋狂：

　　100%單元測試覆蓋率。

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

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

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

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

　　集中的測試階段占整個項目周期的比例?

　　QA和RD的合作流程是怎么樣的?

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

　　自動化測試一般是什么時候寫的，誰維護，怎么管理和運行的?

　　什么時間，如何做回歸測試?

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

　　應用了那些靜態代碼檢查，怎么用的?

　　單元測試的覆蓋率如何?

　　什么時機，做那些人工測試?

　　如何選擇對哪個構建做測試?

　　5 部署及發布維度

　　入門：

　　有輔助腳本支持的手工部署

　　依據文檔的人工上線流程

　　新手：

　　完整的部署腳本支持

　　向測試環境的標準化部署

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

　　中等：

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

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

　　進階：

　　向生產環境中一鍵發布，一鍵回滾。

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

　　瘋狂：

　　一鍵恢復生產環境

　　通過下面問題進一步了解團隊的部署及發布現狀：

　　上線流程是什么樣的?

　　是否需要通過work文檔，郵件或是一個在線系統傳遞上線步驟或參數?

　　如何監測部署的質量?

　　如何做回滾操作?

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

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

　　有那些用于部署的腳本?

　　團隊成員各自的部署環境有什么區別?

　　如何選擇合適的構建做部署?

　　6 團隊習慣維度

　　入門：

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

　　階段性代碼提交習慣

　　專人維護持續集成平臺和腳本

　　新手：

　　專人看護平臺構建狀態

　　最小工作單元完成后即時合并到目標分支

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

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

　　簽入前做本地自動化驗證

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

　　失敗構建不過夜

　　中等：

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

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

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

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

　　團隊清楚持續集成平臺和腳本內容，每個人都可以維護。

　　進階：

　　交付團隊全員對持續集成平臺的穩定構建負責。

　　交付團隊全員負責持續集成腳本開發。

　　瘋狂：

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

　　通過下面問題進一步了解團隊的部署及發布現狀：

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

　　團隊簽入代碼的規范是什么?

　　是否在簽入代碼前運行本地構建?

　　如何確保失敗的平臺構建有人處理?是簽入代碼的人處理嗎?

　　構建失敗的頻率是多少?

　　團隊中誰維護自動化構建腳本?

　　團隊中誰維護CI平臺?CI平臺有那些權限控制?

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

原文轉自：http://www.anti-gravitydesign.com