Martin Fowler 的持續集成(5)

　　持續集成并不能消除bug，卻能幫你快速的發(fā)現bug并予以清除。這種情況下，持續集成更像是自測試的代碼。當遇到bug時(shí)，由于你只做了很小的修改，這樣便大大縮小的bug的查找范圍。另外，由于是你剛寫(xiě)的代碼，你還記得很清楚，因此也使查找bug更加容易。你還可以使用diff debugging，將當前的代碼版本和先前沒(méi)有bug的版本進(jìn)行比較。

　　Bug也存在積累性，bug越多，越難清除。部分原因在于bug之間存在牽連。另外也存在心理因素，bug一多，人便沒(méi)那么多精力去修了——這就是所謂的“Broken Windows 綜合征”。

　　因此，對于采用持續集成的團隊，bug將大大減少，不管是在生產(chǎn)環(huán)境，還是在開(kāi)發(fā)環(huán)境。但是，我想強調的是，你的獲益程度取決于測試的好壞程度。你或許已發(fā)現，寫(xiě)出好多測試并不難。然而，要達到低bug率的程度依然是需要時(shí)間的，你還得不斷地引入并改進(jìn)自己的測試。

　　有了持續集成，頻繁部署也不是什么難事了。頻繁部署的價(jià)值在于，你的客戶(hù)可以快速的享用軟件的新功能，并能快速的提出反饋。這將有利于清除客戶(hù)和開(kāi)發(fā)之間的障礙——我認為這是軟件開(kāi)發(fā)最大的障礙。

　　引入持續集成

　　然后你開(kāi)始試著(zhù)玩持續集成了，但該從何入手呢?上文中我所羅列持續集成實(shí)踐可以給你帶來(lái)太多的好處，但是你并不必在一開(kāi)始就完全采用這些實(shí)踐的。

　　做持續集成沒(méi)有套路，主要取決于你團隊自身的情況，但是我們發(fā)現以下幾點(diǎn)對于持續集成來(lái)說(shuō)是比較通用的。

　　(1)第一步需要將構建自動(dòng)化，并將你所需的所有東西都放在代碼管理系統中，以至于可以通過(guò)一個(gè)命令來(lái)構建整個(gè)系統。對很多項目來(lái)說(shuō)，這并非易事。一開(kāi)始，你可以按照需要進(jìn)行構建，或者可以只做自動(dòng)化的夜晚構建。雖然，這些做法都不能稱(chēng)為持續集成，但夜晚構建確是一個(gè)好的起點(diǎn)。

　　(2)在構建中引入一些自動(dòng)化測試，試著(zhù)確定出現問(wèn)題的主要范圍，并用自動(dòng)化測試去發(fā)現這些問(wèn)題。對于已有的項目來(lái)說(shuō)，很難建立起一組好的快速測試，這時(shí)你就得另尋它路了。

　　(3)使提交構建快速完成。雖然好幾個(gè)小時(shí)的持續集成比沒(méi)有要好，但是如果你能將構建時(shí)間縮短到幾十分鐘，或者就短短的10分鐘，這就再好不過(guò)了。

　　(4)對于新項目，從項目開(kāi)始就采用持續集成。注意構建時(shí)間，如果構建時(shí)間違背了“10分鐘原則”，那么請盡快采取行動(dòng)。

　　(5)尋找幫助，找有經(jīng)驗的人幫助你。和其它的新技術(shù)一樣，當不知到結果會(huì )是什么樣時(shí)，很難開(kāi)頭。找一個(gè)導師可能要花錢(qián)，但是不找的話(huà)，你所付出的代價(jià)是時(shí)間的浪費和低下的生產(chǎn)力。(ThoughtWorks提供這樣的咨詢(xún)服務(wù)，畢竟你可能遇到的問(wèn)題我們之前都遇到過(guò)。)

　　總結

　　自Matt和我發(fā)布了本文的第一版之后，持續集成逐漸變成了軟件開(kāi)發(fā)的主流技術(shù)，在ThoughtWorks，幾乎所有的項目都使用到持續集成，同時(shí)我們也看到世界上其他組織也在使用持續集成技術(shù)。相比起充滿(mǎn)爭議的極限編程來(lái)說(shuō)，持續集成很少得到負面的評論。

　　如果你還沒(méi)有采用持續集成，我強烈建議你試一試。如果你已經(jīng)采用了持續集成，本文可能會(huì )幫助你進(jìn)一步提高效率。這些年來(lái)，我們已經(jīng)學(xué)到了許多關(guān)于持續集成的知識，我們也希望有更多可以學(xué)習和改進(jìn)的地方。

　　延伸閱讀

　　像本文這樣的文章通常只能涵蓋一些基本，但它卻是一種重要的話(huà)題，所以我在自己網(wǎng)站上放了一個(gè)guide page，那里你可以獲得更多的信息。

原文轉自：http://kjueaiud.com