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

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

現(xiàn)狀背景

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

解決方案

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

1.端到端交付全景圖

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

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

3.云代碼托管

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

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

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

4.分支管理策略

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

5.代碼評審

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

6.代碼覆蓋率檢測

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

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

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

7.持續(xù)集成

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

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

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

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

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

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

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

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

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

8.多維度制品庫管理

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

1)snapshot制品庫

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

2)alpha制品庫

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

3)release制品庫

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

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

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

實(shí)踐情況

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

效果評價(jià)：

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

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

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

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

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

采用DevOps實(shí)踐效果對比

推廣

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