有一天，業務人員急沖沖的跑過來，對你說生產上出現了一個嚴重BUG，必須要盡快修復。你聽完問題描述后，胸有成竹坐定并迅速定位問題，隨后改動了一行代碼并提交，系統開始自動編譯、各個環境自動化測試、發布上線。幾分鐘后，生產環境上該BUG已經被修復掉。

上面所提到的場景，這是不是很美妙？但是想必不少讀者要忍不住要吐槽了，這太不實際了：新功能上線測試不要時間么？新增了功能肯定要做回歸測試，這都需要一定的時間。況且怎么可以隨便部署上線？還得通過預發演練、走發布審批流程。其實這些過程大家也都清楚，那么不妨從另一個角度思考下，是否可以把這個過程中所有需要人工線下操作的環節都通過一個平臺自動化實現掉呢？

這些其實都是本文要為大家一一解讀的，事實上上述的例子雖然有些理想化，但是卻可以作為一個終極目標，并非沒有實現的可能。

本文目錄：

一、什么是持續交付？

二、設計持續交付四大關鍵要素

三、落地持續交付五大注意事項

四、總結

一、什么是持續交付？

首先來了解下持續交付的概念，在維基百科中持續交付的定義如下：

持續交付（Continuous delivery，縮寫為 CD），是一種軟件工程方法，讓軟件產品的產出過程在一個短周期內完成，以保證軟件可以穩定、持續的保持在隨時可以發布的狀況。它的目標在于讓軟件的編譯、測試與發布變得更快更頻繁。這種方式可以減少軟件開發的成本與時間，減少風險。

好吧，看定義總是很抽象的，我們從兩個維度來理解持續交付，一個是范圍，一個是宗旨。

先說說范圍，軟件研發的生命周期大家想必都很了解，大致包括如下幾個階段，需求、設計、構建（包括開發、編譯）、測試（系統集成測試、用戶驗收測試、非功能性測試）、發布上線。

持續集成覆蓋構建、測試兩個階段，關注于代碼的提交、編譯、測試。持續部署意在保障每一個代碼提交，都能自動化的部署到生產環境上；持續交付和持續部署有些類似，而是保障從原始需求到最終交付上線全過程的穩定可靠，但是不強求自動化部署到生產環境上，在最終發布上線時，可以人工介入，也可以自動部署。

再看看持續交付的宗旨，持續交付的核心宗旨是：保證每次提交代碼都產生一個可發布的版本。下圖是持續交付的一個核心流程圖，代碼提交觸發構建和單元測試，完成后觸發自動化測試，根據自動化測試的結果進行審批是否進行用戶驗收測試，用戶驗收測試通過后進行發布上線。中間每一個環節都會產生反饋，一旦失敗就終止當前交付流程。

通過這范圍和宗旨兩方面，是否已經有些了解持續交付是什么了呢？還是有些泛？不急，接下來我們針對持續交付的整個流程進行拆分。

從代碼提交開始，我們可以把整個持續交付歸納出四個關鍵要素：持續集成、自動化測試、自動化部署、流水線。

二、設計持續交付四大關鍵要素

持續集成

在傳統瀑布開發模式下，通常很長一段時間內，代碼都是不穩定且不可用的；待到功能開發完畢了，才會進入集成階段，這時問題出現了：團隊規模越大，要開發的需求越多，這個周期就越長，集成階段花費的代價也就越大，項目風險也越大，項目的進度極不可控。

而在敏捷過程中，將代碼開發和集成按模塊拆分成多個小階段，每一階段完成后都會進行集成，這在一定程度上減少了風險。

持續集成要求代碼的開發和功能集成并行進行，相輔相成，要求至少做到每日編譯甚至代碼提交即觸發編譯。構建時會對整個應用的所有模塊進行編譯，并伴隨單元測試以及代碼質量分析等動作。如果編譯失敗了或者單元測試失敗了，那么必須要立即修復問題，直到構建成功?？傊?#xff0c;要求代碼庫的代碼持續處于可用狀態。

持續集成的時間一定要盡可能的短，尤其是代碼提交觸發構建的場景下。否則試想：一支20余人的開發團隊，每次構建（編譯+單元測試+代碼質量分析）需要花費20多分鐘；而每次代碼提交時觸發構建，會產生大量的編譯任務排隊，并且會不停增加；編譯發生問題時較難定位，因為在上次開始編譯到這次編譯中間，會有多人提交，很難快速確認是由誰的提交導致的編譯失敗。

持續集成的時間通常建議在5分鐘以內，90秒內完成是極好的。因此對于代碼的編譯、單元測試都一定要注意時間。在分布式場景下，應用可能會依賴于很多外部應用或者中間件，單元測試不一定非要連通真實環境，會帶來請求響應時間的損耗，并且一般也要求單元測試可以在離線環境下可執行，所以可以采用Mock的方式，提升單元測試速度。同樣，由于要控制每次構建的時間，不建議在持續集成流程中去做集成測試（SIT），這個可以交給集測流水線去處理，由測試人員在集成測試環節繼續跟進。

持續集成保證了代碼始終是可用的，編譯正確并且通過所有單元測試。這是持續交付流水線的第一步。

自動化測試

在整個軟件過程中，測試可以分為兩類：功能測試（冒煙測試、系統集成測試（SIT）、用戶驗收測試（UAT））、非功能性測試（壓力測試、穩定性測試、安全測試）等。非功能性測試姑且不論，功能性測試如系統集成測試、用戶驗收測試等都需要盡可能地覆蓋所有的功能模塊，功能越是復雜的應用系統，測試起來的工作量也越大。

雖然自動化測試的理念已經普及了好多年，但是大部分企業內部，還是以手工測試為主，甚至大部分企業，對手工測試的投入也都是不足的。原因有很多，比如人員缺乏和時間周期緊張，來不及寫自動化測試腳本，或者測試人員的水平不足等。這些確實都是客觀存在的原因，但是這樣真的是節省了成本嗎？事實上對于持續發展的產品而言，每次發布時都需要大量的人力投入去進行測試，會有大量重復的測試工作，發布的次數越多，成本越高，某種程度上這甚至限制了快速頻繁發布的能力，由于人力資源的限制，很多企業回歸測試時，只能相信開發人員對于功能調整影響范圍的預估，縮小回歸測試的范圍，為線上運行帶來了極大的風險。在《持續交付》一書中看到這樣一個數字：某組織每次發布軟件是花費在手工測試上的錢就有300萬美元。自動化測試帶來的價值也絕對值得上現在的投入。

想要實現整個持續交付流水線的自動化，實現本文一開始的那個例子，全面的自動化測試不可或缺。只需要花費幾分鐘至幾十分鐘，通過了各個環境的自動化測試，便相當于對質量打上了合格標簽?？梢赃x擇直接部署到生產環境上，或者等待晚上某個時間點進行上線部署。

交付流水線

持續交付是一個大流程，從代碼提交一直到部署上線，但是我們在實踐過程中發現，這種大流程，未免太大太笨重。在企業真實的情況下，大流程本身沒問題，但是其中的環節往往沒有這么簡單，想要讓這個流水線真正能被企業實際使用，還要對大流程進行拆分。我們在實踐中把持續交付流水線拆分成三個子流水線：開發流水線、集測流水線、發布流水線。

開發流水線：

面向開發人員和開發環境。開發人員提交代碼，觸發構建，部署到開發環境中由開發人員進行自測。這個流水線在開發的過程中會頻繁進行。

集測流水線：

面向測試人員，同樣以構建為開始，基于構建的產物（部署介質），部署到集成測試環境，進行系統集成測試。

發布流水線：

當次發布的所有需求全部通過系統集成測試后，便可以進入后續測試如用戶驗收測試、非功能性測試等，通過后，則認為已經達到發布上線標準，觸發上線申請審批流程，審批通過可以進行自動化發布上線。

在項目中，開發流水線的觸發頻率最高，集測流水線其次，發布流水線觸發的頻率最低。

將整個的持續交付流水線拆分為三個子流水線，可以做到面向不同的角色，這樣更靈活也更便于使用。當然，不同企業的流程也是有著區別的，不一定嚴格按照這三個流水線。即使定義成這三個流水線，每個流水線的流程和環節也是不同的，可以結合自己企業的實際流程來拆分。

三、落地持續交付五大注意事項

上面說了很多理論，理論終究要落地實踐，流程和關鍵環節也已經比較清楚了，但是在實際落地時還是會有很多問題和細節點需要注意。先思考下幾個問題：

• 如何快速支持流程使用過程中的一些微調（如環節的配置字段屬性等）？
• 如何做到流程手工和自動執行的自定義？
• 如何讓每個環境部署的介質對應的是哪次代碼提交、哪個交付物有跡可循？
• 如何直觀的查看交付流程目前到了哪個環節、每個環節的狀態是什么樣的？
• 如何以環境為視角，看到該環境下正在運行哪些應用？

帶著上面幾個問題，我們在實踐的過程中，梳理出如下幾個持續交付能力落地的關鍵點：

安全

交付流水線的核心是驅動開發、測試、運維、質量等多個部門和角色進行協作，涉及眾多的角色和功能、又囊括了各個環境的部署運維操作，安全問題自然不容忽視。

明確責任人：流程中每個環節都要有責任人，在人工執行時，只有該責任人才能執行該環節，同時每個環節執行信息都要有詳細的記錄和展現，如：操作人、開始時間、結束時間、自動化執行時間等。

環境類型授權：而由于自動化部署的支撐，對于每個環境的部署都可以通過平臺一鍵執行。開發、測試環境尚還好，但是對于預發、生產環境的部署，一般要由運維人員來操作。對于環境類型的細分授權，在人工執行的時候，會更加安全。

發布審批流程：事實上，在企業內部，正常發布上線通常需要經歷應用發布審批流程，在生產部署前，根據發布的類型（如正常發布、緊急發布）等來觸發不同的上線審批流程，完成上線審批后，才可以執行部署上線的動作。具體的流程可以結合企業內部實際的流程。

流程支持環節、屬性自定義

理論上說，一個企業的持續交付流程應該是一致并且基本穩定的，但實際上大部分企業內部不止一套流程，不同部門、不同項目組的過程體系甚至都可能是不同的，姑且不論這種情況的對與錯，在尚未統一流程和過程前，這種情況總歸是要考慮支持的。即使統一了流程，隨著企業的不斷發展，流程的一些細節也會持續變化，如一些環節的屬性配置等。所以對于流程的環境、屬性自定義、可動態擴展等能力在設計時是要重點關注的。

保持部署介質不變，便于追溯

很多企業由于規范的不標準，經常會出現最終上線使用的部署介質和系統集成測試、用戶驗收測試的部署介質有所不同。比如在用戶驗收測試階段，發現了一個問題，有可能開發人員改動后直接打一個包進行部署上線，不再通過系統集成測試，或者通過人為的判斷改動影響范圍，進行小范圍測試。這些都帶來了很大的生產隱患。

從標準來說，從系統集成測試開始，后面所有環境應該用的都是同一個介質。在系統集成測試的一開始，進行代碼構建，得到部署介質。該介質地址在整個流水線上下文中進行傳遞，后面每個環境的部署都采用該介質。如果把集測流水線和發布流水線分離開，發布流水線必須要關聯一個集成測試流水線，在發布流水線中的環境部署，采用集測流水線中的介質，依舊維持介質一致。如果發現問題需要進行修復，必須要從集測流水線重新開始。對于介質可以使用nexus等介質倉庫進行統一管理。

直觀的協作看板

一個流水線有多個角色協作參與，從實際參與者視角出發也好、管理者視角出發也罷，都需要一個直觀的看板，來整體查看每個應用當前的交付進度，當前處于哪個環節（系統集成測試、用戶驗收測試環境、預發、生產），以及成功和失敗情況。我們提供了兩種看板：發布看板、環境看板。發布看板基于產品、微服務的角度，查看每個產品版本在不同環境上的部署情況。體現產品版本、產品修訂版本、產品發布版本、產品的微服務及其版本。

環境看板則是從環境的維度，查看每個環境下有哪些應用的哪些版本部署了。如下圖所示：

不要一味的自動化，自動和人工要結合

回過頭來看，文章開篇的例子并非不可達成，但是要求很高，需要成熟的持續集成體系、完整覆蓋的的自動化測試交付，全面的自動化部署能力的支撐，想達到這一步，自然不是一時之功就可以的。在建設的過程中，是少不了人工介入流水線中具體環節的，尤其是測試環節。所以在流水線的設計時，要充分考慮人工執行和自動執行的自定義，如果自動執行失敗的話，也要提供人工介入的入口，允許人工選擇重新執行、終止流程等動作。

以這些為基礎準則，我們底層基于了普元的BPS流程引擎，支撐流程的自定義和擴展。并且，針對于每個環節，都可以配置前置后置事件、人工執行還是自動執行，責任人等。整個流水線從構建開始，以代碼的buildNumber貫穿全流程。便于問題、進度的追溯。效果圖如下：

發布流水線

發布看板

四、總結

最后再回頭看看開篇的例子，在建設企業的持續交付流水線時，能做到全自動化固然很好，但并非是要立刻實現全自動化的效果，這也不現實。初期首先是結合企業的標準流程和規范，將企業的持續交付流水線打通?？梢宰詣踊沫h節盡量做到自動化，尚且做不到自動化的就人工介入。

畢竟持續交付的價值絕不僅僅是快，對于大多數企業而言，在提升軟件交付效率之外，統一企業的軟件交付流程和規范、保證軟件交付質量、降低軟件發布風險，這才是最重要的。

總結

以上是生活随笔為你收集整理的谈谈企业的持续交付流水线设计的全部內容，希望文章能夠幫你解決所遇到的問題。

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