一、什麼是持續傳遞
持續傳遞（Continuous delivery，縮寫為 CD），是一種軟體工程方法，讓軟體産品的産出過程在一個短周期内完成，以保證軟體可以穩定、持續的保持在随時可以釋出的狀況。它的目标在于讓軟體的編譯、測試與釋出變得更快更頻繁。這種方式可以減少軟體開發的成本與時間，減少風險。 而我對持續傳遞的一個較為抽象的了解是“一套軟體工程方法論和許多最佳實踐的集合”。方法論和實踐都需要人去總結落地，是以，要想體會到持續傳遞的真正含義，就要在實際工作中貫徹和使用實踐工具。
二、持續傳遞的價值
其最大的顯性價值是，在實施持續傳遞後，能夠做到在保證傳遞品質的前提下，加快傳遞速度，進而更快地得到市場回報，推動産品的商業價值的實作。在網際網路應用盛行、速度為王的今天，持續傳遞的價值更被突顯出來。持續傳遞的能力，已成為評定一家網際網路公司研發能力的重要名額。除顯性價值外，如果站在不同角度看持續傳遞後的變化，我們還會發現一些隐性價值，而其中有一些影響甚至遠遠超過我們的預期。
1、通過快速靈活統一的環境建構，全面改善企業對測試環境的管理方法，使得環境管理更合理、更自由。
2、标準、規範、流程的落地，都需要載體，而最好的載體就是平台工具。而持續傳遞是一整套平台工具的落地，幾乎涵蓋了研發的整個生命周期，是天然的、最佳的載體。
3、持續傳遞能夠向各個協作部門輸出統一的标準、流程和工具，提升溝通效率；并且通過大量的自動化，進一步提升各部門工作效率；還可以快速內建，把各個分散的小團隊，無論是橫向的業務研發團隊，還是縱向的技術架構團隊，緊緊地聯系在一起，共同進退。
4、生産故障永遠是無法完全避免的，那麼，解決生産故障的最好辦法就是快速回退（回複），而快速回退正是持續傳遞着力打造的能力之一。
三、持續傳遞的落地
了解了持續傳遞的價值以後，我們再看持續傳遞在我們團隊的具體推進實踐。坦誠地說，在任何一個團隊推行持續傳遞都不是易事。
- 首先這會影響整個的研發生命周期，會涉及到流程、團隊、工具等多個方面，需要突破目前組織的束縛，引起大量的技術群組織變革。
- 其次大多數團隊都希望能夠快速見效，立竿見影。
但是，“持續傳遞”的改進過程本身就是一個持續疊代的過程，需要多次循環才能展現效果。甚至在實施初期，因為開發習慣和流程變化，團隊在适應的過程中效率會有暫時的下降。
我們之是以開始做持續傳遞：
- 一方面是因為随着團隊規模、體量的增大，比如我們應用數量達到了500+，系統之間依賴度高，需要有平台化的傳遞系統來支撐大量業務上線，且通過傳遞平台去解決工程問題，解放業務研發人員的大腦，讓他們可以專注于業務研發而不是工程問題，比如環境檢視，部署等；
- 另一方面，團隊也在做應用環境容器化，這也為持續傳遞提供了很好的支撐。
上司對此事非常重視，專門抽調運維、DBA、測試開發同僚臨時組建虛拟的效能研發團隊，了解需求，分析各項目特點，封閉開發3個月的時間，打造出基礎級的持續傳遞中系統，并以一個項目為試點，通過資料去說服同僚對接進來。
四、持續傳遞四要素
從代碼送出開始，我們可以把整個持續傳遞歸納出四個關鍵要素：持續內建、自動化測試、自動化部署、流水線。下面分别從四個關鍵要素解讀我們的持續傳遞平台。
1、持續內建
将代碼開發和內建按子產品拆分成多個小階段，每一階段完成後都會進行內建，這在一定程度上減少了風險。 我們要求在代碼送出時即觸發編譯。建構時會對整個應用的所有子產品進行編譯，并伴随單元測試以及代碼品質分析。如果建構過程失敗了，那麼必須立即郵件告警到相關開發責任人，并責令立即修複問題，如果20分鐘内無法修複，就要回退代碼送出，總之，要求代碼庫的代碼持續處于可用狀态。 目前，每次成功的建構（編譯+單元測試+代碼品質分析）一般在5分鐘内完成，單元測試中的外部依賴通過Mock的方式解決，這塊我們會在後續的文章中專門講解分析。持續內建保證了代碼始終是可用的，編譯正确并且通過所有單元測試和代碼靜态檢測，這些動作都發生在代碼部署到環境之前，是持續傳遞流水線的第一步。
2、自動化測試
網際網路産品要求全回歸測試要快，那麼，如何在保證測試品質和測試覆寫率的前提下，有效鎖定測試執行時間呢？首先，測試執行叢集是很好的思路，通過并發機制提升執行效率，其次測試政策也是一個突破口。傳統軟體産品的測試政策，同時采用金字塔模型，這是邁克·科恩提出的，在很長一段時間内都被認為是測試政策設計的最佳實踐。
但是，網際網路産品具有快速疊代，微服務架構重後端等特性，我們應當遵循“重量級API測試，輕量級GUI測試，輕量級單元測試”的原則。以中間層的 API 測試為重點做全面的測試，盡可能提升自動化比率；輕量級的 GUI 測試，隻覆寫最核心直接影響主營業務流程的；最上層的 GUI 測試通常利用探索式測試思維，以人工測試的方式發現盡可能多的潛在問題；單元測試采用“分而治之”，主攻穩定且核心業務。
雖然自動化測試的理念已經普及了好多年，但是據我了解很多企業内部，還是以手工測試為主，原因很多，比如人員缺乏和時間周期緊張，來不及寫自動化測試腳本，或者測試人員的水準不足等。
我們在團隊成立最初階段，也同樣存在此問題，測試人員是有開發自動化測試能力的，但是因為項目接連上線，時間周期緊張，測試人員忙于了解業務支援業務測試上線，沒有獨立的時間去完善自動化用例，彼時自動化測試相對薄弱。産品釋出又需要不斷疊代，每次釋出都需要大量的測試人力投入，其中重複的測試工作占比不少，釋出的次數越多，成本越高，限制了快速頻繁釋出的能力，我們曾一度裹挾在新業務功能測試和大量重複的手工回歸任務中疲于應對，也有過為了節省時間成本，僅通過開發人員對于功能調整影響範圍的預估，縮小回歸測試的範圍，承擔了線上事故帶來的苦果。
經過權衡，我們下決心要大力推動自動化測試，專門抽調人員成立自動化小組，雖然短期内對業務上線時間造成一定影響，但是我們頂着壓力度過了困難期，陸續完成了API自動化測試平台，性能測試平台、Web-UI自動化架構、APP雲測、Mock Server等系統，并和持續傳遞平台很好地結合到一起。API測試平台是我們自動化測試的核心，下圖是平台架構，實作了測試資料和邏輯的分離，同步異步API結果驗證，連續且參數傳遞API用例測試，微服務下API消費契約測試等主要功能，其中核心處理器既能手動觸發也能提供rest的接口供持續傳遞流水線調用。具體的内部實作邏輯我在另外一篇API測試實踐的文章中再細談。
3、傳遞流水線
傳遞流水線包括了從開發送出代碼，觸發建構，部署測試環境，測試環境自動化以及測試、準生産環境部署到測試、上線審批、自動化釋出上線及測試。下面是傳遞流水線的頁面截圖，每一個節點的狀态通過顔色區分，還可以點選檢視節點的具體發送和響應資訊。縱觀整個流水線，是自動化和人工相結合的一個過程，測試環節需要人工測試的參與，任何節點如果自動執行失敗的話，也要提供人工介入的入口，允許人工選擇重新執行、終止流程等動作，涉及上線需要人工稽核才能觸發自動化釋出節點等等，是以，流水線也不是一味追求自動化，需要自動和人工的結合。
4、環境部署
在環境部署這一環節，目前通過Docker以“容器化“的方式部署應用。利用容器化的快速部署優勢實作流水線快速推進；利用容器化高可擴充性的優勢實作基于負載的自動伸縮；利用容器化更加輕量級的優勢解決了應用和作業系統的強耦合問題；利于容器化高一緻性的優勢統一建構各環境，提高部署環境的一緻性。在DB申請環節，DB也是基于容器化來實作的，統一各環境的資料庫表結構，個性化各環境的獨有資料，比如賬戶資訊、商戶資訊等資料，并提供快速儲存功能以增量的方式儲存關鍵資料的更改。具體架構見下圖。流水線上的幾點各司其職，尤其鏡像制作比較複雜，我們通過鏡像管理平台實作鏡像制作以及線下到線上的轉推。應用傳遞方式和過程歸一化，并通過平台實作自助化和自動化。
以上通過持續內建、自動化測試、流水線以及自動化部署幾個要素對持續傳遞平台做了介紹。持續傳遞的價值應該展現在提升軟體傳遞效率，統一企業的軟體傳遞流程和規範，保證軟體傳遞品質和降低軟體釋出風險等方面，因為每個公司内部結構、形式都不一樣，一套方案肯定不能适用于所有公司，隻有最适合自己公司的東西才是最好的方案，我們團隊也在努力總結經驗，摸索前行，不斷完善符合自身特色的持續傳遞平台。
作者：孫鷹
來源：宜信技術學院