2015-2016年，珍愛線下門店已新增覆蓋城市9個，與此同時，CRM系統大小故障卻發生了數十起... ...

珍愛網是以「網路徵選+人工紅娘」模式提供婚配服務的婚戀相親平台。CRM系統承載了整個珍愛網會員的全生命周期管理，涵蓋資源挖掘、用戶觸達渠道以及服務跟進體系。

CRM系統對珍愛5400名紅娘來說，是承載她們全部工作的核心平台；對公司業務來說，承載著引流、轉化、支付、客戶服務等全部環節。最最重要的是，公司收入的80%都是依託CRM系統完成的。

然而在珍愛網成立10年之際，運行10年之久的CRM系統已不足以支撐業務的快速發展了。

Part.1

我們為什麼要做DevOps

經過分析，我們發現CRM系統目前面臨著以下問題：

技術上——

• 傳統的系統架構，不再適應敏捷開發，模塊耦合，資料庫存在單點故障；
• 容錯性差，冗餘代碼多，修復bug和實現新功能變得困難和耗時。

產品上——

• 產品功能不夠場景化、電子化、智能化；
• 無法快速響應業務變化，迭代周期長。

我們可是背負著「成就天下姻緣」使命呢，系統重構，研發流程改進，迫在眉睫。

2017年1月25日，捷豹項目組成立，只為給業務打造一個「簡單·好用」專註於婚戀相親的綜合服務平台。

捷豹CRM系統（PC端、Pad端、小程序端）的版本發布周期為一周一個常規迭代，緊急版本按天發布。

捷豹CRM系統整體設計思路如下圖，我們希望能夠實現系統的服務解耦、動靜分離以及高可用。

然而大家都知道，微服務架構中每個服務都具有業務屬性，並且能獨立地被開發、測試、構建、部署。換句話說，每個服務都是一個可交付的「系統」。

那麼問題來了，如何讓需求以小批量形式在團隊的各個角色間順暢流動，並以較短的周期完成小粒度的持續發布呢？

答案當然是 TAPD DevOps流水線，簡直是神助攻！

Part.2

整體效果

TAPD DevOps流水線支持集成主流的研發工具，覆蓋產品研發全生命周期，提供可視化交付流水線，可以將DevOps各個環節進行統一展示和管理，真正實現一站式持續交付。

自2017年10月起，我們就應用TAPD的DevOps流水線，開展了一系列持續交付和持續改進實踐。

持續交付部分

CI和CD實現過程使用Gitlab、Jenkins、Sonar、Jacoco、Nexus、EasyOps、Docker、Kubernetes等工具，分別在代碼管理、集成編譯、包管理、自動化測試、發布階段集成到TAPD流水線統一展示和管理。

持續改進部分

在TAPD流水線實踐DevOps的過程中，我們也打通了各環節的研發數據。

通過TAPD迭代詳情中的Dashboard，可以統計並展示當前迭代的研發效能數據，包括：需求完成情況、缺陷新增和解決情況、代碼提交與關聯趨勢、每日構建統計、構建產物版本情況、自動化測試、部署發布等全過程數據，研發效能度量更直觀、更深入，讓改進方向更明確，也讓效能提升更明顯。

改進效果

基於以上持續交付和持續改進實踐，我們的研發效能也有了質的提升。

我們從業務響應周期、持續交付能力、開發質量、交付質量四個方面來衡量研發效能，下圖展示了各個維度的改進效果。

Part.3

我們的DevOps是如何落地的

那麼我們具體怎樣利用TAPD DevOps流水線，一步步實現持續交付，最終提升研發效能的呢？

下面我將分享我們在各個環節的做法。

1 代碼管理環節

1.1 建立TAPD分支管理規範

改造前：

開發編碼過程中最崩潰的應該是：「我剛寫好的代碼又被誰覆蓋了！」

並行開發過程中，最痛苦的莫過於開發的需求太多， 記不清哪個需求在哪個分支上，或者多個需求在一個分支上開發，撤代碼撤到望眼欲穿……

改造後：

通過走訪調研，最終我們確定遵循「一個需求一個開發分支」的原則，方便管理且可追溯，並行開發，互不干擾。

在Jenkins上創建Job，通過TAPD和Git的API，將TAPD需求ID與Git分支關聯，創建的分支名為「工程名-創建日期-TAPD需求ID」，開發小哥哥去Gitlab上拉創建好的需求分支便可努力搬磚了。

待需求上線後轉關閉狀態的21天，自動將該分支刪除，整個分支管理過程實現自動化。

效果：

截至目前， 通過該Job創建分支次數達到1564次，創建成功的分支數遠大於1564*3 個，而合併衝突數小於5次。

1.2 TAPD源碼關聯

改造前：

在測試過程中， 最繁雜的應該是代碼合併環節了，一個需求涉及到多個工程的代碼變更，每天各個開發針對不同的需求，提測到測試同學進行代碼合併。

開發/測試的比例為4:1，需求涉及的前後端工程40餘個，面對一個需求到底要合併哪些工程，測試同學每天要在風中凌亂好幾回……

改造後：

與研發效能度量深度結合，良好編碼習慣，從源碼關聯開始。

通過源碼關聯功能，我們實現了以下閉環：

所有研發任務都必須錄入TAPD，並且只能通過需求ID來創建Git分支 → Commit信息必須關聯源碼提交 → 度量數據只獲取關聯源碼的代碼行 → 根據這部分數據進行研發效率和質量的度量。

測試同學只用關注該需求的Gitlab提交記錄即可知道本次變更涉及的工程有哪些，不用和開發一個個確認，減少溝通成本。

由於提交比較頻繁，我們寫了一個爬蟲腳本，將抓到的版本庫去重，得到該需求要合併的工程。然後我們將待合併工程，生成TAPD的合併任務分發給指定同學，將整個過程自動化管理。

效果：

綜上，通過「源碼管理」和「TAPD分支規範」，有效規避了代碼管理過程中，衝突多、管理亂、不可追溯的問題，同時也實現按需求粒度、靈活發布的效果。

自2018年10月以來，通過這套代碼合併任務自動分發方案，我們成功迭代上線了18個常規版本和10個緊急版本，整個過程簡單清晰，單任務合併整合環節，從原來的40分鐘，減少到5分鐘。

2 代碼質量分析

改造前：

Sonar其實很早就開始在項目過程中使用了，但是效果並不太好。

無論對於開發還是測試同學，都需要多維護一個系統，並且改動頻繁，當某一個服務經手的開發過多時，Sonar掃描出問題後無法快速分配責任開發。

另外Sonar配置到集成環境構建時觸發，讓bug從發現環節開始滯後，修復過程也對版本穩定性帶來風險。

改造後：

在2018年底，我們發現TAPD流水線集成Sonar，還可以一鍵創建缺陷到TAPD。

於是，我們將Sonar掃描前置到開發每一次提交到Git倉庫便觸發構建，讓Sonar缺陷在開發自測環節變暴露出來，同時，每一次構建能清晰的展示本次代碼變更人，開發可以安心地收下這一頁的bug啦。

當然，有的開發小哥哥可能沒有及時修復，沒關係， 測試小姐姐將未及時關閉的Sonar缺陷通過「批量導入缺陷功能」每天自動化（通過TAPD的API實現）創建到你的缺陷清單里，開發小哥哥再也不會錯過那些被遺忘的bug啦。

噢，貼心的TAPD還在缺陷詳情里把bug的文件名和代碼行都給展示了呢，開發小哥哥和測試小姐姐終於可以不跨系統維護Sonar了。

3 集成編譯環節

需求分支經過靜態掃描和自測通過後就要提交到集成環境啦。

在這個環節，除了常規編譯步驟，我們還增加了開發的單元測試和Jacoco覆蓋率檢測。在集成環境我們也增加了Sonar進行最後一次掃描確認。

單元測試框架為JUnit，與TAPD進行關聯，構建後在「自動化測試」板塊可以看到本次構建的單元測試用例總數和通過率（單元測試通過率是我們對研發質量度量的一個很重要的指標），單元測試不通過的case和Sonar掃描的bug處理方式一致，由API腳本統一錄入TAPD缺陷進行跟蹤。

單元測試的覆蓋率情況，方便開發同學分析單元測試用例對測試對象的分支覆蓋情況。

編譯後就是Sonar進行最後一道集成環境的全量代碼掃描工作了。

4 包管理環節

我們在包管理環節的實踐主要分為對 「jar包」和「Docker鏡像」的管理。

構建生成的jar包，推送到Maven倉庫（用於其他項目的依賴引用）。將Nexus集成到TAPD，通過「構建產物」可以看到軟體包的詳細信息。

同時，流水線可以清晰看到構建步驟的耗時分布，也幫助我們有針對性地去優化構建效率。

然後進行Docker鏡像打包，推送到Docker倉庫，生成配置，並推送到配置倉庫。

順便說說為什麼要用Docker吧！

項目初期只有一個dev環境，隨著版本構建的頻繁，穩定的測試環境對測試同學來說尤為關鍵，但是部署一套40餘工程的環境對運維同學來說工作量也非常之大，於是我們引入了容器技術。在環境搭建、應用遷移方面都有很好的收穫。

同時，基於珍愛的業務背景，特別是對於特殊節日搞活動時候，容器化能快速對服務進行橫向擴容；減少對環境的依賴，部署快、擴容快。同時容器運行時會對服務運行環境進行隔離，也有效提升了安全性和服務運行的穩定性。

5 自動化測試環節

自動化測試分為介面測試和UI自動化測試兩個部分。

介面測試主要通過開源工具實現，但涉及到跨系統維護，以及測試結果不能很好地跟蹤，因此在TAPD上嘗試用Python Unit Test做些核心場景的介面測試，以便於將這部分測試納入到整個研發流水線當中，構建成功後自動觸發場景介面測試，失敗的用例也能直接在TAPD跟蹤。

UI自動化，則是我們自己研發的平台，通過關鍵字驅動實現，並增加了代碼覆蓋率檢測，以幫助測試人員分析哪些分支情況是沒覆蓋到的。

測試結果轉為XML格式後也可以統一集成到TAPD管理，可以清晰直觀地展示自動化測試結果。

目前我們的自動化用例覆蓋業務流程達239個，case成功率94%，運行時長15min，代碼覆蓋率21%。

6 部署發布環節

我們整個發布流程簡單分為以下幾個步驟，部署發布環節主要用主流部署工具完成。

Part.4

研發效能度量

每月通過TAPD產生的過程數據進行研發過程效率和質量分析。同時我們也設立了相關獎項激勵大家正向PK，提升效率的同時更加重視研發質量。

研發效率分析

得益於TAPD的強大API，我們可以拿到需求交付過程數據。

通過深入分析，我們可以知道效率較低的環節到底是什麼原因導致，以制定更有效的提升效率的方案，可以是流程自動化，也可以是制定規範。

研發質量分析

而研發質量分析方面，我們希望能在團隊內部形成重視研發質量的共識和文化。

我們會統計出研發同學本月上線的任務數、代碼行、花費、生產bug，來計算出有效花費，遵循「好、多、快」原則，評選出優秀的個人和團隊進行表彰鼓勵。

噢，TAPD的API好好用，以上提到的腳本均由測試同學通過API實現，你會發現高效的質量度量是一件特別有意思的事情，質量度量後的效能提升更是一件特別有成就感的事情！

Part.5

總結

珍愛網捷豹CRM項目，應用TAPD DevOps可視化流水線，集成業界主流研發工具，實現一站式持續交付管理，讓整個研發過程清晰、直觀、透明。

在這一過程中，我們基於TAPD提供的API介面，進行了二次開發，實現了多個環節的自動化閉環。

此外，我們通過API以及TAPD Dashboard，獲取持續交付過程數據，從而進行研發效率和質量的分析以及持續改進。

基於以上實踐，我們從業務響應周期、持續交付能力、開發質量、交付質量4個方面衡量的研發效能，都有了顯著的提升。

我們將持續在此基礎之上不斷完善和優化，挖掘TAPD DevOps流水線的更多場景，全方位提升研發效能。

好咯， 今天的分享先到這裡啦，我要去開早會啦！

歡迎留言與我們多多交流哦~

想開始高效協作，請前往

TAPD-敏捷開發 項目管理 騰訊敏捷產品研發平台?

www.tapd.cn
推薦閱讀：