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

編者按：全線專欄《研發效能提升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個層面，逐一深入，?通過系列文章，為大家一一講解。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的做到这4点，才是真正的持续交付| 研发效能提升36计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。