隨着雲計算、容器等新興技術的發展，“持續交付”這個老生常談的問題，忽如一夜春風來，彷彿找到了從理想通向現實的大門。各類相關工具、產品、服務，也是紛紛出現：如Jenkins 2.0，Jenkins X，阿里雲效，Netflix Spinnaker，Jfrog Artifactory等等。
到底是什麼魔力使得各大公司和廠商對“持續交付”如此趨之若鶩？我在攜程工作多年，負責系統研發的工作，在持續集成、持續交付方面積累了很多實戰經驗。關於攜程爲什麼要做好持續交付，持續交付的價值在哪裏？我談談自己的看法。
你瞭解持續交付嗎？
持續交付，到底是什麼意思，它的定義是什麼？《持續交付：發佈可靠軟件的系統方法》一書中把“持續交付”定義爲：
持續交付是軟件研發人員，如何將一個好點子，以最快的速度交付給用戶的方法。
即使熟知了定義和方法論，其實也還是如海市蜃樓一般，無法落地，因爲大家所貢獻的最佳實踐纔是持續交付理論的核心。只有真正在工作中貫徹和使用這些實踐工具，才能體會持續交付的真正含義和作用。
持續交付的顯性價值
持續交付也通常以“發佈流水線”的方式來解釋，即研發團隊從開發，到測試，再到部署，最終將產品交付給最終用戶使用的過程。如下圖：
雖然持續交付着重打造的是發佈流水線的部分，但它所要達到的目標是在“最終用戶”和“研發團隊”之間建立緊密的反饋環：通過持續交付新的軟件版本，以驗證新想法和軟件改動的正確性，並衡量這些改動對軟件價值的影響。
這裏說的“軟件價值”，說白了就是收入、日活、GMV等KPI指標了。
在互聯網應用盛行、速度爲王的今天，持續交付的價值更是被突顯出來。持續交付的能力，正成爲評定一家互聯網公司研發能力的重要指標。
持續交付的隱性價值
除了上面這些你一眼就能看出來的價值外，如果作爲不同的角色、站在不同的角度去看持續交付之後的變化，你還會發現其他一些隱性價值，而其中有一些影響甚至遠遠超過你的預期。
如果你是CTO或者是一個較大規模研發團隊的管理者
- 你是不是時常困擾於技術選型的問題？
- 你是不是經常頭痛於已制定的標準難以落地？
- 你是不是時常考慮如何提高跨部門協作的效率？
- 你是不是擔心“黑天鵝”的降臨？
如果你是Team Leader
- 你一定希望團隊的知識能夠傳承。
- 你一定希望團隊專注於業務而非工程。
- 你一定希望以一個較平穩的節奏持續工作。
如果你是產品經理
- 你應該是產品真正的第一個用戶。
- 你應該完全知悉當前的進度和質量。
- 你的產品應該隨時能發佈。
如果你是一個程序員
- 你可以通過對持續交付的學習，進一步加強自己對整個軟件工程的認識。
- 你可以利用持續交付的工具或最佳實踐，提高自己的工作效率和質量。
- 你可以參與到持續交付實施中去，享受爲其他程序員提供效率工具的挑戰和樂趣。
如何評估持續交付的價值
那到底應該怎麼評估持續交付的價值呢？這裏和你分享一下我在攜程是怎麼解決這個問題的。
我除了會評估一些常規的KPI外，更多地會換一種思考方式。既然很難量化持續交付的價值，那麼我們就具象化，來看看整個工程生命週期中有多少被開發人員詬病，或者阻礙開發人員自助處理的問題點，即“不可持續點”：
- 開發不能按需產生隔離的測試環境；
- 生產代碼回滾後，要手工處理代碼分支；
- 預發佈（Staging）流量要能自動分離，以便預發佈測試。
在攜程，我們會將所有的“不可持續點”進行記錄和分解，通過OKR的考評方式，將消滅這些點作爲目標，拆解出來的可行動點，作爲關鍵結果，以這樣的方式來完成績效考評。
雖然，有些“不可持續點”已經超越了一般傳統持續交付的概念，甚至有些已經超越了純技術改進的範疇，但是持續交付仍會一直關注於消滅這些“不可持續點”。So what，我們就是要持續交付我們的價值！
持續交付最終的使命
持續交付的價值不僅僅侷限於簡單地提高產品交付的效率，它還通過統一標準、規範流程、工具化、自動化等等方式，影響着整個研發生命週期。
持續交付最終的使命是打破一切影響研發的“阻礙牆”，爲軟件研發工作本身賦能。無論你是持續交付的老朋友還是新朋友，無論你在公司擔任管理工作還是普通的研發人員，持續交付都會對你的工作產生積極的作用。
以上內容取自極客時間的《持續交付36講》專欄，希望通過這個專欄的學習，你和你的團隊可以在保證交付質量的前提下，加快交付速度，從而更快地得到市場反饋，引領產品的方向，最終達到擴大收益的目的：http://t.cn/EUCEALP