四要素落地持續(xù)交付

一、什么是持續(xù)交付

持續(xù)交付（Continuous delivery，縮寫為
CD），是一種軟件工程方法，讓軟件產(chǎn)品的產(chǎn)出過程在一個短周期內(nèi)完成，以保證軟件可以穩(wěn)定、持續(xù)的保持在隨時可以發(fā)布的狀況。它的目標在于讓軟件的編譯、測試與發(fā)布變得更快更頻繁。這種方式可以減少軟件開發(fā)的成本與時間，減少風險。
而我對持續(xù)交付的一個較為抽象的理解是“一套軟件工程方法論和許多最佳實踐的集合”。方法論和實踐都需要人去總結(jié)落地，所以，要想體會到持續(xù)交付的真正含義，就要在實際工作中貫徹和使用實踐工具。

二、持續(xù)交付的價值


其最大的顯性價值是，在實施持續(xù)交付后，能夠做到在保證交付質(zhì)量的前提下，加快交付速度，從而更快地得到市場反饋，推動產(chǎn)品的商業(yè)價值的實現(xiàn)。在互聯(lián)網(wǎng)應用盛行、速度為王的今天，持續(xù)交付的價值更被突顯出來。持續(xù)交付的能力，已成為評定一家互聯(lián)網(wǎng)公司研發(fā)能力的重要指標。除顯性價值外，如果站在不同角度看持續(xù)交付后的變化，我們還會發(fā)現(xiàn)一些隱性價值，而其中有一些影響甚至遠遠超過我們的預期。

1、通過快速靈活統(tǒng)一的環(huán)境構(gòu)建，全面改善企業(yè)對測試環(huán)境的管理方法，使得環(huán)境管理更合理、更自由。

2、標準、規(guī)范、流程的落地，都需要載體，而最好的載體就是平臺工具。而持續(xù)交付是一整套平臺工具的落地，幾乎涵蓋了研發(fā)的整個生命周期，是天然的、最佳的載體。


3、持續(xù)交付能夠向各個協(xié)作部門輸出統(tǒng)一的標準、流程和工具，提升溝通效率；并且通過大量的自動化，進一步提升各部門工作效率；還可以快速集成，把各個分散的小團隊，無論是橫向的業(yè)務研發(fā)團隊，還是縱向的技術(shù)框架團隊，緊緊地聯(lián)系在一起，共同進退。

4、生產(chǎn)故障永遠是無法完全避免的，那么，解決生產(chǎn)故障的最好辦法就是快速回退（回復），而快速回退正是持續(xù)交付著力打造的能力之一。

三、持續(xù)交付的落地

了解了持續(xù)交付的價值以后，我們再看持續(xù)交付在我們團隊的具體推進實踐。坦誠地說，在任何一個團隊推行持續(xù)交付都不是易事。

* 首先這會影響整個的研發(fā)生命周期，會涉及到流程、團隊、工具等多個方面，需要突破當前組織的束縛，引起大量的技術(shù)和組織變革。
* 其次大多數(shù)團隊都希望能夠快速見效，立竿見影。

但是，“持續(xù)交付”的改進過程本身就是一個持續(xù)迭代的過程，需要多次循環(huán)才能體現(xiàn)效果。甚至在實施初期，因為開發(fā)習慣和流程變化，團隊在適應的過程中效率會有暫時的下降。

我們之所以開始做持續(xù)交付：

*
一方面是因為隨著團隊規(guī)模、體量的增大，比如我們應用數(shù)量達到了500+，系統(tǒng)之間依賴度高，需要有平臺化的交付系統(tǒng)來支撐大量業(yè)務上線，且通過交付平臺去解決工程問題，解放業(yè)務研發(fā)人員的大腦，讓他們可以專注于業(yè)務研發(fā)而不是工程問題，比如環(huán)境查看，部署等；
* 另一方面，團隊也在做應用環(huán)境容器化，這也為持續(xù)交付提供了很好的支撐。

領(lǐng)導對此事非常重視，專門抽調(diào)運維、DBA、測試開發(fā)同事臨時組建虛擬的效能研發(fā)團隊，了解需求，分析各項目特點，封閉開發(fā)3個月的時間，打造出基礎(chǔ)級的持續(xù)交付中系統(tǒng)，并以一個項目為試點，通過數(shù)據(jù)去說服同事對接進來。

四、持續(xù)交付四要素

從代碼提交開始，我們可以把整個持續(xù)交付歸納出四個關(guān)鍵要素：持續(xù)集成、自動化測試、自動化部署、流水線。下面分別從四個關(guān)鍵要素解讀我們的持續(xù)交付平臺。

1、持續(xù)集成

將代碼開發(fā)和集成按模塊拆分成多個小階段，每一階段完成后都會進行集成，這在一定程度上減少了風險。
我們要求在代碼提交時即觸發(fā)編譯。構(gòu)建時會對整個應用的所有模塊進行編譯，并伴隨單元測試以及代碼質(zhì)量分析。如果構(gòu)建過程失敗了，那么必須立即郵件告警到相關(guān)開發(fā)責任人，并責令立即修復問題，如果20分鐘內(nèi)無法修復，就要回退代碼提交，總之，要求代碼庫的代碼持續(xù)處于可用狀態(tài)。
目前，每次成功的構(gòu)建（編譯+單元測試+代碼質(zhì)量分析）一般在5分鐘內(nèi)完成，單元測試中的外部依賴通過Mock的方式解決，這塊我們會在后續(xù)的文章中專門講解分析。持續(xù)集成保證了代碼始終是可用的，編譯正確并且通過所有單元測試和代碼靜態(tài)檢測，這些動作都發(fā)生在代碼部署到環(huán)境之前，是持續(xù)交付流水線的第一步。



2、自動化測試


互聯(lián)網(wǎng)產(chǎn)品要求全回歸測試要快，那么，如何在保證測試質(zhì)量和測試覆蓋率的前提下，有效鎖定測試執(zhí)行時間呢？首先，測試執(zhí)行集群是很好的思路，通過并發(fā)機制提升執(zhí)行效率，其次測試策略也是一個突破口。傳統(tǒng)軟件產(chǎn)品的測試策略，同時采用金字塔模型，這是邁克·科恩提出的，在很長一段時間內(nèi)都被認為是測試策略設(shè)計的最佳實踐。

但是，互聯(lián)網(wǎng)產(chǎn)品具有快速迭代，微服務架構(gòu)重后端等特性，我們應當遵循“重量級API測試，輕量級GUI測試，輕量級單元測試”的原則。以中間層的 API
測試為重點做全面的測試，盡可能提升自動化比率；輕量級的 GUI 測試，只覆蓋最核心直接影響主營業(yè)務流程的；最上層的 GUI
測試通常利用探索式測試思維，以人工測試的方式發(fā)現(xiàn)盡可能多的潛在問題；單元測試采用“分而治之”，主攻穩(wěn)定且核心業(yè)務。




雖然自動化測試的理念已經(jīng)普及了好多年，但是據(jù)我了解很多企業(yè)內(nèi)部，還是以手工測試為主，原因很多，比如人員缺乏和時間周期緊張，來不及寫自動化測試腳本，或者測試人員的水平不足等。


我們在團隊成立最初階段，也同樣存在此問題，測試人員是有開發(fā)自動化測試能力的，但是因為項目接連上線，時間周期緊張，測試人員忙于理解業(yè)務支持業(yè)務測試上線，沒有獨立的時間去完善自動化用例，彼時自動化測試相對薄弱。產(chǎn)品發(fā)布又需要不斷迭代，每次發(fā)布都需要大量的測試人力投入，其中重復的測試工作占比不少，發(fā)布的次數(shù)越多，成本越高，限制了快速頻繁發(fā)布的能力，我們曾一度裹挾在新業(yè)務功能測試和大量重復的手工回歸任務中疲于應對，也有過為了節(jié)省時間成本，僅通過開發(fā)人員對于功能調(diào)整影響范圍的預估，縮小回歸測試的范圍，承擔了線上事故帶來的苦果。


經(jīng)過權(quán)衡，我們下決心要大力推動自動化測試，專門抽調(diào)人員成立自動化小組，雖然短期內(nèi)對業(yè)務上線時間造成一定影響，但是我們頂著壓力度過了困難期，陸續(xù)完成了API自動化測試平臺，性能測試平臺、Web-UI自動化框架、APP云測、Mock
Server等系統(tǒng)，并和持續(xù)交付平臺很好地結(jié)合到一起。API測試平臺是我們自動化測試的核心，下圖是平臺架構(gòu)，實現(xiàn)了測試數(shù)據(jù)和邏輯的分離，同步異步API結(jié)果驗證，連續(xù)且參數(shù)傳遞API用例測試，微服務下API消費契約測試等主要功能，其中核心處理器既能手動觸發(fā)也能提供rest的接口供持續(xù)交付流水線調(diào)用。具體的內(nèi)部實現(xiàn)邏輯我在另外一篇API測試實踐的文章中再細談。



3、交付流水線


交付流水線包括了從開發(fā)提交代碼，觸發(fā)構(gòu)建，部署測試環(huán)境，測試環(huán)境自動化以及測試、準生產(chǎn)環(huán)境部署到測試、上線審批、自動化發(fā)布上線及測試。下面是交付流水線的頁面截圖，每一個節(jié)點的狀態(tài)通過顏色區(qū)分，還可以點擊查看節(jié)點的具體發(fā)送和響應信息?？v觀整個流水線，是自動化和人工相結(jié)合的一個過程，測試環(huán)節(jié)需要人工測試的參與，任何節(jié)點如果自動執(zhí)行失敗的話，也要提供人工介入的入口，允許人工選擇重新執(zhí)行、終止流程等動作，涉及上線需要人工審核才能觸發(fā)自動化發(fā)布節(jié)點等等，所以，流水線也不是一味追求自動化，需要自動和人工的結(jié)合。



4、環(huán)境部署


在環(huán)境部署這一環(huán)節(jié)，目前通過Docker以“容器化“的方式部署應用。利用容器化的快速部署優(yōu)勢實現(xiàn)流水線快速推進；利用容器化高可擴展性的優(yōu)勢實現(xiàn)基于負載的自動伸縮；利用容器化更加輕量級的優(yōu)勢解決了應用和操作系統(tǒng)的強耦合問題；利于容器化高一致性的優(yōu)勢統(tǒng)一構(gòu)建各環(huán)境，提高部署環(huán)境的一致性。在DB申請環(huán)節(jié)，DB也是基于容器化來實現(xiàn)的，統(tǒng)一各環(huán)境的數(shù)據(jù)庫表結(jié)構(gòu)，個性化各環(huán)境的獨有數(shù)據(jù)，比如賬戶信息、商戶信息等數(shù)據(jù)，并提供快速保存功能以增量的方式保存關(guān)鍵數(shù)據(jù)的更改。具體架構(gòu)見下圖。流水線上的幾點各司其職，尤其鏡像制作比較復雜，我們通過鏡像管理平臺實現(xiàn)鏡像制作以及線下到線上的轉(zhuǎn)推。應用交付方式和過程歸一化，并通過平臺實現(xiàn)自助化和自動化。




以上通過持續(xù)集成、自動化測試、流水線以及自動化部署幾個要素對持續(xù)交付平臺做了介紹。持續(xù)交付的價值應該體現(xiàn)在提升軟件交付效率，統(tǒng)一企業(yè)的軟件交付流程和規(guī)范，保證軟件交付質(zhì)量和降低軟件發(fā)布風險等方面，因為每個公司內(nèi)部結(jié)構(gòu)、形式都不一樣，一套方案肯定不能適用于所有公司，只有最適合自己公司的東西才是最好的方案，我們團隊也在努力總結(jié)經(jīng)驗，摸索前行，不斷完善符合自身特色的持續(xù)交付平臺。

作者：孫鷹

來源：宜信技術(shù)學院

• ? 上一篇：ASP.NET Core - 實現(xiàn)自定義WebApi模型驗證
• ? 下一篇：Windbg程序調(diào)試系列2-內(nèi)存泄露問題