點擊上方“中興開發者社區”，關注我們

每天讀一篇一線開發者原創好文

現狀背景

某項目是為配合大視頻運維推出的一個項目，需求和任務管理停留在原始的ts上，項目依托svn進行代碼管理，結合jenkins實現持續集成，測試方法偏向使用專項工具進行手工測試的補充。在項目初期經常出現版本交付困難或提交系統測試的交付版本質量滿足不了1輪發布要求，開發和測試人員疲于應對版本提交后的需求調整和故障修復，代碼評審受限于物理空間和時間,不能逐行確認, 自動化測試沒有整體框架，各個專項工具不能整合或擴充；代碼靜態檢查工具等幫助提升版本質量和研發過程效率的工具沒有利用起來。

解決方案

經過研究，也借鑒公司各個兄弟項目的DevOps優秀經驗并與某項目的實際情況相結合，經過不斷的演進，最終形成了以TFS 作為需求和任務管理平臺, 以Gerrit代碼審核服務器為核心構建整合代碼提交、并發測試、靜態檢查、評審、反饋以及入庫等完整代碼流程，引入分層云CI實現了代碼提交評審VerifyCI、代碼合入受控庫MergeCI、每日代碼質量檢測的DailyCI三級質量防護，版本持續迭代和在現網的小批量灰度發布,實現現網運維數據的收集并根據收集的數據改良我們的探針采集建模模型。

1.端到端交付全景圖

2.需求任務可視化

采用TFS輔助敏捷流程，跟蹤需求、用戶故事、Task完成情況

3.云代碼托管

在項目敏捷化迭代演進過程中,很重要的一部分是代碼管理，原來使用svn代碼管理下載速度慢，非常依賴服務器的硬件資源配置， 代碼提交前線下代碼評審比較粗糙，評審過后需要手工合入容易出錯且低效。經過對比考察，使用GIT工具管理源碼，不僅提高代碼獲取效率，而且與Gerrit配合開啟代碼評審功能，提高合入效率。

Git 和其他版本控制系統的主要差別在于，Git 只關心文件數據的整體是否發生變化，而大多數其他系統則只關心文件內容的具體差異,但并不保存這些前后變化的差異數據。實際上，Git 更像是把變化的文件作快照后，記錄在一個微型的文件系統中。每次提交更新時，它會縱覽一遍所有文件的指紋信息并對文件作一快照，然后保存一個指向這次快照的索引。為提高性能，若文件沒有變化，Git不會再次保存，而只對上次保存的快照作一鏈接。

在 Git 中的絕大多數操作都只需要訪問本地文件和資源，不用連網。因為 Git 在本地磁盤上就保存著所有當前項目的歷史更新，所以處理起來速度飛快。舉個例子，如果要瀏覽項目的歷史更新摘要，Git不用跑到外面的服務器上去取數據回來，而直接從本地數據庫讀取后展示給你看。所以任何時候你都可以馬上翻閱，無需等待。如果想要看當前版本的文件和一個月前的版本之間有何差異，Git 會取出一個月前的快照和當前文件作一次差異運算，而不用請求遠程服務器來做這件事，或是把老版本的文件拉到本地來作比較。

4.分支管理策略

原來的分支策略是為不同市場定制需求采用分支版本，開發過程中公共需求采用主線，具體市場發布時采用分支方式，代碼同步耗時過多，極端情況下一個通用的Bug修復要同時同步到幾個活躍分支, 而且CI開展只是覆蓋主線問題容易泄露。切換到git后,項目調整為采取單一master主干為主，少量臨時Feature分支為輔的開發模式。主干通過自動化測試和人工測試結合保證基本功能，實現代碼分支實時可用,可按需發布；對于在master上開發的少量變化大的短周期Feature基于master拉分支開發，自測通過后master進行歸并：

5.代碼評審

Gerrit是一種免費、開放源代碼的代碼審查軟件，使用網頁界面。利用瀏覽器，同一個團隊的開發人員，可以相互審閱彼此修改后的程序代碼，決定是否能夠提交，退回或者繼續修改。公司技術部統一提供Git和Gerrit支持，為了充分利用Git的特性，將項目的代碼托管在公司云服務器，并通過Gerrit實現開發人員之間代碼的互相審核。解決了之前人工看電影式的走查存在的不細致, 記錄失真或者合入失真等問題， 下圖為使用gerrit效果圖：

6.代碼覆蓋率檢測

在功能代碼開發環節和測試用例開發環節，我們引入了gcov代碼覆蓋率檢測工具，通過其lcov生成的掃描報告,如下圖所示:

報表中清晰地指出了代碼行級別的覆蓋，包括：1.每一行代碼的執行頻率；2.實際上哪些代碼確實被執行了；3.每一段代碼(section code)的耗時(執行時間)

根據上述報表，可以清晰地看到代碼是否有冗余或者測試用例設計考慮不周全導致覆蓋率偏低，然后針對性地進行分析和優化改進。

7.持續集成

為了提升代碼產出質量，首先對某的自動化測試環節進行了梳理，把之前零散的專項工具通過基于RF（RobotFrameware)測試框架進行了改造，并引入了分層云CI, 在不同維度上進行分層代碼質量檢測。云CI通過pipeline實現了VerifyCI、MergeCI和DailyCI三個層級持續集成,使得代碼庫變更通過pipeline來組件自動化掃描檢測以郵件推送方式得到及時反饋，示意如下圖：

1)持續集成——VerifyCI

開發人員調試自測通過代碼，提交到gerrit托管庫時，會自動觸發VerfyCI，進行編譯檢測，代碼圈復雜度掃描、UT測試等，并進行VerifyCI+2自動參與代碼評審，并通過郵件自動推送結果。當開發人員開發完成代碼的編寫后，在個人開發環境上就可以立即對自己修改的代碼執行靜態檢查、圈復雜度檢查和UT測試，問題可以在提交gerrit評審庫之前就暴露出來，能夠更早的獲取代碼質量的反饋。實際效果如下圖所示：

2)持續集成——MergeCI

評審通過之后，準許入庫git，提交Merge后會觸發代碼編譯檢測、代碼圈復雜度檢查、商業版的KW靜態代碼掃描、FT功能測試等，并把每個pipeline插件環節的執行結果以郵件的方式實時推送給項目相關成員，執行結果一目了然：

3)持續集成——DailyCI

在某主線分支，我們每天定時觸發進行每日構建，并完成ST系統（包括壓力測試拷機等）測試，執行我完成同樣會生成結果郵件并推送給團隊成員。受資源限制我們設定的定時時間是半夜啟動執行，但第二天一上班就可以看到相關結果，充分利用自動化填報了晚上大家休息的空閑時間。

而且，在掃描過程中的可以設定相關閾值，不滿足要求的可以亮紅燈，進行回退整改。

（備注：CI原則是:紅燈不過夜,如不能及時修復可以先回退,解決后再重新合入）

8.多維度制品庫管理

從制品庫類型分：某的制品庫分為snapshot、alpha、release三個庫。三個庫的功能各不相同，snapshot庫存儲CI中每日構建版本，alpha庫主要存儲供內部測試的穩定版本，release存儲對外發布版本。

1)snapshot制品庫

存放的是每日CI構建的過程版本，這種類型版本通過基本自動化測試,一般用于后續的臨時問題驗證和主線迭代手工測試。

2)alpha制品庫

存放的是經過自動化和手工測試驗證的穩定迭代版本，這種類型版本主要是要開發環節自測可內部發布,提交測試部進行后續占比約20%的系統測試。

3)release制品庫

存放的是通過系統測試，可以進行實際發布部署的版本。

4)灰度發布&持續優化

Release制品庫中的版本，規劃人員會推動現場小批量灰度升級部署，跟蹤升級后的運維指標變化情況后，如果沒發現異常則再安排進行大規模升級部署；如果發現有異常需要修復則反饋給開發團隊修復后重新迭代發布，形成從需求到開發測試及運維的PDCA閉環。

實踐情況

通過項目端到端的流程變革,實現了某探針項目需求開發過程更順暢、團隊產出質量明顯提升，形成了需求、開發、測試和運維相關人員的及時良性互動。

效果評價：

• 代碼分支從svn切換到git,下載速度快，提升了版本構建效率

• 需求經過了充分討論和評審，并在不同維度上進行了拆分

• 實現了任務管理可視化，可以及時干預或調整優先級管控風險

• 代碼提交、評審到主分支入庫進行了有效管控

• 評審、CI測試、靜態檢查等過程有及時有效的反饋環

采用DevOps實踐效果對比

推廣

本文簡要描述了某項目嘗試實踐DevOps工具鏈的過程和前后效果對比，在端到端交付方面進行了摸索，通過優化研發流程提升了團隊的整體效率，當然在很多方面我們做到還不夠精細還需要繼續優化完善，這個轉型過程值得相關項目進行參考。