四要素落地持續交付

本文經過持續集成、自動化測試、流水線以及自動化部署幾個要素介紹宜信的持續交付平臺及實踐。

1、什麼是持續交付

持續交付（Continuous delivery，縮寫爲 CD），是一種軟件工程方法，讓軟件產品的產出過程在一個短週期內完成，以保證軟件能夠穩定、持續的保持在隨時能夠發佈的情況。它的目標在於讓軟件的編譯、測試與發佈變得更快更頻繁。這種方式能夠減小軟件開發的成本與時間，減小風險。 而我對持續交付的一個較爲抽象的理解是「一套軟件工程方法論和許多最佳實踐的集合」。方法論和實踐都須要人去總結落地，因此，要想體會到持續交付的真正含義，就要在實際工做中貫徹和使用實踐工具。

2、持續交付的價值

其最大的顯性價值是，在實施持續交付後，可以作到在保證交付質量的前提下，加快交付速度，從而更快地獲得市場反饋，推進產品的商業價值的實現。在互聯網應用盛行、速度爲王的今天，持續交付的價值更被突顯出來。持續交付的能力，已成爲評定一家互聯網公司研發能力的重要指標。除顯性價值外，若是站在不一樣角度看持續交付後的變化，咱們還會發現一些隱性價值，而其中有一些影響甚至遠遠超過咱們的預期。

一、經過快速靈活統一的環境構建，全面改善企業對測試環境的管理方法，使得環境管理更合理、更自由。

二、標準、規範、流程的落地，都須要載體，而最好的載體就是平臺工具。而持續交付是一整套平臺工具的落地，幾乎涵蓋了研發的整個生命週期，是自然的、最佳的載體。

三、持續交付可以向各個協做部門輸出統一的標準、流程和工具，提高溝通效率；而且經過大量的自動化，進一步提高各部門工做效率；還能夠快速集成，把各個分散的小團隊，不管是橫向的業務研發團隊，仍是縱向的技術框架團隊，牢牢地聯繫在一塊兒，共同進退。

四、生產故障永遠是沒法徹底避免的，那麼，解決生產故障的最好辦法就是快速回退（回覆），而快速回退正是持續交付着力打造的能力之一。

3、持續交付的落地

瞭解了持續交付的價值之後，咱們再看持續交付在咱們團隊的具體推動實踐。坦誠地說，在任何一個團隊推行持續交付都不是易事。

• 首先這會影響整個的研發生命週期，會涉及到流程、團隊、工具等多個方面，須要突破當前組織的束縛，引發大量的技術和組織變革。
• 其次大多數團隊都但願可以快速見效，立竿見影。

可是，「持續交付」的改進過程自己就是一個持續迭代的過程，須要屢次循環才能體現效果。甚至在實施初期，由於開發習慣和流程變化，團隊在適應的過程當中效率會有暫時的降低。

咱們之因此開始作持續交付：

• 一方面是由於隨着團隊規模、體量的增大，好比咱們應用數量達到了500+，系統之間依賴度高，須要有平臺化的交付系統來支撐大量業務上線，且經過交付平臺去解決工程問題，解放業務研發人員的大腦，讓他們能夠專一於業務研發而不是工程問題，好比環境查看，部署等；
• 另外一方面，團隊也在作應用環境容器化，這也爲持續交付提供了很好的支撐。

領導對此事很是重視，專門抽調運維、DBA、測試開發同事臨時組建虛擬的效能研發團隊，瞭解需求，分析各項目特色，封閉開發3個月的時間，打造出基礎級的持續交付中系統，並以一個項目爲試點，經過數據去說服同事對接進來。

4、持續交付四要素

從代碼提交開始，咱們能夠把整個持續交付概括出四個關鍵要素：持續集成、自動化測試、自動化部署、流水線。下面分別從四個關鍵要素解讀咱們的持續交付平臺。

一、持續集成

將代碼開發和集成按模塊拆分紅多個小階段，每一階段完成後都會進行集成，這在必定程度上減小了風險。 咱們要求在代碼提交時即觸發編譯。構建時會對整個應用的全部模塊進行編譯，並伴隨單元測試以及代碼質量分析。若是構建過程失敗了，那麼必須當即郵件告警到相關開發責任人，並責令當即修復問題，若是20分鐘內沒法修復，就要回退代碼提交，總之，要求代碼庫的代碼持續處於可用狀態。 目前，每次成功的構建（編譯+單元測試+代碼質量分析）通常在5分鐘內完成，單元測試中的外部依賴經過Mock的方式解決，這塊咱們會在後續的文章中專門講解分析。持續集成保證了代碼始終是可用的，編譯正確而且經過全部單元測試和代碼靜態檢測，這些動做都發生在代碼部署到環境以前，是持續交付流水線的第一步。

二、自動化測試

互聯網產品要求全迴歸測試要快，那麼，如何在保證測試質量和測試覆蓋率的前提下，有效鎖定測試執行時間呢？首先，測試執行集羣是很好的思路，經過併發機制提高執行效率，其次測試策略也是一個突破口。傳統軟件產品的測試策略，同時採用金字塔模型，這是邁克·科恩提出的，在很長一段時間內都被認爲是測試策略設計的最佳實踐。

可是，互聯網產品具備快速迭代，微服務架構重後端等特性，咱們應當遵循「重量級API測試，輕量級GUI測試，輕量級單元測試」的原則。以中間層的 API 測試爲重點作全面的測試，儘量提高自動化比率；輕量級的 GUI 測試，只覆蓋最核心直接影響主營業務流程的；最上層的 GUI 測試一般利用探索式測試思惟，以人工測試的方式發現儘量多的潛在問題；單元測試採用「分而治之」，主攻穩定且核心業務。

雖然自動化測試的理念已經普及了好多年，可是據我瞭解不少企業內部，仍是以手工測試爲主，緣由不少，好比人員缺少和時間週期緊張，來不及寫自動化測試腳本，或者測試人員的水平不足等。

咱們在團隊成立最初階段，也一樣存在此問題，測試人員是有開發自動化測試能力的，可是由於項目接連上線，時間週期緊張，測試人員忙於理解業務支持業務測試上線，沒有獨立的時間去完善自動化用例，彼時自動化測試相對薄弱。產品發佈又須要不斷迭代，每次發佈都須要大量的測試人力投入，其中重複的測試工做佔比很多，發佈的次數越多，成本越高，限制了快速頻繁發佈的能力，咱們曾一度裹挾在新業務功能測試和大量重複的手工迴歸任務中疲於應對，也有過爲了節省時間成本，僅經過開發人員對於功能調整影響範圍的預估，縮小回歸測試的範圍，承擔了線上事故帶來的苦果。

通過權衡，咱們下決心要大力推進自動化測試，專門抽調人員成立自動化小組，雖然短時間內對業務上線時間形成必定影響，可是咱們頂着壓力度過了困難期，陸續完成了API自動化測試平臺，性能測試平臺、Web-UI自動化框架、APP雲測、Mock Server等系統，並和持續交付平臺很好地結合到一塊兒。API測試平臺是咱們自動化測試的核心，下圖是平臺架構，實現了測試數據和邏輯的分離，同步異步API結果驗證，連續且參數傳遞API用例測試，微服務下API消費契約測試等主要功能，其中核心處理器既能手動觸發也能提供rest的接口供持續交付流水線調用。具體的內部實現邏輯我在另一篇API測試實踐的文章中再細談。

三、交付流水線

交付流水線包括了從開發提交代碼，觸發構建，部署測試環境，測試環境自動化以及測試、準生產環境部署到測試、上線審批、自動化發佈上線及測試。下面是交付流水線的頁面截圖，每個節點的狀態經過顏色區分，還能夠點擊查看節點的具體發送和響應信息。縱觀整個流水線，是自動化和人工相結合的一個過程，測試環節須要人工測試的參與，任何節點若是自動執行失敗的話，也要提供人工介入的入口，容許人工選擇從新執行、終止流程等動做，涉及上線須要人工審覈才能觸發自動化發佈節點等等，因此，流水線也不是一味追求自動化，須要自動和人工的結合。

四、環境部署

在環境部署這一環節，目前經過Docker以「容器化「的方式部署應用。利用容器化的快速部署優點實現流水線快速推動；利用容器化高可擴展性的優點實現基於負載的自動伸縮；利用容器化更加輕量級的優點解決了應用和操做系統的強耦合問題；利於容器化高一致性的優點統一構建各環境，提升部署環境的一致性。在DB申請環節，DB也是基於容器化來實現的，統一各環境的數據庫表結構，個性化各環境的獨有數據，好比帳戶信息、商戶信息等數據，並提供快速保存功能以增量的方式保存關鍵數據的更改。具體架構見下圖。流水線上的幾點各司其職，尤爲鏡像製做比較複雜，咱們經過鏡像管理平臺實現鏡像製做以及線下到線上的轉推。應用交付方式和過程歸一化，並經過平臺實現自助化和自動化。

以上經過持續集成、自動化測試、流水線以及自動化部署幾個要素對持續交付平臺作了介紹。持續交付的價值應該體如今提高軟件交付效率，統一企業的軟件交付流程和規範，保證軟件交付質量和下降軟件發佈風險等方面，由於每一個公司內部結構、形式都不同，一套方案確定不能適用於全部公司，只有最適合本身公司的東西纔是最好的方案，咱們團隊也在努力總結經驗，摸索前行，不斷完善符合自身特點的持續交付平臺。

做者：孫鷹

來源：宜信技術學院