持續(xù)集成在敏捷開發(fā)模式中的應(yīng)用探析

袁宜霞

關(guān)鍵詞：敏捷開發(fā)模式；持續(xù)集成；自動(dòng)化測(cè)試；CI流水線

0 引言

隨著互聯(lián)網(wǎng)時(shí)代的到來，傳統(tǒng)的瀑布式開發(fā)無法應(yīng)對(duì)需求快速變化的缺點(diǎn)越來越明顯。面對(duì)市場(chǎng)商機(jī)的競(jìng)爭(zhēng)情況，各大企業(yè)需要快速上線產(chǎn)品并獲得市場(chǎng)反饋，所以各大企業(yè)普遍采用敏捷開發(fā)模式[1]。敏捷開發(fā)是以用戶需求為核心，把一個(gè)大項(xiàng)目拆分為多個(gè)可以獨(dú)立運(yùn)行的小項(xiàng)目[2]，在研發(fā)過程中，軟件始終處于可使用狀態(tài)。在現(xiàn)有產(chǎn)品基礎(chǔ)上，研發(fā)團(tuán)隊(duì)通過增加代碼來豐富功能和優(yōu)化用戶體驗(yàn)，每個(gè)團(tuán)隊(duì)成員每天都在生成和上傳代碼。未經(jīng)過驗(yàn)證的代碼合并后，如果不能快速檢查發(fā)現(xiàn)問題，會(huì)影響各自的功能或關(guān)聯(lián)模塊，而如果每個(gè)開發(fā)人員都手動(dòng)執(zhí)行來檢查問題，又會(huì)影響效率，特性的高頻率交付與軟件質(zhì)量之間的矛盾日漸尖銳，如何平衡兩者成為研發(fā)團(tuán)隊(duì)需要重點(diǎn)解決的問題。持續(xù)集成[3]就是解決這一個(gè)問題的利器，其采用高頻率自動(dòng)化檢查代碼方式，減少了手工執(zhí)行錯(cuò)誤，避免了重復(fù)性勞動(dòng)，且更快地發(fā)現(xiàn)錯(cuò)誤提高了產(chǎn)品質(zhì)量，是一種常見的敏捷工程實(shí)踐方法。增量代碼只有徹底解決持續(xù)集成過程中發(fā)現(xiàn)的問題才能通過持續(xù)集成的驗(yàn)證。

本文制定了一套持續(xù)集成的流程，介紹了本地IDE、合并請(qǐng)求MR和CI流水線等階段的具體實(shí)踐過程，并詳細(xì)闡述了實(shí)踐過程中的關(guān)鍵點(diǎn)。

1 持續(xù)集成的流程

為了同時(shí)兼顧質(zhì)量與效率，在提高發(fā)布頻率的情況下保證可靠性，持續(xù)集成在代碼集成、功能測(cè)試、部署發(fā)布、基礎(chǔ)設(shè)施架構(gòu)管理等各個(gè)環(huán)節(jié)都應(yīng)該有全面的自動(dòng)化監(jiān)控手段，盡量避免人工介入，圖1是一套持續(xù)集成的流程。

1.1 本地集成開發(fā)環(huán)境IDE 階段

開發(fā)團(tuán)隊(duì)都具有版本控制功能的代碼庫，各大公司一般使用SVN或者Git對(duì)代碼進(jìn)行版本管理。開發(fā)人員在個(gè)人工作區(qū)完成代碼開發(fā)后，先執(zhí)行自動(dòng)化驗(yàn)證集，用于驗(yàn)證自己修改的代碼質(zhì)量是否達(dá)標(biāo)，只有通過了自動(dòng)化驗(yàn)證才能push代碼到主干。自動(dòng)化驗(yàn)證包括本次增量以及相關(guān)代碼的單元測(cè)試和代碼規(guī)范掃描。

1） 單元測(cè)試

單元測(cè)試是指對(duì)軟件中的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證，可以是函數(shù)級(jí)、方法級(jí)、類級(jí)或者功能模塊級(jí)，本地IDE環(huán)境執(zhí)行的僅僅是本地增量代碼的單元測(cè)試。單元測(cè)試用例的編寫者既可以是開發(fā)人員也可以是測(cè)試人員：開發(fā)人員編寫用例的優(yōu)勢(shì)在于熟悉自身編寫的開發(fā)代碼，加上擁有較強(qiáng)的編程技能，所以單元測(cè)試編寫覆蓋率和效率都比較高，劣勢(shì)在于開發(fā)人員的開發(fā)時(shí)間緊張，普遍缺乏測(cè)試思維且代碼自寫自測(cè)無法達(dá)到絕對(duì)的客觀；測(cè)試人員編寫用例的優(yōu)勢(shì)在于具有較強(qiáng)的測(cè)試思維可以保證覆蓋率，借由編寫用例的機(jī)會(huì)能更好地了解代碼架構(gòu)和實(shí)現(xiàn)流程，有利于后續(xù)的功能測(cè)試，劣勢(shì)在于代碼實(shí)現(xiàn)能力相對(duì)較弱，效率會(huì)比較低。在各個(gè)業(yè)務(wù)線中，可以根據(jù)自身團(tuán)隊(duì)人員和產(chǎn)品特點(diǎn)來實(shí)際情況來確定單元測(cè)試用例的編寫者。

不同編程語言使用不同的單元測(cè)試框架，比如Java語言普遍使用Junit或TestNG[4]，Python語言普遍使用Unittest或者Pytest[5]。評(píng)估單元測(cè)試的重要標(biāo)準(zhǔn)是代碼覆蓋率，需要盡量覆蓋全部的開發(fā)代碼，常見的覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋和路徑覆蓋。

2） 代碼規(guī)范掃描

代碼規(guī)范掃描是指不需要編譯過程，通過詞法分析、語法分析和抽象語法樹分析等技術(shù)手段直接掃描源代碼，以便檢查代碼是否滿足規(guī)范性和是否有漏洞。針對(duì)不同開發(fā)語言，業(yè)界有多種不同的代碼規(guī)范掃描工具，持續(xù)集成可以依據(jù)是否開源、適用的編程語言、掃描結(jié)果展示、掃描速度、擴(kuò)展性和可維護(hù)性等方面選擇幾種工具進(jìn)行接入以達(dá)到更好的掃描效果。例如Findbugs能掃描Java代碼，PCLint和Cppcheck能掃描C/C++，golangci-lint 能掃描Go 語言，Pylint 和Flake8 能掃描Python，ESLint 能掃描JavaScrip 和NodeJs，Coverity Prevent和騰訊開源的TScanCode能掃描C/C++、C#，Sonarqube 開源且能支持Java、Python、PHP、JavaScript、CSS等25種以上的語言的掃描等[6]。

1.2 合并請(qǐng)求MR 階段

本地驗(yàn)證通過后，開發(fā)人員將本地修改的代碼與主干上已經(jīng)更新的代碼進(jìn)行合并，再執(zhí)行一次合入前檢查，確保本地修改的代碼與主干上最新代碼的合并沒有質(zhì)量問題。這次質(zhì)量驗(yàn)證會(huì)執(zhí)行產(chǎn)品全量代碼的單元測(cè)試、集成測(cè)試和代碼掃描規(guī)范，其中任意一項(xiàng)驗(yàn)證未通過都會(huì)結(jié)束合并請(qǐng)求并通知開發(fā)人員進(jìn)行修改。與本地IDE階段相比，單元測(cè)試和代碼掃描規(guī)范由本地增量和相關(guān)代碼變成全量代碼，新增了全量代碼的集成測(cè)試。集成測(cè)試的主要是通過模擬真實(shí)的用戶場(chǎng)景，從最終用戶的體驗(yàn)出發(fā)對(duì)多個(gè)已完成單元測(cè)試的模塊進(jìn)行模塊間調(diào)用和集成，對(duì)被測(cè)系統(tǒng)的集成性和數(shù)據(jù)完整性進(jìn)行測(cè)試，其重點(diǎn)關(guān)注模塊間的接口和集成后的功能，常見的有針對(duì)API調(diào)用的接口測(cè)試和利用Selenium[7]和Appium[8]等測(cè)試工具來實(shí)現(xiàn)的UI自動(dòng)化測(cè)試等。當(dāng)通過合入前檢查后，本地修改代碼才正式合入主干。

1.3 CI 流水線階段

市面上有很多的CI 工具，無論是新興輕量的工具Drone，還是老牌的Jenkins工具都原生或通過插件方式支持了配置文件管理流水線[9]這一特性。這樣一方面不再需要一個(gè)Web頁面專門用于流水線管理，減少了維護(hù)成本，另一方面，將流水線配置集成在源碼倉庫中，享受與源碼同步升級(jí)的方式，使得CI 流程也能使用Git 的版本管理進(jìn)行規(guī)范與審計(jì)溯源，如下是關(guān)鍵階段。

1） 提交構(gòu)建

持續(xù)集成服務(wù)器發(fā)現(xiàn)主干代碼變更后，立即開始執(zhí)行提交構(gòu)建，運(yùn)行自動(dòng)化質(zhì)量驗(yàn)證。如果這次構(gòu)建失敗，則直接阻塞結(jié)束本次構(gòu)建，研發(fā)團(tuán)隊(duì)負(fù)責(zé)人立即著手修復(fù)，為了盡快獲得軟件質(zhì)量反饋，提交構(gòu)建的執(zhí)行時(shí)間不應(yīng)超過團(tuán)隊(duì)規(guī)定時(shí)間，比如15分鐘，所以這個(gè)階段自動(dòng)化驗(yàn)證的是運(yùn)行速度較快且質(zhì)量高的測(cè)試用例，主要包括：增量代碼和相關(guān)依賴代碼的單元測(cè)試用例、安全/漏洞掃描、BVT核心準(zhǔn)入測(cè)試等，其中安全/漏洞掃描工具主要有Burp Suite、Nessus、AWVS等[10]。

2） 次級(jí)構(gòu)建

這個(gè)步驟在流水線里是可選步驟，當(dāng)自動(dòng)化測(cè)試用例的規(guī)模增加到一定程度，無法在團(tuán)隊(duì)規(guī)定時(shí)間內(nèi)完成提交構(gòu)建的所有質(zhì)量驗(yàn)證時(shí)，可以在提交構(gòu)建通過后立刻啟用次級(jí)構(gòu)建。通常把運(yùn)行時(shí)間長(zhǎng)且不經(jīng)常失敗的測(cè)試用例放到次級(jí)構(gòu)建，在執(zhí)行次級(jí)構(gòu)建時(shí)并不阻塞其他工作任務(wù)開展。次級(jí)構(gòu)建會(huì)執(zhí)行全量的單元測(cè)試和集成測(cè)試，如果次級(jí)構(gòu)建驗(yàn)證失敗，也要求立即通知研發(fā)團(tuán)隊(duì)負(fù)責(zé)人進(jìn)行修復(fù)，并通知其他開發(fā)成員在問題修復(fù)前，不能再次提交代碼。放入次級(jí)構(gòu)建的自動(dòng)化測(cè)試用例主要包括執(zhí)行時(shí)間長(zhǎng)耗費(fèi)資源多的或者優(yōu)先級(jí)低出錯(cuò)可能性低的用例。

3） 編譯打包

通過提交構(gòu)建和次級(jí)構(gòu)建的基礎(chǔ)質(zhì)量驗(yàn)證后，當(dāng)前主干的代碼就是一個(gè)可以直接部署的版本，將這個(gè)版本的所有文件進(jìn)行編譯打包存檔到生產(chǎn)服務(wù)器，做好發(fā)布準(zhǔn)備。

2 持續(xù)集成流程的關(guān)鍵點(diǎn)

2.1 主干開發(fā)，頻繁提交代碼

研發(fā)團(tuán)隊(duì)內(nèi)的開發(fā)人員從主干上拉出個(gè)人分支，完成開發(fā)任務(wù)和通過單元測(cè)試后，以每天至少一次的頻率將其新增代碼合并到主干中。主干開發(fā)可以大大加快產(chǎn)品迭代的效率，但是也會(huì)讓新完成的功能特性無法得到全面的手工測(cè)試和驗(yàn)證，所以要實(shí)現(xiàn)主干開發(fā)、頻繁提交，必須實(shí)現(xiàn)如下策略：

1） 研發(fā)團(tuán)隊(duì)采用小批量開發(fā)模式，把項(xiàng)目拆分成多個(gè)小項(xiàng)目后，能夠較短時(shí)間內(nèi)實(shí)現(xiàn)小項(xiàng)目的需求。

2） 團(tuán)隊(duì)積累全面且有效的自動(dòng)化測(cè)試用例，包括全量的單元測(cè)試和集成測(cè)試，擁有極高的測(cè)試覆蓋率、準(zhǔn)確率和有效率，才能保障主干代碼質(zhì)量的穩(wěn)定，持續(xù)集成過程不需介入人工驗(yàn)證也可以讓團(tuán)隊(duì)對(duì)代碼的質(zhì)量比較有信心。

3） 提交代碼到主干前，開發(fā)人員進(jìn)行代碼走查和審核能提高新增代碼的質(zhì)量，有助于提升新增代碼通過各種自動(dòng)化驗(yàn)證的概率，確保代碼能順暢地合并到主干中。

4） 構(gòu)建和測(cè)試過程應(yīng)該在15分鐘內(nèi)完成，過長(zhǎng)的等待時(shí)間會(huì)提高將代碼合并到主干的成本，提高了持續(xù)集成效率才能提升團(tuán)隊(duì)的研發(fā)效率。

5） 高度自動(dòng)化且精準(zhǔn)的線上及灰度監(jiān)控能力能為采用持續(xù)集成的項(xiàng)目進(jìn)行質(zhì)量保底。通過持續(xù)集成驗(yàn)證發(fā)布出去版本一旦有嚴(yán)重缺陷，強(qiáng)大的線上灰度監(jiān)控能力能讓團(tuán)隊(duì)在短時(shí)間內(nèi)發(fā)現(xiàn)異常，停止新版本發(fā)布，并緊急修復(fù)缺陷后快速進(jìn)行驗(yàn)證再次發(fā)布。

2.2 團(tuán)隊(duì)分支也需要持續(xù)集成

研發(fā)團(tuán)隊(duì)有時(shí)也會(huì)采用分支開發(fā)集成發(fā)布的研發(fā)模式，比如重大底層重構(gòu)類技術(shù)需求或者是數(shù)據(jù)版本升級(jí)，研發(fā)團(tuán)隊(duì)會(huì)從主干上拉出團(tuán)隊(duì)分支，多人在該分支上頻繁提交和構(gòu)建代碼，開發(fā)人員在本地完成開發(fā)任務(wù)后，把代碼合入團(tuán)隊(duì)分支。這種團(tuán)隊(duì)分支通常會(huì)與主干并行存在較長(zhǎng)一段時(shí)間，在分支驗(yàn)證通過后直接在分支上進(jìn)行灰度發(fā)布，灰度發(fā)布的數(shù)據(jù)穩(wěn)定后把團(tuán)隊(duì)分支代碼合入主干，再跟隨主干進(jìn)行全量發(fā)布。針對(duì)這種團(tuán)隊(duì)分支，團(tuán)隊(duì)將其設(shè)置為保護(hù)分支，僅允許在所有測(cè)試通過后才合并拉取請(qǐng)求，并且跟主干一樣所有的代碼提交自動(dòng)觸發(fā)CI流水線，強(qiáng)制執(zhí)行持續(xù)集成以保證團(tuán)隊(duì)分支代碼質(zhì)量的穩(wěn)定。

2.3 單元測(cè)試由開發(fā)人員負(fù)責(zé)測(cè)試人員輔助，集成測(cè)試由測(cè)試人員負(fù)責(zé)

單元測(cè)試的對(duì)象是模塊內(nèi)部的程序，為了消除局部模塊的功能和邏輯上的缺陷，在持續(xù)集成中采用白盒自動(dòng)化測(cè)試方法。由熟悉自己實(shí)現(xiàn)的功能代碼的開發(fā)人員負(fù)責(zé)單元測(cè)試是事半功倍的，鑒于開發(fā)人員對(duì)測(cè)試知識(shí)的不足，測(cè)試人員負(fù)責(zé)單元測(cè)試代碼的走查。對(duì)于重點(diǎn)功能的單元測(cè)試，由開發(fā)和測(cè)試采用結(jié)對(duì)編程的方式完成能達(dá)到質(zhì)量和效率的平衡。集成測(cè)試的對(duì)象是模塊間的集成和調(diào)用關(guān)系，采用白盒測(cè)試和黑盒UI自動(dòng)化測(cè)試方法。這類測(cè)試需要對(duì)整個(gè)程序功能和實(shí)現(xiàn)方式比較了解，專業(yè)的測(cè)試人員負(fù)責(zé)比較合理。在項(xiàng)目實(shí)施過程中，采用自頂向下方式和自底向上方法結(jié)合的集成測(cè)試用例編寫能達(dá)到發(fā)現(xiàn)缺陷時(shí)機(jī)和編寫成本的平衡。

2.4 測(cè)試用例分級(jí)處理

在實(shí)際項(xiàng)目發(fā)布時(shí)，存在小范圍的灰度發(fā)布和針對(duì)全部用戶的全量發(fā)布兩種形式。一般情況下，集成測(cè)試用例的自動(dòng)化執(zhí)行是持續(xù)集成中最耗時(shí)的步驟，采用用例分級(jí)方式能進(jìn)一步提升發(fā)布效率。對(duì)于集成測(cè)試用例，標(biāo)注1級(jí)為程序最重要的用例，灰度發(fā)布和全量發(fā)布都需要執(zhí)行；標(biāo)注2級(jí)為次重要用例，灰度發(fā)布不需要執(zhí)行僅在全量發(fā)布時(shí)執(zhí)行；標(biāo)注3級(jí)為不穩(wěn)定用例，需要優(yōu)化代碼提高穩(wěn)定性。

3 結(jié)束語

綜上，持續(xù)集成將軟件交付過程中開發(fā)、測(cè)試和運(yùn)維的環(huán)節(jié)打通，通過自動(dòng)化測(cè)試與監(jiān)控來提高研發(fā)效率和質(zhì)量，其主要特點(diǎn)如下文。

3.1 構(gòu)建自動(dòng)化

持續(xù)集成提供讓軟件自動(dòng)編譯和鏈接到可執(zhí)行文件的能力，在運(yùn)行集成構(gòu)建時(shí)，會(huì)識(shí)別出代碼沖突、編譯錯(cuò)誤等基本問題，這類低級(jí)別高影響的問題需要在代碼合并后快速被發(fā)現(xiàn)和處理，所以需要高頻的自動(dòng)化構(gòu)建。

3.2 測(cè)試自動(dòng)化

在迭代過程中，研發(fā)團(tuán)隊(duì)需要重新測(cè)試之前版本中的可行功能，保證產(chǎn)品功能的穩(wěn)定性。所以，在開發(fā)代碼的同時(shí)，團(tuán)隊(duì)也需要編寫對(duì)應(yīng)的單元測(cè)試和集成測(cè)試用例，在構(gòu)建產(chǎn)品增量代碼時(shí)自動(dòng)觸發(fā)這些不斷累積的測(cè)試用例的執(zhí)行，能更早發(fā)現(xiàn)功能性和邏輯性缺陷，減少項(xiàng)目提交測(cè)試后的代碼缺陷。

3.3 豐富的插件應(yīng)用

持續(xù)集成系統(tǒng)能應(yīng)用豐富的插件來提高系統(tǒng)的穩(wěn)定性和安全性，比如代碼靜態(tài)掃描和安全掃描等都可以嵌入到持續(xù)集成中，一方面保證了功能的質(zhì)量，另一方面也促使團(tuán)隊(duì)優(yōu)化系統(tǒng)架構(gòu)、減少冗余代碼、提升系統(tǒng)安全性，讓交付的產(chǎn)品更加完美。