我在采用持續(xù)交付的組織中和開發(fā)團(tuán)隊(duì)工作一起工作，發(fā)現(xiàn)很多開發(fā)者認(rèn)為的正確的敏捷團(tuán)隊(duì)的工作方式，在這里跑得不是很順暢。我認(rèn)為傳統(tǒng)敏捷與持續(xù)交付的矛盾的根本在于，二者是采用不同的方式把軟件變得“可以發(fā)布“（ready to release）的。
軟件交付的演進(jìn)
使軟件變得可以發(fā)布的過程一直在不停進(jìn)化，下面是一個(gè)簡要的介紹：
瀑布模型
瀑布模型認(rèn)為，當(dāng)一個(gè)軟件所有的功能都發(fā)開完畢的時(shí)候（也就是功能完整的時(shí)候），才可以發(fā)布。
敏捷：
敏捷引入的思想是，在整個(gè)開發(fā)過程中，軟件都應(yīng)該“可以發(fā)布”。許多敏捷的版本（在這篇文章里被稱為傳統(tǒng)敏捷）都認(rèn)為，“可以發(fā)布”應(yīng)該在固定周期的間隔點(diǎn)上完成。
持續(xù)交付：
持續(xù)交付是敏捷的一個(gè)子集，在持續(xù)交付中團(tuán)隊(duì)會(huì)保持軟件在開發(fā)過程的所有時(shí)間內(nèi)都可以發(fā)布。它和傳統(tǒng)敏捷不同之處在于，持續(xù)交付在開發(fā)過程中不會(huì)有停下來然后創(chuàng)建發(fā)布版本的過程。
持續(xù)性交付不是指更短的周期
從傳統(tǒng)的敏捷開發(fā)流程變成可持續(xù)性交付，不是指把軟件發(fā)布的周期變短。每天晚上做發(fā)布版本仍然不是可持續(xù)性交付。可持續(xù)性交付是說要把”做可以發(fā)布的軟件”這個(gè)動(dòng)作本身從開發(fā)過程中去掉，取而代之的是保持軟件在開發(fā)的過程中始終是可以發(fā)布的。
可以發(fā)布不是意味著真正的發(fā)布
有一個(gè)普遍的誤解是可持續(xù)性交付就是非常頻繁地發(fā)布出產(chǎn)品。而當(dāng)一些組織把每天數(shù)次發(fā)布軟件當(dāng)作是持續(xù)交付的標(biāo)桿時(shí)，就更加深了這一誤解。可持續(xù)性交付不是一定要頻繁的發(fā)布，它只是要求在開發(fā)過程中的任何一個(gè)點(diǎn)上，用非常少的工作，軟件就能夠發(fā)布（可參考Jez Humble的文章，可持續(xù)性交付VS可持續(xù)性部署）。盡管具備這一能力為更加頻繁的發(fā)布敞開了大門，但是許多團(tuán)隊(duì)還是從持續(xù)交付的實(shí)踐中，找到了壓倒性的證據(jù)，來證明即便發(fā)布不是很頻繁時(shí)，持續(xù)交付也是有用的。
持續(xù)交付和傳統(tǒng)敏捷的沖突點(diǎn)
我前面講過，有時(shí)候持續(xù)交付和開發(fā)團(tuán)隊(duì)所認(rèn)為是“正確”的敏捷實(shí)踐流程有一些矛盾。
沖突點(diǎn)：當(dāng)有工作沒有完成時(shí)，軟件依然是可發(fā)布的
其中一個(gè)沖突點(diǎn)是，一個(gè)迭代結(jié)束時(shí)，代碼庫中是否可以包含未完成的用戶故事（user stories）或者bug修復(fù)。我在上一篇關(guān)于迭代的帖子中做了探討。這個(gè)問題主要是源于，傳統(tǒng)敏捷認(rèn)為在迭代結(jié)束時(shí)，team停止開發(fā)，并且來做準(zhǔn)備軟件發(fā)布的一些額外工作，但是，如果團(tuán)隊(duì)采用持續(xù)交付，讓軟件可發(fā)布就沒什么額外的工作需要做。
更有甚者，持續(xù)交付團(tuán)隊(duì)甚至認(rèn)為，通過使用功能切換等技術(shù)，他們的代碼即使在還有功能沒有完成也可以發(fā)布成產(chǎn)品。這也從另外一個(gè)方面說明，團(tuán)隊(duì)在迭代結(jié)束時(shí)能夠達(dá)到可以發(fā)布的要求，即使有未完成的用戶故事。
這可能稍微有點(diǎn)難理解，團(tuán)隊(duì)肯定還是可以要求在迭代結(jié)束點(diǎn)上所有的工作都必須完成，但是這容易讓人感覺是團(tuán)隊(duì)原有的正常開發(fā)的節(jié)奏被隨便打斷了。持續(xù)交付不是要求沒有時(shí)間盒的迭代，這兩種實(shí)踐其實(shí)是互補(bǔ)的。
沖突點(diǎn)：snapshot（軟件快照）/發(fā)布版本（release build）
許多開發(fā)團(tuán)隊(duì)把軟件的版本分為“snapshot”版本和“release”版本。這個(gè)并不是敏捷所特有的，而是隨著Maven的興起，被深深植入了Java開發(fā)中，因?yàn)镸aven把snapshot的概念放入了它的設(shè)計(jì)核心中。這種方案把開發(fā)周期劃分成兩個(gè)階段，在軟件開發(fā)過程中使用snapshot，當(dāng)軟件成為可以發(fā)布狀態(tài)時(shí)才創(chuàng)建release版本。
很明顯，這種發(fā)布周期的劃分和持續(xù)交付的“軟件應(yīng)該總是可以發(fā)布”的理念是相沖突的。持續(xù)交付通常采用的方式是只在開始創(chuàng)建一次版本，然后通過不同階段的測試驗(yàn)證等一系列串行工作來對版本進(jìn)行改進(jìn)，如果使用Maven，要用兩種方式創(chuàng)建版本，這種方式就不行了。
其實(shí)完全可以使用Maven做持續(xù)交付，比如說，為每個(gè)版本創(chuàng)建一個(gè)release build。當(dāng)然，這個(gè)會(huì)和Maven的“release build只以生產(chǎn)部署為目的，不會(huì)經(jīng)常創(chuàng)建”的理念矛盾。而且，像Nexus和Artefactory這樣的私服都有刪除舊的snapshot版本的清理功能，但不允許刪除release版本。所以一個(gè)活躍的持續(xù)交付團(tuán)隊(duì)，一天可以產(chǎn)生幾十個(gè)版本，這樣很容易就吃掉服務(wù)器上幾G到幾T的空間。
矛盾點(diǎn)：更著重測試可部署性
標(biāo)準(zhǔn)的持續(xù)交付的實(shí)踐方式是，通過基本的持續(xù)集成自動(dòng)地把每個(gè)版本部署到與真實(shí)生產(chǎn)環(huán)境盡量貼近的模擬環(huán)境中，使用相同的發(fā)布流程和工具。這對驗(yàn)證每次提交的代碼是否是“可以發(fā)布”是至關(guān)重要的，但是這樣對持續(xù)集成的要求比現(xiàn)在大部分開發(fā)團(tuán)隊(duì)正在使用的要高很多。
舉個(gè)例子，在沒有要求持續(xù)發(fā)布的持續(xù)集成，可能會(huì)使用Ant或者M(jìn)aven將應(yīng)用發(fā)布到嵌入應(yīng)用服務(wù)器然后進(jìn)行自動(dòng)的功能測試。開發(fā)者使用和維護(hù)都很方便，但是這很可能不是生產(chǎn)環(huán)境中應(yīng)用發(fā)布的方式。
所以持續(xù)交付團(tuán)隊(duì)會(huì)自動(dòng)化發(fā)布到一個(gè)更貼近真實(shí)生產(chǎn)的環(huán)境，包括不同的網(wǎng)頁/app/數(shù)據(jù)層，并且使用在真正生產(chǎn)中使用的部署工具。當(dāng)然，這種更像生產(chǎn)的部署階段更加可能出錯(cuò)，因?yàn)樗黾恿藦?fù)雜性，而且可能對開發(fā)者而言更難以維護(hù)和修正，因?yàn)檫@些工具更像是給系統(tǒng)管理員而不是給開發(fā)者使用的。
不過這是個(gè)機(jī)會(huì)，可以和管理運(yùn)營團(tuán)隊(duì)一起創(chuàng)建一個(gè)更可靠、更易于支持的部署流程。但是實(shí)現(xiàn)和穩(wěn)定這一流程的難度會(huì)比較大，可能會(huì)影響開發(fā)的進(jìn)度。
值得采用持續(xù)交付嗎？
考慮到有這么多沖突的地方，那持續(xù)交付有什么好處，值得我們從傳統(tǒng)敏捷遷移過來呢？特別是對于那些實(shí)際上不太可能在一次迭代中有好幾次發(fā)布到生產(chǎn)環(huán)境的團(tuán)隊(duì)來說，更是要問這個(gè)問題。值得這么做的原因如下：
盡早發(fā)現(xiàn)部署可能遇到的問題以降低風(fēng)險(xiǎn)
增加靈活性，組織可以選擇在任何時(shí)候發(fā)布，并把附加的代價(jià)和風(fēng)險(xiǎn)控制到最小
把生產(chǎn)發(fā)布涉及的每個(gè)人拉進(jìn)來（比如QA、運(yùn)營等），使得整個(gè)流程更有效率。組織必須識(shí)別出流程中的困難區(qū)域，并且通過自動(dòng)化、更好的協(xié)作或者改進(jìn)工作方法等方式找到克服它們的方法。
通過持續(xù)的演練發(fā)布流程，組織會(huì)對這個(gè)過程很精通，然后發(fā)布就會(huì)變得自動(dòng)化，就像陣痛過后自由的呼吸，像生孩子一樣。
提升軟件質(zhì)量，因?yàn)閳F(tuán)隊(duì)不能再像以前一樣把問題留到后面，他們必須現(xiàn)在就解決。
消除沖突
當(dāng)引入持續(xù)交付的時(shí)候，我以上所說的沖突點(diǎn)就會(huì)頻繁出現(xiàn)。我希望當(dāng)這些問題出現(xiàn)的時(shí)候，了解沖突的根本原因，可以有助于更好地討論并解決它們。如果開發(fā)者一開始不愿意打破他們習(xí)慣的“正確”做事方式，或者認(rèn)為持續(xù)交付所帶來的串行工作太復(fù)雜，或者很難理解這些實(shí)踐的目的和價(jià)值，那么我希望他們可以盡量開放地給自己一個(gè)機(jī)會(huì)去嘗試一下。一旦這些實(shí)踐方式根植于一個(gè)組織并且變得成熟，團(tuán)隊(duì)成員們往往會(huì)覺得很難退回到以前的做事方式。
編者按：我重新定義了“傳統(tǒng)敏捷”中讓軟件可以發(fā)布的方式。這個(gè)定義不是適用于所有敏捷實(shí)踐，但是就我看到的，大部分主流概念都認(rèn)為敏捷需要停下工作來將軟件變得可發(fā)布。