每日構建與持續集成聯系與區別 1）持續集成（Continuous Integration）貴在速度，強調一個快速反饋。 比如我一簽入代碼，就立刻集成，給我一個反饋，我要知道我的代碼是否破壞掉了構建。 持續集成是和單元測試結合在一起的，也就是說一般持續集成的時候都要做單元測試。但持續集成中不能加入更多影響“快速反饋”這條宗旨的東西，比如不能加入大量的集成測試，冒煙測試的代碼，尤其是當這些代碼嚴重影響到集成時間的時候。 持續集成一般由每次簽入代碼觸發。我先簽入代碼我就要先看到構建結果，你後簽入，你就要排在後面。這就要求構建時間不能太長。否則在構建的時候有很多人簽入代碼了，就很難知道到底是誰的代碼破壞了集成,很難定位問題，反映簽入代碼的問題，不能給簽入代碼的人快速提供明確的信息。因為一般由後簽入代碼的人來保證集成的成功。 持續集成可以是增量構建，也可以是完全構建。當完全構建時間很長的時候， 一般采用增量構建。 我記得Martin Flower關於持續集成寫過兩篇文章，如果我沒記錯的話，好像是第一篇比較鼓勵放入很多的測試到持續集成中，但是後來他對自己的說法進行了修正，說不能把很多影響集成的東西都加入進去，要保持快速集成，快速反饋，否則很難做到持續集成。 剛查了下最新版的《Continuous Integration》。上面對持續集成的實踐是這樣概括的，更說明了持續集成要快速反饋的重要性。 # Practices of Continuous Integration * Maintain a Single Source Repository. * Automate the Build * Make Your Build Self-Testing * Everyone Commits To the Mainline Every Day * Every Commit Should Build the Mainline on an Integration Machine * Keep the Build Fast * Test in a Clone of the Production Environment * Make it Easy for Anyone to Get the Latest Executable * Everyone can see what's happening * Automate Deployment 2）每日構建（daily build），這個提法最早的出處，我也不知道在哪裡，不過看過《微軟的秘密》這本書，微軟很早就做每日構建了，忘記看過Steve-McConnell啥文章，還是書了，他也提到了每日構建。 我自己感覺每日構建在快速反應上沒有持續集成那麼強，但是他更強調的是質量更能衡量項目的進度。 --- 由於持續集成的宗旨，決定了他不可能加入很多的測試，而每日構建則不然我們知道每日構建一般都會安排在夜裡進行構建，這個時候我們有充足的時間來做構建，那麼這個時候我們就可以做更多的事情，比如代碼質量檢查，命名規范單元測試，測試覆蓋率，集成測試，冒煙測試，代碼安全性檢查.....等等都可以這裡來做。對代碼，對構建的要求更高。許多在持續集成中沒能發現的問題，在這裡都能發現。 --- 每日構建，因為是在晚上執行，會把當天所有的變化的代碼都一起做集成，而不像持續集成是每次僅僅把自己的代碼和以前的代碼做集成那樣。持續集成可以是增量構建的，但是每日構建卻總是一個完全構建。 --- 每日構建是項目的心跳線。一般來講，通過每日構建我們就能看到項目的進度。比如今天有5 個bug的代碼都提交了，第二天我們發現每日構建成功了，那麼項目就又往前邁了一大步，項目又有所進展了。
