點擊上方“中興開發(fā)者社區(qū)”，關(guān)注我們

每天讀一篇一線開發(fā)者原創(chuàng)好文

現(xiàn)狀背景

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

解決方案

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

1.端到端交付全景圖

2.需求任務(wù)可視化

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

3.云代碼托管

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

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

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

4.分支管理策略

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

5.代碼評審

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

6.代碼覆蓋率檢測

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

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

根據(jù)上述報表，可以清晰地看到代碼是否有冗余或者測試用例設(shè)計考慮不周全導(dǎo)致覆蓋率偏低，然后針對性地進(jìn)行分析和優(yōu)化改進(jìn)。

7.持續(xù)集成

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

1)持續(xù)集成——VerifyCI

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

2)持續(xù)集成——MergeCI

評審?fù)ㄟ^之后，準(zhǔn)許入庫git，提交Merge后會觸發(fā)代碼編譯檢測、代碼圈復(fù)雜度檢查、商業(yè)版的KW靜態(tài)代碼掃描、FT功能測試等，并把每個pipeline插件環(huán)節(jié)的執(zhí)行結(jié)果以郵件的方式實時推送給項目相關(guān)成員，執(zhí)行結(jié)果一目了然：

3)持續(xù)集成——DailyCI

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

而且，在掃描過程中的可以設(shè)定相關(guān)閾值，不滿足要求的可以亮紅燈，進(jìn)行回退整改。

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

8.多維度制品庫管理

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

1)snapshot制品庫

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

2)alpha制品庫

存放的是經(jīng)過自動化和手工測試驗證的穩(wěn)定迭代版本，這種類型版本主要是要開發(fā)環(huán)節(jié)自測可內(nèi)部發(fā)布,提交測試部進(jìn)行后續(xù)占比約20%的系統(tǒng)測試。

3)release制品庫

存放的是通過系統(tǒng)測試，可以進(jìn)行實際發(fā)布部署的版本。

4)灰度發(fā)布&持續(xù)優(yōu)化

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

實踐情況

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

效果評價：

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

• 需求經(jīng)過了充分討論和評審，并在不同維度上進(jìn)行了拆分

• 實現(xiàn)了任務(wù)管理可視化，可以及時干預(yù)或調(diào)整優(yōu)先級管控風(fēng)險

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

• 評審、CI測試、靜態(tài)檢查等過程有及時有效的反饋環(huán)

采用DevOps實踐效果對比

推廣

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