報告——企業持續整合成熟度模型簡介之四
持續整合工具一直以來就負責報告最近一次構建的狀態。報告是持續整合的乙個至關重要的元素。在企業持續整合中，報告應包含所做軟體的相關質量和內容方面的資訊，以及與企業持續整合過程有關的度量資訊。沒有報告的團隊就象乙個沒有雷達的飛機在飛行。如果沒有人看測試結果的話，所有的測試都是無用的。同樣，很多資料如果沒有被提取成可消化利用的資訊的話，就很難使用，一樣可以視為無用。越成熟團隊的報告，其視覺化程度越高，有用的資訊也會越多。
很多任務具在構建過程中都會產生報告。在乙個團隊中，如果某人利用一些工具來產生報告，並分析它，之後會根據它來做出行動的話，這個團隊就已經是入門級成熟度了。注意：此級別上，如果團隊的其他人想利用這些資料做些事情時，需要聯絡這個人，索要相關資訊。當到了新手級成熟度時，每個角色組（開發、測試、部署等）都會公布這類資訊。乙個構建伺服器也可能提供一些資訊，比如哪些**變化了，源**的分析報告、單元測試結果或編譯錯誤等。測試人員也會公布他們自動測試和手工測試的結果報告。部署與發布人員會公布某個版本在生產環境的執行時長、記錄的缺陷，以及發布速度等資訊。但每個角色幾乎各自為戰，跨角色資訊傳遞通常是手工完成的。事實上，這個級別應該是業內的平均水平，儘管很多企業有比較強大的跨角色或部門的展示能力。
中級成熟度則有兩個比較大的變化。第乙個是每個角色組的關鍵資訊集合可以被整個團隊的其它人員訪問。測試人員可以看到開發部分的資訊：比如從上次測試人員測試過的版本到目前的版本有哪些檔案變化了；開發人員能夠知道測試人員正在測試哪個版本，目前的測試結果如何等。每個參與到版本生命週期的人都至少會得到對其有用的總結報告。有了更高的視覺化程度，那麼用於溝通基本資料所用的成本會減少，從而依據報告進行相應工作的時間就增加了。第二個是有歷史報告。即不但有最近的活動報告，而且有過去的報告。比如可以拿出過去發布的測試資料與當前發布的資料進行對比。團隊不但知道最近測試通過率是95%，還知道加了多少個測試，刪除了多個測試，或者哪些測試之前通過了。95%的通過率比昨天的結果好，還是壞？我們是應該高興，還是需要繼續努力讓它更高？
而高階級團隊能夠利用歷史報告資訊進行趨勢分析。中級團隊記錄了每個測試的失敗，而高階級團隊利用報告分析出哪些測試經常被破壞。還可能分析出修改哪些檔案後更有可能使單元測試失敗？哪些會讓功能測試套件失敗？通過識別那些經常出錯的**幫助團隊來發現哪些**應該多加測試或進行重新設計實現。在特定的報告中，會有從不同的豎井（不同的角色團隊）彙總在一起得到的資料，並互相迭加引用。高階級團隊也是真正使用這些特定報告並會採取相應行動的團隊。生成這些可操作的跨功能團隊的報告應該是企業持續整合的目標。而瘋狂級報告是關於**的。這樣的瘋狂級團隊會收集每次交付客戶之後得到的反饋度量資訊，如從缺陷報告和接收到的技術支援的需求抽取相關資訊。根據當前的一次發布與過去的某次發布之間的資料對比，團隊應該可以**在發布後的第一周內技術支援的壓力有多大（比如，可能會接到多少個問題反饋）。在這種模式下，他們可能問更多有意思的問題，而不只是簡單的問一下「我們的特性都做完了嗎？」
企業持續整合成熟度模型簡介之三 測試
測試 持續整合一直同自動化測試相關聯。這在馬丁福勒的文章或更早期steven mcconnell對日構建和冒煙測試的相關實踐描述中都有提及。而且在企業持續整合的領域中，我們會考慮很多種型別的自動化測試和手工測試。儘管如些，很多團隊在測試方面還是比較弱。很常見的乙個版本發布場景就是 某個團隊完成乙個版...
如何使用企業持續整合成熟度模型？
所有團隊在四個維度都達到統一的企業持續整合成熟度 是很困難的。企業持續整合在不同的條件和狀態下，應該考慮選擇不同的方向來實現或加強。為了表明這一點，下面是乙個企業的例子，提供了企業持續整合混合成熟度的解決方法。emeno 投資公司 平衡敏捷與控制 現狀分析 emeno採納企業持續整合的最高優先順序是...
企業持續整合成熟度模型簡介之二 部署
出差在外，沒有及時更新blog。繼 構建 之後，今天再說一下企業持續整合成熟度模型的另乙個維度 部署 在正文之前，還想再強調一點，即 這個模型本身是是工具箱裡的一件工具，並不一稱個斤兩的量器。部署 對於團隊來說，拋棄完全的手工過程，使用一些輔助指令碼或全過程指令碼化是乙個非常巨大的進步。縱觀整個行業...