編者按：全線專欄《研發效能提升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、安全可信釋出

在軟體交付中，一個程式碼、配置，甚至是一個依賴的變化，都會引發製品的改變。製品的改變會經過流水線的一系列節點。這些節點中間有很多需要去驗證、關注和管控的點，例如程式碼審查、測試驗證、評審、釋出管控；也會有很多的規則、檢測項，例如程式碼質量合規、安全檢測。

這些規則加上這些檢測項，會最終形成一個反饋，表明這次釋出是不是可信的。如果反饋有問題，那就不應該釋出，如果反饋沒有問題那便可以繼續往下走。

作為安全可信釋出來講，首先它要能夠降低釋出的風險，防止缺陷帶來的業務損失。更重要的是降低釋出的心智負擔，不會不敢釋出。

同時，通過安全可信釋出我們可以獲得質量的反饋，讓質量是看得見的。讓我們能做到及時反饋、及時修復，整個開發效率就會變高。

享受持續交付的紅利

持續交付可以帶來很多的好處，例如：

（1）消除對個人的依賴：所有的資訊都是共享的，可見、可控、可度量、可加速

（2）降低團隊之間的損耗：流程一致，所有版本一致，出現故障時更好處理。

（3）降低測試成本、提升質量：自動化的測試是可以迴歸的，可以不斷地執行的，也可以重複的，成本遠低於手工測試。在微服務架構下如果出現問題，也可以更清晰、方便地定位。

（4）降低釋出風險：版本可以回溯，一致性也比較好，因而釋出風險也會很好地被控制。另外，有了可信釋出的支援，整體的釋出成功率也會更有保障。

接下來我們將從：不可變基礎設施、持續交付流水線、安全可信釋出3個層面，逐一深入，通過系列文章，為大家一一講解。

也歡迎在評論區與作者互動，說出你想聽到的內容～

點選下方連結立即體驗雲效持續交付流水線Flow。
https://www.aliyun.com/product/yunxiao/flow?channel=yy_rccb_36

關於我們

瞭解更多關於雲效DevOps的最新動態，可微信搜尋關注【雲效】公眾號；

福利：公眾號後臺回覆【指南】，可獲得《阿里巴巴DevOps實踐指南》&《10倍研發效能提升案例集》；

看完覺得對您有所幫助別忘記點贊、收藏和關注呦；