開篇詞 | 量身定製你的持續交付體系

「持續交付」已再也不是一個陌生詞彙了，絕大多數軟件研發企業，都在或多或少地實施「持續交付」，由於你們都清楚，也都曾經體會或者聽別人說過，「持續交付」可以提升研發效率。可是要說實施得多好、多完全，那我估計不少人都會面面相覷。

作好持續交付並非件易事，從個人經驗來看，它主要難在三個地方。

第一，實施「持續交付」，將會影響整個的研發生命週期，會涉及到流程、團隊、工具等多個方面。極可能須要突破當前組織的束縛，引發大量的技術和組織變革。由於，實施「持續交付」須要組織從上到下的承認，須要有大勇氣將一些可能屬於黑箱操做的工做，公開出來給你們監督。因此，這樣的事情很難推動。
第二，實施「持續交付」，對實施者和參與者的要求都很高，他們不只須要瞭解開發，還要了解流程，瞭解測試，瞭解運維，甚至還須要有必定的架構知識和管理知識。因此，這樣的人才很難尋找。
第三，實施「持續交付」，大多數團隊都但願可以快速見效，立竿見影。可是，「持續交付」的改進過程自己就是一個持續迭代的過程，須要屢次循環才能體現效果。甚至在實施的初期，由於開發習慣和流程變化，團隊在適應的過程當中效率會有暫時的降低。因此，這樣的效果很難度量。

因爲這三大難點，不少人對「持續交付」敬而遠之，或者愛恨交加。所以，我但願這個專欄可以帶你全面、立體地認識持續交付，當你瞭解得越多，理解得越透徹，你也就越有信心。簡單來講，我認爲：

不管企業在什麼階段，不管我的的能力如何，均可以去嘗試「持續交付」。

在實踐中，我還常常看到一些錯誤的觀點。
一、過分強調自動化。認爲只有自動化才能算是「持續」，但限於業務邏輯變化快，QA能力不足等，又沒法實現測試自動化，而發佈自動化更是遙遙無期，因此只能放棄。
二、過分強調流程化。總以爲「持續交付」先要構建強流程來管控，結果就一直限於流程和實現流程的「泥潭」裏，卻忘了初衷。
三、過分強調特殊化。好比咱們常常會聽到，咱們的工程師能力特別強，咱們的團隊有特殊的工做方式，咱們的系統有不一樣的設計，這些每每成了拒絕「持續交付」的藉口。

但願在這裏，經過個人講解可以糾正你的這些錯誤觀點。

同時，我也但願和你之間不是教與學的關係，而是切磋與討論，在這三個月的時間裏，咱們一塊兒討論如何解決現實的問題，討論如何進一步去作好「持續交付」，討論那些超出你我邊界的所謂的「難題」。
自從決定寫這個專欄，我就一直在腦子裏「翻箱倒櫃」，在網絡上收集相關參考資料，整理寫做材料。忽然，我腦子裏蹦出一個問題：我本身當年是怎麼接觸到持續交付的，是怎麼走上「持續」這條「不歸路」的？

仔細回想一下，接觸「持續集成」這個概念實際上是挺早的事情了。那時我在第九城市負責用戶中心的開發，有些與《魔獸世界》相關的功能須要大洋彼岸的老美同窗（QA）進行驗收。所以，爲了利用時差優點，咱們若是有新功能要測試，就會要求整個團隊在當天下午凍結代碼版本，並在6點後向測試環境發佈。

晚上咱們睡覺的時候，老美們就開始幹活了。由於《魔獸世界》的爆紅，因此當時開發需求特別多，缺陷也特別多，幾乎天天都要提測，我就乾脆用按鍵精靈寫了個腳本，實現了天天自動地處理這些事情。如今想一想，這不就是每日構建嘛。

你如今可能和當時的我同樣，正在採用或借鑑一些「持續集成」或「持續交付」的最佳實踐，但還停留在一個個小的、零散的點上，並無造成統一的體系，還搞不定持續交付。

因此，我但願這個專欄首先可以給你呈現一個體系化的「持續交付」課程，幫助你拓展高度和廣度，造成對「持續交付」立體的認識。

其實從這個角度來看，我想經過這個專欄與你分享的內容，不正好就是我本身在實際成長過程當中一點一點學到的東西嗎？那麼，若是你不嫌厭煩，能夠繼續聽一下個人故事。離開第九城市以後，因爲經受不住帝都「乾燥」的天氣，2008年我又回到魔都，加入了當時還默默無聞的大衆點評網。在那裏，我真正體驗了一把「坐火箭」的感受；也是在那裏，我與「持續交付」真正結緣。

點評是一家工程師文化很濃重的公司，一直以來都以工程師的能力爲傲。但隨着O2O和移動互聯網的興起，點評走到了風口浪尖，團隊在不斷擴大，而研發效率開始降低了。

起初，你們都以爲是本身的能力跟不上，就開始拼命學習，公司也開始樹立專家典型。但結果卻事與願違，我的越牛，瑣事越多，不能專一，反而成了瓶頸。總結以後，咱們發現，這種狀況是研發流程、合做方式等低效形成的。我的再強放在一個低效的環境下，也無力可施。

而後，QA團隊開始推進「持續交付」，試圖改變現狀。爲何是QA團隊呢，由於QA在軟件研發生命週期的最後一端，全部前期的問題，他們都得承擔。低效的研發模式和體系，首先壓死的就是QA。可是，QA團隊最終仍是以失敗收場了。究其緣由：

一、缺少實踐經驗，多數「持續交付」相關的圖書、分享都停留在「what」和「why」上，沒有具體的「how」；QA團隊自己缺少開發能力，沒法將「持續交付」經過工具進行落地，只能流於表面的流程和理念。但這場自底向上的革命，卻讓公司看到了變革的方向。
二、以後，點評就開始了轟轟烈烈的「精益創業」運動。「持續交付」做爲研發線變革的重點，獲得了更多資源的支持和高度的關注。也是在這時，我得到了與國內衆多的領域專家進行探討和學習的機會。

最終，點評是以發佈系統爲切入點，從下游逐步向上游的方式推行「持續交付」。而且在這個過程當中，造成了專職的工程效能團隊，從而打造出了一套持續交付平臺。

因此，我但願這個專欄的第二個重點是，結合我我的多年的實踐經驗，與你分享「持續交付」涉及的工具、系統、平臺，到底如何去設計，如何去實施，如何去落地。離開點評以後，我加入了攜程。攜程的規模、體量相比點評，又大了許多。好比，攜程有近20個BU，應用數量達到6000%2B，研發人員有3000人；同時還有去哪兒、藝龍等兄弟公司，在系統上也息息相關；並且攜程隨着多年的業務發展，系統複雜度也遠遠高於點評。要在這麼大的平臺上推行「持續交付」，挑戰是巨大的。
其實，攜程在「持續交付」方面一直以來都是有所嘗試和努力的，引進、自研各類方式都有，可是收效甚微。其中構建的一些工具和平臺，因爲種種問題，反而給研發人員留下了壞印象。這裏面天然有各方面的問題，但我認爲最主要的問題是如下三點：
一、「持續交付」必須以平臺化的思想去看待，單點突破是無力的；
2「持續交付」的實施，也要順應技術的變遷，善於利用技術紅利；
三、「持續交付」與系統架構、運維體系息息相關，已經不分彼此。
事實上，在攜程推動「持續交付」時，咱們聯合了框架、OPS等部門，將目標放在支持更將來的容器化、雲原生（CloudNative），以及微服務上，利用這些新興技術的理念，和開源社區的紅利，從「持續發佈」開始，逐步推動「持續交付」。在推動的過程當中，咱們既兼容了老舊的系統架構，也爲遷移到新一代架構作好了準備，並提供了支持。能夠說，攜程第四代架構的升級自己，就是在堅持「持續交付」，從而得到了成功。因此，在DevOps愈來愈火的今天，我但願這個專欄能夠達到的第三個目的是，可以讓你看到「持續交付」與新興技術擦出的火花，並與你探討「持續交付」的將來。
除了以上內容，你還將經過個人專欄收穫如下四個方面。
一、「持續交付」的主要組件：配置管理、環境管理、構建集成和測試管理。在這一部分裏，我會深刻淺出地，跟你聊聊「持續交付」的這「四大金剛」，幫你全方位地理解「持續交付」的各項主要活動。
二、如何實現「灰度發佈」。若是你對「持續部署」有所期待，但願進一步瞭解，那麼你大多數的問題均可以在這一部分獲得解答。
三、移動App中有所不一樣的「持續交付」體系。移動互聯網如火如荼，你必定也想了解下，如何在手機客戶端研發中作好「持續交付」。那麼這一部分，你就不能錯過了。
四、如何利用開源紅利，快速搭建一套持續交付平臺。在這一部分，我會手把手地，帶你真正去搭建一套最小集合的持續交付平臺。

學須致用，思須有爲。個人這趟「持續交付」班車即將發車，若是你感興趣，那就趕忙一塊兒來，讓咱們一同欣賞沿途的風景吧！

極客時間版權全部: https://time.geekbang.org/column/article/10175