“當一個項目經理或一名開發者說已經完成了80%的任務，您必須保持審慎的態度。因為剩下的20%可能還需要80%的時間，甚至永遠都不能完成。”

上面這段話來自于《持續集成——軟件質量改進和風險降低之道》的譯者序。仔細想想，此話說得相當有道理：程序員是一群自信而樂觀的人，總是以為自己已經考慮到了方方面面，所編寫的模塊萬無一失、無懈可擊。哪怕遇到了問題，也總會找到理由：是不是需求或是別人出了問題——一句最為流行的Developer應對Tester的Bug Report的話就是，“It is not a bug, but it is a feature.”。

不過即使程序員有千萬種理由為自己的模塊洗清了一切的“罪名”，但客戶需要的上線或發布時間卻仍舊無聲地等在那里，不以任何人的借口而改變。

回到本文開始的那段譯者序文字中，那“剩下的20%”究竟要用來做什么呢？為什么“可能還需要80%的時間”呢？

答案就是集成。雖然流行的軟件開發理論已經把模塊/組件之間的耦合程度降低到了最低，且有無數種類似單元測試的“流程”保證這每一個獨立模塊功能的正確性，不過當把這些堪稱“完美”的模塊集合成一個整體系統時，還是會不停地出現各種問題？?

OK，讓我們停止探討為什么會發生這樣的情況之類無謂的探討，而是去看看應該怎樣解決這個問題，并最終保證產品的發布時間和質量——畢竟問題已經發生了。

——持續集成。

持續集成能夠把最終的一次大規模的集成調試過程分散到項目開發時間表的每一周、每一天、甚至每個小時。讓項目中的各個人員都能夠隨時掌握當前的整體進度，并迅速發現集成過程中出現的問題并進行解決。

這本《持續集成——軟件質量改進和風險降低之道》的第一部分就詳細介紹了持續集成的理念、相關流程以及做法。?

目前來看，持續集成似乎看起來非常不錯，不是嗎？

可是，一次集成并不是說句話就能搞定的——構建、部署、測試、生成測試報告、反饋……種種操作將會占用大量的人工。難道還需要專門派人負責每天的集成嗎？

因此，將所有的步驟自動化，就是實現持續集成中最為重要的問題。

《持續集成——軟件質量改進和風險降低之道》的第二部分則給出了一個完善的自動化持續集成流程，讓持續集成從一句空談變為實實在在的、具有可操作性的規范。?

不過是一本200頁左右的小書，卻已經毫無遺漏地將持續集成的點點滴滴娓娓道來。若你正在為這方面的問題苦惱，不妨嘗試從中找到一些答案。

?

==================================================================================

陳黎夫個人作品集?

2005年畢業于上海交通大學計算機科學專業 ·2005年作為軟件開發工程師加入微軟Windows Live Hotmail團隊 ·曾參與開發了下一代Email系統Windows Live Mail，以及Windows Live Calendar等產品。 ·擅長ASP.NET、CSS、JavaScript等Web相關技術并有著多年的開發、設計經驗。

總結

以上是生活随笔為你收集整理的Dflying 陈黎夫谈《持续集成——软件质量改进和风险降低之道》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。