“You build it, you run it”
這是 Amazon 一年完成 5000 萬次部署，平均每個(gè)工程師每天超過 50 次部署的核心秘籍。
而這一切，都離不開各種自動(dòng)化測(cè)試工具及高效的持續(xù)交付管道。
目前大部分互聯(lián)網(wǎng)公司，尤其是新興的創(chuàng)業(yè)公司，已經(jīng)從傳統(tǒng)的瀑布流模式變革到敏捷開發(fā)模式。隨之而來的 DevOps 以及持續(xù)交付等概念，也成為當(dāng)下異?；馃岬脑掝}。大家的探討常常離不開以下七個(gè)問題：
持續(xù)交付本質(zhì)上是什么？它是如何提升開發(fā)效率的？
持續(xù)交付在技術(shù)實(shí)現(xiàn)上有哪些關(guān)鍵點(diǎn)？
從2010年國(guó)外就有持續(xù)交付的書出爐，7年過去了，持續(xù)交付現(xiàn)在使用的普及率怎么樣？
持續(xù)交付適用于什么樣的公司和團(tuán)隊(duì)？創(chuàng)業(yè)團(tuán)隊(duì)？大公司？做什么業(yè)務(wù)類型的公司？
團(tuán)隊(duì)規(guī)模不同，大團(tuán)隊(duì)和小團(tuán)隊(duì)在持續(xù)交付的應(yīng)用上痛點(diǎn)在哪里？
老團(tuán)隊(duì)在轉(zhuǎn)型持續(xù)交付的時(shí)候會(huì)遇到哪些阻力？
持續(xù)交付的應(yīng)用是不是在團(tuán)隊(duì)中常見？從個(gè)人角度來說，學(xué)習(xí)持續(xù)交付的意義是什么？會(huì)不會(huì)自己學(xué)習(xí)了，團(tuán)隊(duì)不用，學(xué)了也沒啥用？
持續(xù)交付本質(zhì)上是什么？它是如何提升開發(fā)效率的？
持續(xù)交付的概念已經(jīng)交代了其本質(zhì)，即高質(zhì)量的快速交付。高質(zhì)量和快速交付就是其本質(zhì)。基于高質(zhì)量和快速交付兩個(gè)出發(fā)點(diǎn)，持續(xù)交付的最佳實(shí)踐實(shí)際上是因團(tuán)隊(duì)而變的，并不是所有的最佳實(shí)踐都適合于所有團(tuán)隊(duì)，因團(tuán)隊(duì)而異。然而其包含的幾個(gè)基本持續(xù)交付管道則是必須的，這幾個(gè)交付管道包括：代碼提交，測(cè)試，部署和發(fā)布等基本管道。
幾乎所有的最佳實(shí)踐都能從一定程度上提高開發(fā)效率。舉例說明，代碼提交管道里有很多關(guān)于版本控制(Git)的使用最佳實(shí)踐，比如提交前需要做pre-commit測(cè)試，提交后需要有靜態(tài)代碼檢測(cè)，結(jié)合CI系統(tǒng)使用，保證了代碼的質(zhì)量。
同樣的XP(包括TDD開發(fā)等)原則以及自動(dòng)化測(cè)試管道的存在同樣保證了代碼的質(zhì)量。
表面上看，似乎開發(fā)人員花在開發(fā)，尤其是測(cè)試上的時(shí)間增加了，效率是否提升存疑，然而事實(shí)并非如此。事實(shí)上，通過實(shí)踐這些操作，開發(fā)人員之間可以更好的保證項(xiàng)目在 CI（持續(xù)集成）系統(tǒng)上面的健康狀態(tài)。
尤其是在需要大量合作的項(xiàng)目中，往往一段時(shí)間以后，項(xiàng)目build就處于不穩(wěn)定的狀態(tài)甚至 fail 狀態(tài)，在這種狀態(tài)下開發(fā)，很可能導(dǎo)致各種沖突的產(chǎn)生甚至代碼的回滾，對(duì)后面的集成階段產(chǎn)生極差的體驗(yàn)。而從長(zhǎng)遠(yuǎn)來看，這些管道，尤其是測(cè)試管道的實(shí)現(xiàn)，極大保障了項(xiàng)目始終如一的品質(zhì)，最終來看，實(shí)現(xiàn)開發(fā)效率的極大提升。
持續(xù)交付在技術(shù)實(shí)現(xiàn)上有哪些關(guān)鍵點(diǎn)？
其實(shí)持續(xù)交付和DevOps一樣，技術(shù)實(shí)現(xiàn)上是多樣化的。而真正的落地關(guān)鍵點(diǎn)卻不在技術(shù)上。對(duì)于DevOps來講，關(guān)鍵點(diǎn)是DevOps團(tuán)隊(duì)文化的普及，其中就包括通過實(shí)踐持續(xù)交付來推動(dòng)DevOps文化。但最關(guān)鍵的點(diǎn)還是在于組織上從上而下的普及，即技術(shù)leader(CTO或者首席架構(gòu)師)在技術(shù)團(tuán)隊(duì)來普及DevOps文化，包括團(tuán)隊(duì)內(nèi)如何合作，跨部門如何合作，使用怎樣的工具來實(shí)現(xiàn)持續(xù)交付以及怎樣將DevOps文化推廣到整個(gè)公司。
具體到持續(xù)交付，那么最關(guān)鍵的還是搭建持續(xù)交付管道。持續(xù)交付管道搭建完畢以后，針對(duì)每一個(gè)管道或者步驟，再尋求適合于自身團(tuán)隊(duì)和每個(gè)管道的工具和技術(shù)。
從2010年國(guó)外就有持續(xù)交付的書出爐，7年過去了，持續(xù)交付現(xiàn)在使用的普及率怎么樣？
首先，目前來講，大部分好的技術(shù)基本都是國(guó)外先有然后國(guó)內(nèi)才開始流行的，國(guó)內(nèi)互聯(lián)網(wǎng)行業(yè)更偏重于業(yè)務(wù)或者商業(yè)模式，這在全球都可以說是領(lǐng)先的。然而技術(shù)上還是處于相對(duì)的落后狀態(tài)。包括近幾年非?；馃峄蛘咧饾u火起來的持續(xù)交付，DevOps，Docker，區(qū)塊鏈等等，都處于這種狀態(tài)。
其次，國(guó)內(nèi)大公司由于技術(shù)傳統(tǒng)的問題，普及率并不高，但很多中小公司在實(shí)現(xiàn)持續(xù)交付上已經(jīng)付出了很多努力。國(guó)外的很多大公司已經(jīng)號(hào)稱可以做到每天多次產(chǎn)品交付了，包括但不限于亞馬遜，谷歌，facebook等等。國(guó)內(nèi)隨著容器技術(shù)和DevOps文化的普及，相信也會(huì)像國(guó)外一樣，越來越多的公司開始實(shí)現(xiàn)持續(xù)交付。
持續(xù)交付適用于什么樣的公司和團(tuán)隊(duì)？創(chuàng)業(yè)團(tuán)隊(duì)？大公司？做什么業(yè)務(wù)類型的公司？
持續(xù)交付適合于任何團(tuán)隊(duì)。之所以敢這樣說，是因?yàn)槌掷m(xù)交付有一個(gè)非常非常重要的原則。即要求，代碼的上線和業(yè)務(wù)的上線分離。
簡(jiǎn)單講，就是運(yùn)維可以隨時(shí)上線master(release)代碼。即主干代碼永遠(yuǎn)處于releasable的狀態(tài)，而不關(guān)心業(yè)務(wù)代碼是否已經(jīng)開發(fā)完畢。目前可以實(shí)現(xiàn)這一點(diǎn)的技術(shù)叫做release train和feature toggle。而且他們帶來的好處不單單是這一點(diǎn)，通過release train和feature toggle的實(shí)現(xiàn)，可以使產(chǎn)品經(jīng)理擁有在線上做A/B testing的能力，可以實(shí)現(xiàn)灰度發(fā)布等等。所以說，在技術(shù)上完全可以做到持續(xù)交付而不管你是怎樣的業(yè)務(wù)。
團(tuán)隊(duì)規(guī)模不同，大團(tuán)隊(duì)和小團(tuán)隊(duì)，在持續(xù)交付的應(yīng)用上痛點(diǎn)在哪里？
持續(xù)交付能不能做好，實(shí)際上跟團(tuán)隊(duì)大小無關(guān)。但一般情況來講，一個(gè)團(tuán)隊(duì)如果維持在5-8人之間，效率更高。
不分項(xiàng)目大小，在實(shí)際落地過程中持續(xù)交付的痛點(diǎn)很可能在于測(cè)試管道的實(shí)現(xiàn)。因?yàn)闇y(cè)試管道要求既要復(fù)雜到可以cover掉大部分的代碼和業(yè)務(wù)場(chǎng)景，又要簡(jiǎn)單到可以支持分鐘級(jí)甚至秒級(jí)的交付。那么自動(dòng)化測(cè)試的實(shí)現(xiàn)方式和執(zhí)行時(shí)間就是一個(gè)很關(guān)鍵的問題了。
老團(tuán)隊(duì)在轉(zhuǎn)型持續(xù)交付的時(shí)候會(huì)遇到哪些阻力？
阻力分為內(nèi)因和外因。內(nèi)因即技術(shù)團(tuán)隊(duì)本身的原因，包括團(tuán)隊(duì)技術(shù)能力，技術(shù)團(tuán)隊(duì)之間的合作和團(tuán)隊(duì)leader態(tài)度等等。比如開發(fā)的目標(biāo)是改變，運(yùn)維的目標(biāo)是穩(wěn)定，測(cè)試的目標(biāo)是控制風(fēng)險(xiǎn)，大家相對(duì)來講擁有不同kpi，這些是技術(shù)團(tuán)隊(duì)本身需要解決的問題。
但一個(gè)擁有DevOps技術(shù)文化的公司，肯定不會(huì)在實(shí)現(xiàn)持續(xù)交付的時(shí)候遇到技術(shù)阻力。
阻力其實(shí)多半來自外因。比如技術(shù)資源都是有限的，這時(shí)候各部門對(duì)于技術(shù)資源的爭(zhēng)奪很大程度上成為了持續(xù)交付普及的阻力。若一個(gè)大的團(tuán)隊(duì)擁有一個(gè)大的待轉(zhuǎn)型的項(xiàng)目，這項(xiàng)工作往往要持續(xù)很久甚至數(shù)年才可以完全轉(zhuǎn)型完畢。而在這個(gè)過程中，產(chǎn)品部門需要技術(shù)資源來改進(jìn)提升產(chǎn)品體驗(yàn)，甚至研發(fā)新的產(chǎn)品，運(yùn)營(yíng)部門需要技術(shù)資源來搞各種活動(dòng)來實(shí)現(xiàn)利潤(rùn)。架構(gòu)部門與此同時(shí)還要推動(dòng)持續(xù)交付的實(shí)現(xiàn)。
所以外因往往是轉(zhuǎn)型中的痛點(diǎn)。這時(shí)候，其實(shí)也有解決方案，即Martin Fowler曾經(jīng)提到過的Strangler方法。有興趣的讀者可以自行搜索研究一下。一個(gè)最簡(jiǎn)單的例子，新起的項(xiàng)目要盡量做到使用持續(xù)交付，不要再往老路上走。如果你已經(jīng)意識(shí)到自己在坑里了，就不要再繼續(xù)往下挖了。
新團(tuán)隊(duì)一上來就用持續(xù)交付也是可行的。
持續(xù)交付的應(yīng)用是不是在團(tuán)隊(duì)中常見？從個(gè)人角度來說，學(xué)習(xí)持續(xù)交付的意義是什么？會(huì)不會(huì)自己學(xué)習(xí)了，團(tuán)隊(duì)不用，學(xué)了也沒啥用？
這個(gè)肯定不會(huì)。
持續(xù)交付比DevOps更偏重實(shí)踐一些，DevOps更偏文化一些。所以在學(xué)習(xí)持續(xù)交付的過程中，除了一些概念上的東西，會(huì)學(xué)到非常多最佳實(shí)踐。
其中包括各種各樣的工具，環(huán)境配置管理，代碼版本控制，各種測(cè)試工具和技術(shù)，代碼build工具，持續(xù)集成工具等等。
而且通過學(xué)習(xí)持續(xù)交付，可以更加了解自己目前的工作方式是不是真的適合所在的團(tuán)隊(duì)，繼而才有可能幫助團(tuán)隊(duì)做出有效的改變。
尤其當(dāng)你是團(tuán)隊(duì)leader的時(shí)候，這幾乎可以改變一個(gè)團(tuán)隊(duì)的命運(yùn)。
個(gè)人學(xué)習(xí)持續(xù)交付的意義就顯而易見了
第一，編織自己的持續(xù)交付知識(shí)網(wǎng)絡(luò)，開闊眼界，了解這種工作方式。
第二，學(xué)習(xí)到很多技術(shù)工具。
第三，作為leader，可以極大提升團(tuán)隊(duì)?wèi)?zhàn)斗力、交付能力以及交付質(zhì)量。
即使你不是leader，作為一個(gè)有追求的程序員，未嘗不可以去建議老大進(jìn)行這樣的改革，你也會(huì)成為改革的推動(dòng)者。
后記：
程序員加班是常態(tài)，總有人會(huì)嘴上說“只要提高效率，就不用加班這么嚴(yán)重了“。但是，有時(shí)候你加班并不是個(gè)人效率低，而是涉及到組員間的協(xié)作，甚至跨部門協(xié)作時(shí)的整體效率低下，一個(gè)高效的個(gè)人面對(duì)一個(gè)低效的團(tuán)隊(duì)，渾身是勁也使不出來。
如果你也在被這樣的問題困擾，那你可以考慮系統(tǒng)學(xué)習(xí)一下持續(xù)交付了。
