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