做到這4點，才是真正的持續交付| 研發效能提升36計-有解無憂

編者按：全線專欄《研發效能提升36計_持續交付篇》上線啦！本專欄將通過10-20篇文章，系統分享云原生時代，企業如何落地持續交付，本文是該專欄的第2篇，

策劃&編輯｜雅純

什么是真正的持續交付？

首先，我們先看一下什么是持續交付，我們認為，持續交付至少應該包含這4點：

● 持續：顧名思義，是均勻的、分散的，具體來說是要：

粒度小： 持續發布的粒度一定要很小，大了便很難做到“持續”，

頻率高：發布頻率要非常高，

● 快速： 持續交付中整個的交付程序是很快的，交付頻率也是很高的，要做到快速需要，

工序短：在測驗、發布、開發等各個階段中都要做到“短”，這樣才能做到快速地反饋、快速地回應，

等待少： 工序和工序之間、工序和其他流程之間的等待應做到“少”，

反饋快： 提交代碼后，應在盡短時間內反饋此次提交的問題，應盡快修復問題再盡快得到又一次的修復反饋，

● 高質量：持續交付是要能夠保證質量的，一定要做到高質量，高質量需要保證：

質量可見性： 判斷做得好不好，首先我們要看到它，所以可見性是非常重要的，

缺陷少： 軟體應是按照預期設計去運行的，而不是有很多潛在的缺陷在里面，

故障少： 每次軟體故障帶來的不僅僅是客戶的損失，也是軟體團隊的損失，很多客戶機會、業務資產會因為故障太多而白白損失掉，

● 低風險：在現在的互聯網環境下，風險無處不在，所以我們要做到安全、合規且可信，

軟體可觀測： 要知道軟體的風險，最重要的一點就是可觀測，知道軟體當前是什么樣子的，

發布可控： 我們后續會專門講到，

問題可回溯： 如果出現了發布問題或軟體故障，我們能夠回溯整個問題的來源，從哪開始、從哪個地方引入的，都需要能回溯起來，

系統可回滾： 如果有問題真的解決不了或沒法快速解決，我們需要能夠快速把它回滾掉，以避免造成更大的風險，

以上是持續交付的4個關鍵點，只有滿足了持續、快速、高質量、低風險這4點才是實作了持續交付， 這4點是缺一不可的，粒度小、頻率高，是快速的前提，相應地，只有質量高了，風險才能夠低一些，

問題是：如何做到呢？

基于云和云原生技術的持續交付

我們認為，云原生時代，要實作持續交付需要做到這3點：不可變基礎設施、持續交付流水線、安全可信發布，

1、不可變基礎設施

有一本書叫做《集裝箱改變世界》，這本書講述了集裝箱的發明讓原本零碎松散的貨物運輸體系變成以集裝箱為單位，并由此帶來了整個貨運成本的95%的降低，

如果我們看軟體交付，以往我們的開發語言構建方式是各種各樣的，程式的打包、運行、管理方式也都不一樣，這些不同使得我們的軟體交付面臨著很大的風險，

在容器出現之前，大家在運維工具、部署工具上做了很多嘗試，但是都不太成功，整體也不如容器流行，其原因便是容器做的就像集裝箱做的事情——標準化，

基于容器我們又做了K8S，做了容器的分發和整個部署運維體系，運行的環境也做掉了，在此基礎上，誕生了各種各樣的云原生的資料庫、云原生的中間件，這樣云原生的整體標準就出來了，就像集裝箱帶來的改變一樣，研發體系實作了標準化，由此我們便可以以相同的方式去對待不同技術堆疊寫出的程式，

整體來看，不可變基礎設施的應用為我們帶來了以下幾點“紅利”：

（1）消除了不一致帶來的不確定性： 以前一個程式換了一個環境可能就跑不動了，其中的問題便是底層出現了不一致帶來的bug，

（2）減少不一致的風險： 風險很難預估，像一個Java程式里面，你大部分跑的是對的，但是在某些情況下，它會出現例外，小版本的差異會產生更多例外的風險，這種情況下你會發現風險是非常難排查的，而且風險帶的后果很嚴重，

（3）減少維護成本： 因為很多底層的東西被標準化了，就不用我們去做了，比如K8S就做了很多這樣的事情，

（4）部署簡化了： 都是同樣一套東西，就像集裝箱一樣，運輸就是了，

（5）環境維護成本降低了： 普遍使用標準化后便不需要有太多的負擔，只要遵照這個標準就行，

（6）工具的開發和學習成本的降低了，

不可變基礎設施帶給我們非常大的技術紅利，我們生態越來越完整，只是這時，我們原來的習慣、思維或者作業方式都要發生變化，

2、持續交付流水線

持續交付流水線一定程度上是把我們的整個軟體交付的程序完整地串接在一起，

上圖展示的是一個非常典型的流水線：從代碼提交到合并、構建、生成一個制品、介面測驗、功能驗證、類生產環境部署驗證到最終驗收、上線，

這個流水線是一個完整的程序，沒有間斷、沒有跳過，是一層層往后走的，

有了這個流水線之后，如果代碼質量很好、自動化率很高，整體就會自動地在很短的時間內告知我們上線成功，這是一個非常美妙的體驗，流暢而省力，

要想達到上面流暢的體驗，我們對流水線是有要求的，具體來說有如下幾點：

（1）可描述性

流水線是研發模式的具象化表達： 流水線應該是一個可描述的東西，研發模式其實是通過流水線或其他一些手段描述出來的，

發布流程的一致性： 有了流水線之后，每次的發布流程都是一樣的，

最佳實踐可快速復制： 在一個公司里，不同團隊的研發實踐差別往往非常大，因為很多東西是在口口相傳或者是檔案里的，不同的人對其中內容有不同的掌握、解讀方式，但是流水線可以實作快速的復制，把流程用文章寫出來不如讓它落實在流水線中效果好，

（2）可觀測性

開發、發布程序可見： 在流水線中，不僅僅是當前的發布、開發程序是可以看到的，歷史發布程序、開發程序也是可以看到的，每一次的發布經過了哪些階段、每個階段是什么結果，都是可以看到的，如此便可以知道整個流程是什么樣子，整個流程的質量是什么樣子，中間哪個節點有可能出現問題，

發布程序有保障： 整個流水線中我們看到有很多的驗證節點、介面測驗、預發驗收，所有這些節點的成本都不小，但是它們卻能保證最后發布上線的結果是成功的、穩定的，如此，有了流水線的運用，整個發布程序就有了保障，

（3）自動化

自動化顧名思義就是盡量減少人工在程序中的干預，若每一次階段間的銜接是靠人工完成的，它中間的等待時長以及它的協同成本就會比較高，會帶來各種各樣的風險，所以我們應該做到整個發布程序是完全自動化的，從代碼提交到最后上線，全程序是完全由流水線牽動的，即使中間有些步驟需要人去做驗識訓者測驗，但是這也只是一個工序，這個工序完了之后執行人點個確定，說我驗收成功了，之后就會自動地往下發，因此，整個程序是一個自動化的程序，

3、安全可信發布