特征進(jìn)入產(chǎn)品階段越快，它就能越早提供價值，

超越持續(xù)集成——持續(xù)部署

。系統(tǒng)響應(yīng)客戶反饋的速度越快，它就能越早讓客戶滿意。Timothy Fitz和Joe Ludwig最近發(fā)布了一些文章，描述了持續(xù)部署的實踐經(jīng)驗，將交付周期從以星期計縮短到以分鐘計。

    Timothy的第一篇文章描述了持續(xù)部署如何影響修復(fù)bug的成本。錯誤被發(fā)現(xiàn)的時間越遲，修復(fù)的難度越高，代價也最昂貴。如果工程師在敲下代碼的時候就發(fā)現(xiàn)了問題，那修復(fù)的成本幾 乎為零。如果編譯器捕獲了bug，它對開放時間造成的影響就是以分鐘計的。如果bug進(jìn)入了產(chǎn)品，而且在一段時間內(nèi)沒有被發(fā)現(xiàn)，找到bug、修復(fù)bug的 代價就會讓人覺得難以承受。千年蟲問題就是一個典型的例子。Timothy贊同快速失�。╢ail fast），這樣bug所造成的影響和代價都會降低到最小。

    讀者的評論基本上對持續(xù)集成的實用性全持強(qiáng)烈的質(zhì)疑態(tài)度。Erik A. Brandstadmoen直言不諱：“在實際應(yīng)用中，我覺得[你的]做法還不夠”。來自ycombinator的一位評論者說道：“唔……不。也許這種做法對單人適用，可以取代持續(xù)繼承。不過要是在一個復(fù)雜的系統(tǒng)上，許多人同時提交，你的站點(diǎn)肯定玩完。”

    imothy又寫了一篇文章回應(yīng)質(zhì)疑聲，他介紹了IMVU是怎么持續(xù)部署系統(tǒng)的。IMVU的做法是，先用持續(xù)集成來做快速構(gòu)建，測試新的變化。這里有一個關(guān)鍵點(diǎn)——要有大量的、覆蓋范圍廣的、非�？煽康淖詣踊瘻y試。他們用了許多測試機(jī)，用來保證可以在10分鐘以內(nèi)運(yùn)行整個測試套件，

管理資料

《超越持續(xù)集成——持續(xù)部署》(http://www.ishadingyu.com)。所有測試都已通過以后，部署便開始了。

代碼用rsync備份到集群的幾百個機(jī)器里面。用一個push腳本來得到平均負(fù)載、cpu占用率、php錯誤及崩潰等等的樣本作為基線。然后在小部分機(jī)器 上建立symlink，讓代碼在這些機(jī)器上運(yùn)行起來。一分鐘以后，push腳本就會在集群中重新收集樣本，如果數(shù)據(jù)出現(xiàn)大幅度衰退，那么就把代碼回退到上 一個版本；如果沒有的話，就把代碼在整個集群上運(yùn)行起來，繼續(xù)監(jiān)控，五分鐘之后重新收集數(shù)據(jù)。然后代碼就可以正式運(yùn)行了。

    IMVU現(xiàn)在有60名員工，3千萬注冊用戶，每月收入上百萬英鎊，做出的成績可相當(dāng)不俗。不過從Michael Bolton和James Bach的調(diào)查中看，這個系統(tǒng)也不完美。Elisabeth Hendrickson則指出，完美并不是這個系統(tǒng)的目標(biāo)。

    Joe Ludwig是Pirates of the Burning Sea的前任架構(gòu)師，他寫了兩篇文章，指出怎樣才能在重量級的客戶端代碼的環(huán)境中執(zhí)行持續(xù)部署。他先是描述了“Pirates”長達(dá)7個半小時的部署過程，然后略述了怎樣把它縮短到1個小時。在第二篇文章中，他詳細(xì)描述了要把一小時部署變成現(xiàn)實所要做出的重大技術(shù)改動。

    你有沒有持續(xù)部署的經(jīng)驗？要把你的系統(tǒng)變的可以持續(xù)部署，需要做出那些變動？請留下你的觀點(diǎn)，與讀者共享。

    查看英文原文：Beyond Continuous Integration: Continuous Deployment

    本文來自：http://www.infoq.com/cn/news/2009/03/Continuous-Deployment