測試
持續整合一直同自動化測試相關聯。這在馬丁福勒的文章或更早期steven mcconnell對日構建和冒煙測試的相關實踐描述中都有提及。而且在企業持續整合的領域中，我們會考慮很多種型別的自動化測試和手工測試。儘管如些，很多團隊在測試方面還是比較弱。很常見的乙個版本發布場景就是：某個團隊完成乙個版本後，手工測試一下基本功能就發布了。而其中的某一部分總是出錯，而新功能也只做了少量測試。如果團隊在測試方面比較成熟的話，他們能很快發現問題或缺陷，從而在生產率和信心方面都會有所增加。
目前，大多數團隊或多或少都會有某種形式的自動化測試。比如一小撮單元測試套件或一些指令碼化的測試，用於確保軟體的基本功能是可以工作的。這些基本的自動化回歸測試能夠較早及比較容易地發現那些基本功能性問題。入門級的團隊通常剛剛開始習慣於做這種自動化測試。
為了達到新手級成熟度，應該有一套快速測試在每次構建時都執行。這些測試給團隊增加了信心：軟體基本上在任何時間都能工作。測試一旦失敗，開發團隊會得到即時通知，從而在他們忘記這個問題的上下文之前就有機會去修復這些失敗的測試。因此，對於這一級別來說，對測試失敗通知的響應是非常重要的：如果乙個團隊測試失敗卻不響應的話，那它應該低於測試成熟度的入門級。
中級成熟度的團隊會在這些同快速構建同時執行的測試的基礎之上，擴大測試範圍。企業持續整合的成熟測試是以多種多樣的測試集合為特性的。乙個中級團隊不僅有快速測試和手工測試，而且還有自動化的功能測試。中級團隊常常讓持續整合系統同時執行一些靜態源**分析。靜態分析可能不是每次都執行，但一定會週期性執行。而且一旦產生了某種嚴重的靜態質量問題的話，一定修復之後才能發布。
高階級成熟度是以「完整測試」為標誌的。每種測試都提供其所能提供的最大價值。單元測試覆蓋了系統中所有複雜**與邏輯。功能測試覆蓋了系統中所有的重要功能。也會有邊界測試和隨機測試。同時，還要頻繁執行靜態**分析，並補充以工具支援的執行時分析和安全掃瞄來發現那些可能因測試不足或無法測試而遺漏的問題。測試可能被分配在多種系統下執行，以使能並行執行，從而提供快速的反饋。達到高階級需要相當大的投入，然而對於那些缺陷的成本很高且需要能夠保持高速前進的團隊來說，對是非常重要的。假如沒有這類需求的話，一般來說，中級可能是乙個更適當的目標。
在極端的情況下（也就是瘋狂級成熟度），某些團隊追求100％的測試覆蓋率。儘管100%測試覆蓋率的定義在變化，但它反映出至少每行**都被測試覆蓋到。在某些軟體中，存在乙個收益遞減的點，在這一點上，對某行**的自動化測試的價值要小對寫測試的成本。追求100%的測試覆蓋率意味著團隊會做一些浪費的測試，然而其目的有可能是阻止因某些測試很有價值但很難寫而不寫測試找藉口。滿足並保持100%的測試覆蓋率可能也是乙個自豪感與動力的源泉。對於高階級團隊來說，如果曾經發現的確錯過了一些非常重要的測試的話，要求100%的測試覆蓋也未尚不可。但對於大多數團隊來說，簡直可以說是**啦。
企業持續整合成熟度模型簡介之四 報告
報告 企業持續整合成熟度模型簡介之四 持續整合工具一直以來就負責報告最近一次構建的狀態。報告是持續整合的乙個至關重要的元素。在企業持續整合中，報告應包含所做軟體的相關質量和內容方面的資訊，以及與企業持續整合過程有關的度量資訊。沒有報告的團隊就象乙個沒有雷達的飛機在飛行。如果沒有人看測試結果的話，所有...
如何使用企業持續整合成熟度模型？
所有團隊在四個維度都達到統一的企業持續整合成熟度 是很困難的。企業持續整合在不同的條件和狀態下，應該考慮選擇不同的方向來實現或加強。為了表明這一點，下面是乙個企業的例子，提供了企業持續整合混合成熟度的解決方法。emeno 投資公司 平衡敏捷與控制 現狀分析 emeno採納企業持續整合的最高優先順序是...
企業持續整合成熟度模型簡介之二 部署
出差在外，沒有及時更新blog。繼 構建 之後，今天再說一下企業持續整合成熟度模型的另乙個維度 部署 在正文之前，還想再強調一點，即 這個模型本身是是工具箱裡的一件工具，並不一稱個斤兩的量器。部署 對於團隊來說，拋棄完全的手工過程，使用一些輔助指令碼或全過程指令碼化是乙個非常巨大的進步。縱觀整個行業...