特征進(jìn)入產(chǎn)品階段越快，它就能越早提供價(jià)值，
超越持續(xù)集成——持續(xù)部署
。系統(tǒng)響應(yīng)客戶反饋的速度越快，它就能越早讓客戶滿意。Timothy Fitz和Joe Ludwig最近發(fā)布了一些文章，描述了持續(xù)部署的實(shí)踐經(jīng)驗(yàn)，將交付周期從以星期計(jì)縮短到以分鐘計(jì)。Timothy的第一篇文章描述了持續(xù)部署如何影響修復(fù)bug的成本。錯(cuò)誤被發(fā)現(xiàn)的時(shí)間越遲，修復(fù)的難度越高，代價(jià)也最昂貴。如果工程師在敲下代碼的時(shí)候就發(fā)現(xiàn)了問題，那修復(fù)的成本幾 乎為零。如果編譯器捕獲了bug，它對(duì)開放時(shí)間造成的影響就是以分鐘計(jì)的。如果bug進(jìn)入了產(chǎn)品，而且在一段時(shí)間內(nèi)沒有被發(fā)現(xiàn)，找到bug、修復(fù)bug的 代價(jià)就會(huì)讓人覺得難以承受。千年蟲問題就是一個(gè)典型的例子。Timothy贊同快速失�。╢ail fast），這樣bug所造成的影響和代價(jià)都會(huì)降低到最小。
讀者的評(píng)論基本上對(duì)持續(xù)集成的實(shí)用性全持強(qiáng)烈的質(zhì)疑態(tài)度。Erik A. Brandstadmoen直言不諱：“在實(shí)際應(yīng)用中，我覺得[你的]做法還不夠”。來自ycombinator的一位評(píng)論者說道：“唔……不。也許這種做法對(duì)單人適用，可以取代持續(xù)繼承。不過要是在一個(gè)復(fù)雜的系統(tǒng)上，許多人同時(shí)提交，你的站點(diǎn)肯定玩完。”
imothy又寫了一篇文章回應(yīng)質(zhì)疑聲，他介紹了IMVU是怎么持續(xù)部署系統(tǒng)的。IMVU的做法是，先用持續(xù)集成來做快速構(gòu)建，測(cè)試新的變化。這里有一個(gè)關(guān)鍵點(diǎn)——要有大量的、覆蓋范圍廣的、非�？煽康淖詣�(dòng)化測(cè)試。他們用了許多測(cè)試機(jī)，用來保證可以在10分鐘以內(nèi)運(yùn)行整個(gè)測(cè)試套件，
管理資料
《超越持續(xù)集成——持續(xù)部署》(http://www.msguai.com)。所有測(cè)試都已通過以后，部署便開始了。代碼用rsync備份到集群的幾百個(gè)機(jī)器里面。用一個(gè)push腳本來得到平均負(fù)載、cpu占用率、php錯(cuò)誤及崩潰等等的樣本作為基線。然后在小部分機(jī)器 上建立symlink，讓代碼在這些機(jī)器上運(yùn)行起來。一分鐘以后，push腳本就會(huì)在集群中重新收集樣本，如果數(shù)據(jù)出現(xiàn)大幅度衰退，那么就把代碼回退到上 一個(gè)版本；如果沒有的話，就把代碼在整個(gè)集群上運(yùn)行起來，繼續(xù)監(jiān)控，五分鐘之后重新收集數(shù)據(jù)。然后代碼就可以正式運(yùn)行了。IMVU現(xiàn)在有60名員工，3千萬注冊(cè)用戶，每月收入上百萬英鎊，做出的成績(jī)可相當(dāng)不俗。不過從Michael Bolton和James Bach的調(diào)查中看，這個(gè)系統(tǒng)也不完美。Elisabeth Hendrickson則指出，完美并不是這個(gè)系統(tǒng)的目標(biāo)。
Joe Ludwig是Pirates of the Burning Sea的前任架構(gòu)師，他寫了兩篇文章，指出怎樣才能在重量級(jí)的客戶端代碼的環(huán)境中執(zhí)行持續(xù)部署。他先是描述了“Pirates”長(zhǎng)達(dá)7個(gè)半小時(shí)的部署過程，然后略述了怎樣把它縮短到1個(gè)小時(shí)。在第二篇文章中，他詳細(xì)描述了要把一小時(shí)部署變成現(xiàn)實(shí)所要做出的重大技術(shù)改動(dòng)。
你有沒有持續(xù)部署的經(jīng)驗(yàn)？要把你的系統(tǒng)變的可以持續(xù)部署，需要做出那些變動(dòng)？請(qǐng)留下你的觀點(diǎn)，與讀者共享。
查看英文原文：Beyond Continuous Integration: Continuous Deployment
本文來自：http://www.infoq.com/cn/news/2009/03/Continuous-Deployment