一、什麼是持續交付
持續交付（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也是基於容器化來實現的，統一各環境的數據庫表結構，個性化各環境的獨有數據，比如賬戶信息、商戶信息等數據，並提供快速保存功能以增量的方式保存關鍵數據的更改。具體架構見下圖。流水線上的幾點各司其職，尤其鏡像製作比較複雜，我們通過鏡像管理平臺實現鏡像製作以及線下到線上的轉推。應用交付方式和過程歸一化，並通過平臺實現自助化和自動化。
以上通過持續集成、自動化測試、流水線以及自動化部署幾個要素對持續交付平臺做了介紹。持續交付的價值應該體現在提升軟件交付效率，統一企業的軟件交付流程和規範，保證軟件交付質量和降低軟件發佈風險等方面，因爲每個公司內部結構、形式都不一樣，一套方案肯定不能適用於所有公司，只有最適合自己公司的東西纔是最好的方案，我們團隊也在努力總結經驗，摸索前行，不斷完善符合自身特色的持續交付平臺。
作者：孫鷹
來源：宜信技術學院