持續交付知易行難，想做成這事你要理解這幾個關鍵點

前面幾篇文章，我們介紹了非常基礎的運維建設環節。如果我們想要這些運維基礎建設發揮出更大的作用和價值，就需要針對運維場景進行場景化設計和自動化，讓效率和穩定性真正提升上來。也就是說，把基礎的事情做好之後，我們就要進入效率提升的運維場景自動化階段了。

在這一階段，我個人的經驗和建議是，首先要把持續交付做好。

為什麼要先做持續交付？如果說我們完成了一些運維職責範圍內的自動化工具，提升的是運維效率的話，那麼，做持續交付就是提升整個研發體系效率的關鍵。

做持續交付的價值表現在哪裡？

持續交付覆蓋了應用的整個生命週期，涉及產品、開發、測試、運維以及專案管理

同時，也避免了各個環節只把注意力放在各自職責範圍內的事情上，而忽略了整體的配合。所以，做好持續交付，對於整個研發體系意義重大。

我們面臨的實際場景是怎樣的？

我們知道，隨著業務複雜度的升高，不管是分層架構，還是微服務架構，都會帶來一個最明顯的變化，那就是應用數量增多，有時甚至多達幾十個、上百個。不同的應用就有不同的程式碼、依賴和配置，為了協同多應用之間的線上釋出，我們還要做到服務能夠平滑地進行上下線切換。同時，為了最大限度地降低釋出風險，我們還需要進行多環境下的驗證，以及上線後的灰度策略等等。

應對這一切，如果只是手工維護，或者利用簡單的工具指令碼進行維護，都不能保證正常運作。這個時候，我們必須有一系列的流程、機制和工具鏈來支援和保障。

由傑斯·赫布林（Jez Humble）、戴維·法利（ David Farley）編著，喬樑老師翻譯的《持續交付：釋出可靠軟體的系統方法》（Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation ）這本書，針對持續交付的過程、方法和指導建議幾個方面做了非常詳細的描述。我向你強烈推薦這本書，不過，這本書的內容並不僅僅針對於微服務架構。

接下來我就分享如何把持續交付的理念和實踐相結合，講一講在實踐過程中，做好持續交付最關鍵的幾步是什麼，以及具體應該怎麼做。

什麼是持續交付？

我們現在經常會接觸到這些名詞，比如持續交付、持續整合、持續部署、持續釋出、DevOps和敏捷開發等等。大多有關持續交付的分享或文章中，這些名詞經常會同時出現。它們之間到底有什麼區別？我自己之前也弄不清楚，直到看到喬樑老師的這張圖。

這裡我重點解釋一下持續交付這個概念，通俗地說，持續交付代表著從業務需求開始到交付上線之後的端到端的過程。後面我們會針對這個過程的關鍵環節進行分享。

持續交付的關鍵點

可以說，這一部分也是我們後面將要分享內容的提綱。

從前面那張圖來看，做持續交付需要端到端考慮，同時還要有一些非常關鍵的準備工作。我把這些工作大致分為以下幾個部分。

配置管理

這一部分會利用到我們前面講過的標準化和CMDB打下的基礎，同時還會有更大的外延，比如環境配置、程式碼配置以及依賴管理等等。

配置管理是非常關鍵的基礎工作。有一點值得注意，那就是標準化是一個持續的過程。我們不太可能在一開始就把所有運維物件、屬性和關係全部都考慮清楚，面面俱到是不太現實的，所以，一定要具備標準化的意識，在開展運維工作的過程中，持續不斷地用這個思路去標準化新出現的物件。先標準，再固化，然後自動化。

需求拆解

需求拆解這個工作跟業務需求部門和業務開發有更直接的關係。在這裡，運維需要做的是，明確需求拆解的粒度和我們最終釋出上線的粒度相匹配。

提交管理

需求拆解完成後，就進入到開發階段，開發完成後向程式碼庫中提交程式碼，這個過程中程式碼分支的合併策略選擇就是提交管理。

構建打包

這一部分是指將提交後的程式碼編譯成可釋出的軟體包。

自動化測試

自動化測試包括功能測試和非功能性測試。對於運維來說，會更注重非功能方面的特性，所以後面我會著重講非功能性相關的測試環節。

部署釋出

這一部分是指釋出到不同的環境，如開發環境、預發環境、線上Beta以及線上全量環境。針對不同的環境，釋出策略和注意事項也會不同。

以上是一個完整的持續交付過程中最重要的幾個環節，後面我們分篇進行詳細介紹。

從我自己的實踐經驗來看，配置管理、提交管理、構建和部署釋出是持續交付的重中之重，是關鍵路徑，是從開發程式碼開始，到釋出上線的必經之路。當時，因為這幾個環節出現了問題，不能解決，運維同學經常做手工釋出，這樣效率就跟不上，還經常出現各種問題。

後來，我們就是先從這幾個環節入手，把阻塞的問題解決掉，然後在這個主流程上不斷增加外圍能力，讓整個流程的功能更加豐富和全面。整個系統也從原來的只具備持續部署釋出功能的平臺，逐步演進為具有持續交付能力的平臺。由此可見，我們實現持續交付的過程，也不是一蹴而就的，而是在摸索中逐步演進完善的。

最後，給你留兩個思考題。

1. 先放下持續交付的概念，你所理解或經歷的從開發完程式碼到釋出到線上這個過程中，會有哪些環節？和我列出來的這幾部分是否有相同之處？
2. 持續交付是誰的持續交付，它的主體是誰？或者有哪些主體？

精品提問

1. 持續交付的是產品不是程式碼，上家公司闡述QA指責的時候說的，通過測試的還是程式碼，通過QA的才是產品，使用者要的是產品，不是程式碼。

2. 持續交付的概念很清晰，階段的交付物也很具體，到畢竟這個概念是跨多個團隊，如果他們的意識沒有起來，在落地的過程中及其痛苦，而且要有覺悟：同一件事會被翻騰個3、4遍（一二十個應用還好，如果應用有一二百個的時候，再加上上層對這件事情資源的投入，就會痛不欲生，所以此時上層管理層的支援至關重要）

   需要引導，我也有類似的經歷