為什麼攜程要做好持續交付？

隨著雲計算、容器等新興技術的發展，「持續交付」這個老生常談的問題，忽如一夜春風來，彷彿找到了從理想通向現實的大門。各類相關工具、產品、服務，也是紛紛出現：如jenkins 2.0，jenkins x，阿里雲效，netflix spinnaker，jfrog artifactory等等。

到底是什麼魔力使得各大公司和廠商對「持續交付」如此趨之若鶩？我在攜程工作多年，負責系統研發的工作，在持續整合、持續交付方面積累了很多實戰經驗。關於攜程為什麼要做好持續交付，持續交付的價值在**？我談談自己的看法。

持續交付，到底是什麼意思，它的定義是什麼？《持續交付：發布可靠軟體的系統方法》一書中把「持續交付」定義為：

持續交付是軟體研發人員，如何將乙個好點子，以最快的速度交付給使用者的方法。

即使熟知了定義和方**，其實也還是如海市蜃樓一般，無法落地，因為大家所貢獻的最佳實踐才是持續交付理論的核心。只有真正在工作中貫徹和使用這些實踐工具，才能體會持續交付的真正含義和作用。

持續交付也通常以「發布流水線」的方式來解釋，即研發團隊從開發，到測試，再到部署，最終將產品交付給終端使用者使用的過程。如下圖：

雖然持續交付著重打造的是發布流水線的部分，但它所要達到的目標是在「終端使用者」和「研發團隊」之間建立緊密的反饋環：通過持續交付新的軟體版本，以驗證新想法和軟體改動的正確性，並衡量這些改動對軟體價值的影響。

這裡說的「軟體價值」，說白了就是收入、日活、gmv等kpi指標了。

在網際網路應用盛行、速度為王的今天，持續交付的價值更是被突顯出來。持續交付的能力，正成為評定一家網際網路公司研發能力的重要指標。

除了上面這些你一眼就能看出來的價值外，如果作為不同的角色、站在不同的角度去看持續交付之後的變化，你還會發現其他一些隱性價值，而其中有一些影響甚至遠遠超過你的預期。

如果你是cto或者是乙個較大規模研發團隊的管理者

如果你是team leader

如果你是產品經理

如果你是乙個程式設計師

那到底應該怎麼評估持續交付的價值呢？這裡和你分享一下我在攜程是怎麼解決這個問題的。

我除了會評估一些常規的kpi外，更多地會換一種思考方式。既然很難量化持續交付的價值，那麼我們就具象化，來看看整個工程生命週期中有多少被開發人員詬病，或者阻礙開發人員自助處理的問題點，即「不可持續點」：

在攜程，我們會將所有的「不可持續點」進行記錄和分解，通過okr的考評方式，將消滅這些點作為目標，拆解出來的可行動點，作為關鍵結果，以這樣的方式來完成績效考評。

雖然，有些「不可持續點」已經超越了一般傳統持續交付的概念，甚至有些已經超越了純技術改進的範疇，但是持續交付仍會一直關注於消滅這些「不可持續點」。so what，我們就是要持續交付我們的價值！

持續交付的價值不僅僅侷限於簡單地提高產品交付的效率，它還通過統一標準、規範流程、工具化、自動化等等方式，影響著整個研發生命週期。

持續交付最終的使命是打破一切影響研發的「阻礙牆」，為軟體研發工作本身賦能。無論你是持續交付的老朋友還是新朋友，無論你在公司擔任管理工作還是普通的研發人員，持續交付都會對你的工作產生積極的作用。

以上內容取自極客時間的《持續交付36講》專欄，希望通過這個專欄的學習，你和你的團隊可以在保證交付質量的前提下，加快交付速度，從而更快地得到市場反饋，引領產品的方向，最終達到擴大收益的目的：