轉自高效運維
前言
隨著云計算、容器等新興技術的發展，“持續交付”這個老生常談的問題，忽如一夜春風來，仿佛找到了從理想通向現實的大門。各類相關工具、產品、服務，也是紛紛出現：如 Jenkins 2.0，Jenkins X，阿里云效，Netflix Spinnaker，Jfrog Artifactory 等等。
你了解持續交付嗎？
持續交付，到底是什么意思，它的定義是什么？《持續交付：發布可靠軟件的系統方法》一書中把“持續交付”定義為：
持續交付是軟件研發人員，如何將一個好點子，以最快的速度交付給用戶的方法。
即使熟知了定義和方法論，其實也還是如海市蜃樓一般，無法落地，因為大家所貢獻的最佳實踐才是持續交付理論的核心。只有真正在工作中貫徹和使用這些實踐工具，才能體會持續交付的真正含義和作用。
持續集成、持續交付和持續部署的關系
了解了持續交付，你可能會說“持續集成”、“持續部署”又是什么意思，
它們和“持續交付”有什么關系呢。那我就給你簡單解釋一下。
我們通常會把軟件研發工作拆解，拆分成不同模塊或不同團隊后進行編碼，編碼完成后，進行集成構建和測試。這個從編碼到構建再到測試的反復持續過程，就叫作“持續集成”。
“持續集成”一旦完成，則代表產品處在一個可交付狀態，但并不代表這是最優狀態，還需要根據外部使用者的反饋逐步優化。當然這里的使用者并不一定是真正的用戶，還可能是測試人員、產品人員、用戶體驗工程師、安全工程師、企業領導等等。
這個在“持續集成”之后，獲取外部對軟件的反饋再通過“持續集成”進行優化的過程就叫作“持續交付”，它是“持續集成”的自然延續。
那“持續部署”又是什么呢？軟件的發布和部署通常是最艱難的一個步驟。
傳統安裝型軟件，要現場調試，要用戶購買等等，其難度可想而知。即使是可達度最高的互聯網應用，由于生產環境的多樣性（各種軟件安裝，配置等）、架構的復雜性（分布式，微服務）、影響的廣泛性（需要灰度發布）等等，就算產品已是待交付的狀態，要真正達到用戶可用的標準，還有大量的問題需要解決。
而“持續部署”就是將可交付產品，快速且安全地交付用戶使用的一套方法和系統，它是“持續交付”的最后“一公里”。
可見，“持續交付”是一個承上啟下的過程，它使“持續集成”有了實際業務價值，形成了閉環，而又為將來達到“持續部署”的高級目標做好了鋪墊。
雖然從概念上你可以這樣理解，但從實踐和我個人多年的經驗來說，往往是從“持續部署”（自動化發布）開始推進“持續交付”，這才是一條優選的路徑。
持續交付的顯性價值
持續交付也通常以“發布流水線”的方式來解釋，即研發團隊從開發，到測試，再到部署，最終將產品交付給最終用戶使用的過程。如下圖：
雖然持續交付著重打造的是發布流水線的部分，但它所要達到的目標是在“最終用戶”和“研發團隊”之間建立緊密的反饋環：通過持續交付新的軟件版本，以驗證新想法和軟件改動的正確性，并衡量這些改動對軟件價值的影響。
這里說的“軟件價值”，說白了就是收入、日活、GMV等KPI指標了。
在互聯網應用盛行、速度為王的今天，持續交付的價值更是被突顯出來。持續交付的能力，正成為評定一家互聯網公司研發能力的重要指標。
持續交付的隱性價值
除了上面這些你一眼就能看出來的價值外，如果作為不同的角色、站在不同的角度去看持續交付之后的變化，你還會發現其他一些隱性價值，而其中有一些影響甚至遠遠超過你的預期。
或者可以這么說，通過介紹持續交付的隱性價值，我希望你能夠了解到，無論是什么企業，無論你的職位高低，都可以或者應該去嘗試持續交付，它一定會讓你覺得物超所值。
如果你是CTO或者是一個較大規模研發團隊的管理者
1.你是不是時常困擾于技術選型的問題？
技術選型最大的難點在于影響大，又難以驗證（或者驗證效率低下）。而造成這些困境的絕大多數原因是沒有合適的測試環境，比如環境差異造成測試數據缺乏說服力，又比如缺少隔離環境造成服務沖突等等。而這正是持續交付的用武之地。
持續交付的實施，將全面改善企業對測試環境的管理方法，使得環境管理更合理、更自由。我也將在后續章節里介紹如何做好環境管理。
2.你是不是經常頭痛于已制定的標準難以落地？
標準、規范、流程的落地，都需要載體，而最好的載體就是平臺工具。而持續交付是一整套平臺工具的落地，幾乎涵蓋了研發的整個生命周期，是天然的、最佳的載體。
另外，持續交付的落地本身就伴隨著各類標準、規范、流程的制定和實施，可以說兩者相互依存，是非常好的管理思想落地方案。
3.你是不是時常考慮如何提高跨部門協作的效率？
我看到的每一個持續交付實施團隊，都可以說是最厲害的“拆墻大隊”，拆的就是各個研發協作部門間的“隔離墻”。
持續交付能夠向各個協作部門輸出統一的標準、流程和工具，提升溝通效率；并且通過大量的自動化，進一步提升各部門工作效率；還可以快速集成，把各個分散的團隊，無論是橫向的業務研發團隊，還是縱向的技術框架團隊，緊緊地聯系在一起，共同進退。
4.你是不是擔心“黑天鵝”的降臨？
既然叫“黑天鵝”，那就是說明它的產生有一定的必然性。正應了一句老話“是福不是禍，是禍躲不過”，既然躲不過，那就解決它唄。其實任何故障都有一個天敵，叫作：快速恢復。
假設，所有的故障都可以在3分鐘內恢復，你是不是覺得天下無敵了。那恢復故障最快、最有效的手段又是什么呢？當然就是回滾（或重新部署）了，而這正是持續交付所包含和著力打造的能力之一。
如果你是Team Leader
1.你一定希望團隊的知識能夠傳承。
互聯網公司的人才流動之頻繁已經遠遠超過了你我的想象。人來人往，如何將知識傳承下來呢？其實在這方面，持續交付也能為團隊提供很多幫助。
首先，持續交付將團隊賴以生存的工作流程進行了固化；其次，利用代碼靜態檢查等工具，能夠很好地傳承團隊多年來的代碼規范，并作為檢查項進行自動化校驗；再次，自動化測試的腳本，同樣是團隊經驗的產物。
2.你一定希望團隊專注于業務而非工程。
目前越來越多的公司或研發組織意識到，持續交付體系也如同中間件一樣，能夠從日常的業務研發工作中抽象出來，其不同只在于中間件解決架構問題，而持續交付解決工程問題。這樣研發團隊能夠全力應付業務的需求，而不用總是重復奔波于一些煩人且耗時的工程問題，比如安裝測試機、準備編譯服務器等等。
3.你一定希望以一個較平穩的節奏持續工作。
雖然在實施持續交付的初期，團隊為了適應新的流程和工具，會有一定的效率下降，但之后在自動化的幫助下，團隊效率會有一個明顯的提升并逐漸穩定下來。
持續交付就是這樣通過穩固的流程、自動化的工具和公開而真實的數據，來避免發布前夕容易發生的“死亡行軍”式開發階段。
如果你是產品經理
1.你應該是產品真正的第一個用戶。
持續交付不僅僅是可以保證每一個變化都能及時得到測試以及反饋，更多的是解決測試與實際發布時存在差異的問題。產品人員再也不會陷入“為什么用戶端運行的結果，和在測試環境中的不一致”這樣的窘境，他們將真正成為第一個用戶，而不再是最后一個QA。
2.你應該完全知悉當前的進度和質量。
作為產品人員，你是不是一直有這樣的感覺：和研發團隊之間總有一扇墻，程序員們似乎并不樂意告訴產品人員項目的真相；而最終總有這樣那樣的理由造成延期，產品人員往往無話可說。那么，持續交付就能夠實時地反應當前的開發情況，從而幫助產品人員決策和調整。
3.你的產品應該隨時能發布。
計劃永遠趕不上變化，任何產品人員都希望自己的產品能夠隨時處于可發布狀態。這樣就能靈活地交付已完成的功能，迎合市場或業務的需要。本質上，做到代碼上線和業務上線的解耦分離，這也正是持續交付方法論強調的一個重點。
如果你是一個程序員
1.你可以通過對持續交付的學習，進一步加強自己對整個軟件工程的認識。
持續交付涵蓋了軟件交付端到端的整個周期，其覆蓋面不僅僅包括編碼，還包括：設計、測試、部署、運維、運營等等。
如果你對自己的發展有更高的要求，那么你就應該學習一下持續交付的內容，它能讓你看到更多與編碼有關的其他東西，比如不同的編碼方式等；也能讓你站在更高的角度去看待自己的工作：研發效率的提高往往不是個人能力的提高，而是集體協同效率的提高。
2.你可以利用持續交付的工具或最佳實踐，提高自己的工作效率和質量。
隨著持續交付的流行，其配套的實踐和工具也層出不窮。如果你玩過ping-pong式的結對編程（A寫測試，B寫實現，然后B寫下一個測試，A寫重構和實現），你一定會覺得編程如此輕松有趣，而這種TDD的方式也很好的保證了代碼質量。
3.你可以參與到持續交付實施中去，享受為其他程序員提供效率工具的挑戰和樂趣。
試想一下，如果你是一個出租車司機，而你的乘客卻是舒馬赫（F1世界冠軍），此時你開車的壓力會有多大。其實參與到持續交付的實施中也是一樣，因為你正在用程序員的方式改造程序員的工作習慣，為程序員提供工具。
雖然挑戰和壓力巨大，但這又是如此有趣，你將會站在另一個高度去看你曾經的工作，不想試試嗎？
如何評估持續交付的價值
我跟你說了這么多持續交付的價值，那如何評估它呢？這是一個非常難的問題，我自己每年在績效考評時也都會問自己這個問題：我到底應該怎么給老板匯報呢？我可以量化持續交付的價值嗎？
首先，你一定會說，我可以衡量產品的交付速度是否變快了。但是，實際情況下影響產品交付速度的因素實在太多，雖然我們一定知道持續交付有積極作用，但到底占比是多少呢？好像非常模糊，難以回答。
然后，你又想到，我們可以衡量各個自動化過程的速度是否變快了，比如：編譯速度、發布速度、回滾速度、自動化測試速度等等。是的，這些指標確實很好地反應了持續交付的價值，但總覺得這些并不是全部，持續交付的標準化、推行的新流程、改革的環境治理架構，好像都沒有體現出來。
那到底應該怎么評估持續交付的價值呢？這里和你分享一下攜程的大牛是怎么解決這個問題的。
我除了會評估一些常規的KPI外，更多地會換一種思考方式。既然很難量化持續交付的價值，那么我們就具象化，來看看整個工程生命周期中有多少被開發人員詬病，或者阻礙開發人員自助處理的問題點，即“不可持續點”：
- 開發不能按需產生隔離的測試環境；
- 生產代碼回滾后，要手工處理代碼分支；
- 預發布（Staging）流量要能自動分離，以便預發布測試。
在攜程，他們們會將所有的“不可持續點”進行記錄和分解，通過OKR的考評方式，將消滅這些點作為目標，拆解出來的可行動點，作為關鍵結果，以這樣的方式來完成績效考評。
雖然，有些“不可持續點”已經超越了一般傳統持續交付的概念，甚至有些已經超越了純技術改進的范疇，但是持續交付仍會一直關注于消滅這些“不可持續點”。
所以，我們就是要持續交付我們的價值！
總結
持續交付的價值不僅僅局限于簡單地提高產品交付的效率，它還通過統一標準、規范流程、工具化、自動化等等方式，影響著整個研發生命周期。
持續交付最終的使命是打破一切影響研發的“阻礙墻”，為軟件研發工作本身賦能。無論你是持續交付的老朋友還是新朋友，無論你在公司擔任管理工作還是普通的研發人員，持續交付都會對你的工作產生積極的作用。
