第13部分(第4/4 頁)

中解放出來，做真正有意義的事情了。”

“嗯，有道理。”

“看來關鍵是如何實現完全的自動化，從讀取原始碼、編譯、連線、測試，整個建立過程都應該自動完成。對於一次成功的建立，我們要做到在這個自動化過程中的每一步都不能出錯。”

“這麼一來，也就不需要專人做Build　Manager了！我總算解放了　。”阿朱對這個想法的實施，肯定已經神往很久了。

“嗯，具體的工作是不需要你親自動手了，但是策略性的東西，還得你把關。譬如軟體配置管理（SCM）、分支/合併策略、軟體釋出通知（Release　Notes）等。”

“這些工作不需要經常做的。我會搞好的。”阿朱笑著說。

“不過，上述所說的持續整合過程，實際上要求開發過程也要有對應的改變，譬如自動單元測試那塊，應該由開發人員負責。”

“對，因為這不再是傳統的編譯和連線那麼簡單，屬於自測試的範疇。自測試的程式碼是開發人員提交原始碼的時候同時提交的，是針對原始碼的單元測試，將所有的這些自測試程式碼整合到一起形成測試集，在所有的最新的原始碼透過編譯和連線之後，還必須透過這個測試集的測試，才能算是一次成功的建立。”

“這好像就是McConnell　提出的‘冒煙測試’吧。”阿捷突然想起了前幾天看過的一篇文章。

“對！這種測試的主要目的是為了驗證建立的正確性。在持續整合裡面，這叫做整合驗收測試——Build　Verify　Test，簡稱　BVT。我們測試人員按理不會感受到　BVT　的存在，我們只針對成功的建立進行測試，如功能測試。”

“嗯，這塊我會跟大民、小寶他們說的，讓他們去實現。”

“那我和阿紫負責其他部分的測試框架。”

“我還有一個問題，持續整合和日建立有什麼關係？二者是不是就是一個東西？”阿捷絕對不會放過任何一個學習的機會。

“有些不同。

持續整合強調了整合頻率，和日建立相比，持續整合顯得更加頻繁，目前業界推薦的最佳實踐是每一個小時就整合一次。

持續整合強調及時反饋，日建立的目的是得到一個可以使用的穩定的釋出版本，而持續整合強調的是整合失敗之後向開發人員提供快速的反饋，當然成功建立的結果也是得到穩定的版本。

日建立並沒有強調開發人員提交（check　in）原始碼的頻率，而持續整合鼓勵並支援開發人員儘快提交對原始碼的修改並得到儘快的反饋。

“噢，重點就是‘頻率’和‘反饋’兩個方面。”阿捷若有所思。

“對！持續整合有一個與直覺相悖的基本要點，那就是‘經常性的整合比偶爾整合要好’。對於持續整合來說，整合越頻繁，效果越好　，如果整合不是經常進行的，少於每天一次，那麼�