軟體整合的7重境界

第1重，手工開啟n個工程，複製m個檔案，按照腦袋裡的次序乙個乙個編譯，花費了不少時

間，總算編譯完成了。換個工程師來編譯就出了好多錯，問了很多問題，最後歷經千難萬險

總算編譯成了，但是跑起來一看，發現漏了點什麼，如是反覆幾次，最後總算編出了個勉強

可用的版本。

第2重，書寫了編譯說明書，照著說明，手工開啟n個工程，複製m個檔案，按照次序乙個一

個編譯。就算換個人來，也能照著編出來。

第3重，書寫了編譯指令碼，能夠做到一鍵編譯

第4重，階段編譯， 每隔1周或幾周，進行一次自動的大整合編譯，並且配套進行測試，

第5重，每日整合，一天就執行一次，一般是在晚上做，也有nightly build的說法，整個過

程的時間可以長達12小時以上，所以可以安排介面自動化測試、**檢查等比較耗時的任務，可以有全面的每日測試集，執行時間可以達到1小時以上

第6重，持續整合，配套進行快速測試。每逢checkin做，或者每隔一定時間（比如半小時）檢查有無**checkin，如果有，就做。 一般的，當天的後續工作對持續整合的結果有依賴，所以對開發人員而言，需要等待持續整合的結果，這樣持續整合全過程的時間就被大大限制了，其測試集是乙個快速測試集，一般而言全過程時間控制在15分鐘以內。

第7重，每日整合+持續整合，有全面的每日測試集，執行時間可以達到1小時以上。由於每日整合和持續整合解決的問題是有差異的，有少數組織兩個都做。

cmmi組織起碼達到第2重，敏捷團隊起碼達到第4重。

cmmi沒有對持續整合和每日整合有具體要求，對整合提出了要求，要求並不高。持續整合和每日整合能夠符合cmmi中配置管理和專案整合過程域的多個實踐。

如何最大程度的避免因為人工所帶來的錯誤，那就是把人完成的工作盡量讓機器完成，第2重就是通過少量的自動化指令碼來減少這種重複性工作中人為犯錯的可能性。

持續整合應該也會受到所採用的語言和相關技術及所開發產品型別的影響，可能會做不到最後那幾重, 而且不是所有的地方都有必要來追求最高境界的。

軟體整合的7重境界

第1重，手工開啟n個工程，複製m個檔案，按照腦袋裡的次序乙個乙個編譯，花費了不少時 間，總算編譯完成了。換個工程師來編譯就出了好多錯，問了很多問題，最後歷經千難萬險 總算編譯成了，但是跑起來一看，發現漏了點什麼，如是反覆幾次，最後總算編出了個勉強 可用的版本。第2重，書寫了編譯說明書，照著說明，手工...

軟體配置管理七重境界

軟體開發熱點詞彙不斷推陳出新，cmmi，agile，精益，持續交付，持續整合，灰度 但有乙個詞其實一直在那裡，支援著各種各樣的新熱點，它是 軟體配置管理 它也是影響團隊軟體開發效率的重大因素。英文縮寫scm scm從軟體工程誕生時，甚至誕生前就在那裡，因為程式 文件總是要存放的.scm發展歷經了許多...

BaseAdaPter的三重境界

逗比式 文藝式 普通式 1 逗比式 view view minflayer.inflate r.layout.item,null 存在缺點 重複創造view findviewbyid依然會浪費大量時間 逗比式 view view minflayer.inflate r.layout.item,nul...