Martin Fowler 的持續集成(4)

　　如果第二階段構建發(fā)現了bug，通常意味著(zhù)應該在第一階段中引入新的測試來(lái)予以保證。

　　當然，以上的兩階段構建只是一個(gè)例子，你完全可以加入多個(gè)構建階段。提交構建之后的其它構建是可以并行完成的，如果這些階段的構建需要好幾個(gè)小時(shí)，那么可以用幾臺機器來(lái)并行完成。通過(guò)這種并行化，你可以將提交構建之外的所有測試都引入到構建過(guò)程中來(lái)，比如性能測試。

　　在與生產(chǎn)環(huán)境的拷貝環(huán)境中運行測試

　　測試旨在發(fā)現可能在生產(chǎn)環(huán)境中出現的問(wèn)題，因此如果你的測試環(huán)境與生產(chǎn)環(huán)境不同，那么測試很有可能發(fā)現不了生產(chǎn)環(huán)境中的bug。

　　因此，你的測試環(huán)境應該盡量與生成環(huán)境相同。使用相同的數據庫，相同的操作系統，并且版本都應該一樣。另外，將生產(chǎn)環(huán)境中的庫文件也放到測試環(huán)境中，即使構建時(shí)用不到這些庫。IP地址和端口號也應當相同，當然還包括硬件。

　　但事實(shí)上這是有限制的。如果你開(kāi)發(fā)的是桌面軟件，很難預測你的客戶(hù)在使用哪些第三方庫。再者，生產(chǎn)環(huán)境可能非常昂貴。即便存在這么多限制，你依然應當盡量去復制生產(chǎn)環(huán)境，并熟知因測試環(huán)境和生產(chǎn)環(huán)境的不同而可能導致的風(fēng)險。

　　如果你搭建的環(huán)境足夠簡(jiǎn)單并沒(méi)有多少煩人的外部交互，那么你的提交構建便可在仿真環(huán)境中進(jìn)行。但是，由于系統反應慢等原因，你可能需要test doubles。因此，通常情況是在人工環(huán)境下跑提交構建以獲取速度，而用一個(gè)生產(chǎn)環(huán)境的拷貝環(huán)境來(lái)跑其它測試。

　　我注意到，虛擬化技術(shù)越來(lái)越引起人們的興趣。由于虛擬機可以保存構建所需的所有東西，故在虛擬機中運行構建和測試相對比較容易。另外，虛擬機技術(shù)也允許你在一臺機器上運行多個(gè)測試，或者可以模擬多臺機器同時(shí)訪(fǎng)問(wèn)網(wǎng)絡(luò )的情況。隨著(zhù)虛擬機性能逐漸提升，它將引起更多的注意。

　　使任何人都能輕易獲得可執行文件

　　軟件開(kāi)發(fā)最困能的事情之一便是你不能保證所開(kāi)發(fā)的是正確的軟件。我們發(fā)現人們往往很難預知自己究竟想要什么，而相反，對已有的東西進(jìn)行評判和修改卻容易的多。敏捷開(kāi)發(fā)過(guò)程則恰恰是符合人類(lèi)這種行為習慣的。

　　為此，項目中的所有成員都應能夠獲得最新的可執行文件并能成功的運行，目的可以包括做演示，瀏覽測試或者僅僅看看項目本周有何修改。

　　這是很容易達到的：確保一個(gè)通用的地方來(lái)存放最新可執行文件。在同一個(gè)地方存放多個(gè)可執行文件也是很有用的。對于最新的可執行文件，應當保證能夠通過(guò)提交測試。

　　如果你的開(kāi)發(fā)過(guò)程有一個(gè)很好的迭代計劃，將每次迭代最后一次構建生成的可執行文件存放起來(lái)也是明智的做法。

　　人人都能看到正在發(fā)生什么

　　持續集成主要在于交流，因此應當保證每人都能輕易看到當前系統的狀態(tài)和已做的修改。

　　主線(xiàn)的構建狀態(tài)是非常重要的，Cruise服務(wù)器包含一個(gè)網(wǎng)站，你可以在該網(wǎng)站上看到當前的構建狀態(tài)和最后一次主線(xiàn)構建的結果，許多團隊喜歡用比較顯眼的標識來(lái)反應構建狀態(tài)，比如在屏幕上放一盞燈，燈綠表示構建成功，燈紅表示失敗。尤其常見(jiàn)的是lava lamps——不僅表明構建狀態(tài)，還可顯示構建時(shí)間。如果紅燈中有了氣泡，則表明構建已經(jīng)失敗了很長(cháng)一段時(shí)間了。每個(gè)團隊都有自己的選擇，當然，適合自己的才是最好的。

　　對于手工完成的持續集成過(guò)程，這種可見(jiàn)性也是很重要的，構建機器的顯示器應該能顯示主線(xiàn)構建的狀態(tài)。通常，正在做集成的人會(huì )放一個(gè)token在桌上來(lái)表明他正在做集成。人們喜歡在構建成功后播放一些簡(jiǎn)單的聲音，比如鬧鈴之類(lèi)的。

　　當然，CI服務(wù)器的網(wǎng)站可以展示更多的信息。Cruise不但能可以顯示是誰(shuí)在構建，并且能顯示最新提交的修改。另外，Cruise還可以查看提交歷史，這樣，團隊成員便可以很清楚項目的進(jìn)展情況。據我所知，有些團隊的頭便是通過(guò)這種方式來(lái)了解項目成員的工作情況和整個(gè)系統的修改情況。

　　使用CI網(wǎng)站的另一個(gè)好處是，哪怕不在一起工作的人都可以看到當前項目的狀態(tài)。再者，你也可以將不同項目的構建信息放到一起。

　　并不是只有CI網(wǎng)站才能展示顯示構建信息。由于構建的不穩定性是一直存在的，這時(shí)我們可以將全年的日歷畫(huà)在一張墻上，每天對應一個(gè)方塊，如果構建成功，QA則在該天的方塊貼上綠色標簽，否則貼上紅色標簽。時(shí)間一久，這份日歷便可顯示出項目的穩定性進(jìn)展情況。

　　自動(dòng)化部署

　　做持續集成需要多種環(huán)境，不同的構建階段需要不同的環(huán)境。每天，項目的可執行文件都會(huì )在這些環(huán)境之間搬來(lái)移去，于是你希望將這些過(guò)程自動(dòng)化。因此，自動(dòng)化部署腳本便很重要了，不僅包括測試環(huán)境的腳本，也包括針對生產(chǎn)環(huán)境的部署腳本。雖然我們不是每天都向生產(chǎn)環(huán)境部署，但自動(dòng)化部署不僅可以加速部署過(guò)程，并且能夠減少部署錯誤。

　　如果你已經(jīng)有了生產(chǎn)環(huán)境的自動(dòng)化部署，那么也應該考慮一下相應的自動(dòng)化回滾。由于失敗是時(shí)而會(huì )發(fā)生的事情，在這種情況下，我們希望能快速回滾到失敗之前的狀態(tài)。這樣一來(lái)，我們在部署是也不用那么畏首畏尾了，于是我們可以頻繁的發(fā)布軟件，用戶(hù)亦能盡快的享受到新的功能。(Ruby on Rails社區有一款名為Capistrano的工具即是一個(gè)典型的例子。)

　　在集群環(huán)境中，我看到有每次只向一個(gè)節點(diǎn)部署的情況，由此在幾個(gè)小時(shí)之內逐漸完成所有節點(diǎn)的部署。

　　對于一些面向大眾的web應用，我所了解的另外一種很有趣的部署方式是，先試驗性針對一部分用戶(hù)進(jìn)行部署，再通過(guò)這些用戶(hù)的試用情況來(lái)決定是否向所有用戶(hù)部署。自動(dòng)化部署，做為CI的一項原則，能夠很好的勝任這些工作。

　　持續集成的好處

　　總的來(lái)說(shuō)，我認為持續集成的最大好處在于降低風(fēng)險。我又想起了我在本文一開(kāi)始提到的那個(gè)項目——已經(jīng)處于項目的末期，但是仍然不知到何時(shí)才能結束。

　　延期集成的缺點(diǎn)在于，很難預測集成到底要花多少時(shí)間，更糟的是，你很難了解集成的進(jìn)展情況。

　　持續集成正好解決了這些問(wèn)題。每次集成的時(shí)間都不長(cháng)，任何時(shí)候你都知道自己所處的情況，軟件的哪些地方在工作，哪些沒(méi)有。

　　Bug——惡心的玩意兒，傷害我們的自信，攪亂我們的日程，還破壞我們的名聲。如果在生產(chǎn)環(huán)境中遇到了bug，那么用戶(hù)將會(huì )把氣往你身上撒。而在開(kāi)發(fā)環(huán)境中，bug攔著(zhù)你的路，迫使你無(wú)法完成余下的工作。

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