持續整合實踐成熟度模型

Link http://www.ltesting.net/ceshi/ceshijishu/csgl/jccs/2012/1106/205678.html

　　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 測試維度

　　在其它緯度中也有一些與測試相關的條目，可參考。

　　入門：

　　有部分自動化功能測試

　　在專案後期集中測試

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

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

　　新手：

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

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

　　構建時執行自動迴歸測試。#p# 分頁標題 #e#

　　有人工參與的提測過程。

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

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

　　中等：

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

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

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

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

　　自動化提測

　　進階：

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

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

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

　　瘋狂：

　　100% 單元測試覆蓋率。

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

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

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

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

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

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

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

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

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

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

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

　　單元測試的覆蓋率如何?

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

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

　　5 部署及釋出維度

　　入門：

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

　　依據文件的人工上線流程

　　新手：

　　完整的部署指令碼支援

　　向測試環境的標準化部署

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

　　中等：

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

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

　　進階：

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

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

　　瘋狂：

　　一鍵恢復生產環境

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

　　上線流程是什麼樣的?

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

　　如何監測部署的質量?

　　如何做回滾操作?

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

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

　　有那些用於部署的指令碼?

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

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

　　6 團隊習慣維度

　　入門：

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

　　階段性程式碼提交習慣

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

　　新手：

　　專人看護平臺構建狀態

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

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

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

　　簽入前做本地自動化驗證

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

　　失敗構建不過夜

　　中等：

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

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

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

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

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

　　進階：

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

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

　　瘋狂：

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

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

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

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

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

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

　　構建失敗的頻率是多少?

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

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

　　團隊如何提高每個人的單元測試水平?
文章分類:整合測試

Link http://www.ltesting.net/ceshi/ceshijishu/csgl/jccs/2012/1106/205678.html