《flow.ci 持續(xù)集成技術(shù)實踐》要點：
本文介紹了flow.ci 持續(xù)集成技術(shù)實踐，希望對您有用。如果有疑問，可以聯(lián)系我們。

互聯(lián)網(wǎng)時代,人人都在追求產(chǎn)品的快速響應(yīng)、快速迭代和快速驗證.不論是創(chuàng)業(yè)團隊還是大中型企業(yè),都在探索屬于自己的敏捷開發(fā)、持續(xù)交付之道.fir.im 團隊也在全面實施敏捷,并推出新持續(xù)集成服務(wù) —flow.ci(http://u6.gg/adck),以幫助企業(yè)將開發(fā)測試流程自動化,更快速地交付產(chǎn)品.

? ? ? ?這次分享由 fir.im CTO 郭揚,從敏捷方法論的角度來講解 fir.im 團隊的 CI 技術(shù)實踐,希望能帶給你一些思考.

?

郭揚,fir.im CTO,曾就職于奔馳戴姆勒創(chuàng)新實驗室,Thoughtworks,索尼移動通信,網(wǎng)易等公司,擔(dān)任 DevLead,負責(zé)組建技術(shù)團隊,管理項目進度與項目風(fēng)險,軟件及 DevOps 的架構(gòu)設(shè)計、高并發(fā)條件下的性能調(diào)優(yōu)、敏捷教練等工作.

持續(xù)集成做什么

持續(xù)集成的概念出現(xiàn)在 2001 年,它其實是一個 XP 極限編程的工程實踐.那么持續(xù)的是什么,集成是什么呢,非常簡單就是“一直不停地集成代碼”.

持續(xù)集成是把代碼頻繁的合并到主干,通過自動構(gòu)建的方式驗證軟件的質(zhì)量,讓團隊快速的響應(yīng)質(zhì)量,快速的修復(fù)問題,快速的給客戶解決問題,快速地交付更好的軟件質(zhì)量.

我們?yōu)槭裁匆龀掷m(xù)集成

開發(fā)人員對下面的軟件開發(fā)場景很熟悉,比如：

• 場景一：開發(fā)了新功能,老功能產(chǎn)生新的 bug；
• 場景二：修好一個 bug,又產(chǎn)生其他 bug,甚至出現(xiàn)連環(huán) bug；
• 場景三：出現(xiàn)的 bug 比較多,修改代碼要很謹慎,不熟悉的模塊一般不敢動,怕引起問題；

持續(xù)集成是如何緩解這個問題的,Martin Fowler 大師曾經(jīng)說過：

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler

如上面所說,持續(xù)集成不能消除 bug ,但能更容易地發(fā)現(xiàn) bug且更快速地修復(fù),提升產(chǎn)品質(zhì)量.那么,持續(xù)集成能給我們帶來哪些價值呢?

從這張圖上可以看到,持續(xù)集成形成一個完美的閉環(huán).通過持續(xù)的集成進行不斷地檢查、調(diào)整,同時項目的透明性也得到了最大的體現(xiàn).

fir.im 如何進行持續(xù)集成實踐

這是一個常見的持續(xù)集成流水線：

在日常的開發(fā)過程中,程序員在本地提交代碼,持續(xù)集成流水線要求先做一次本地集成,在本地進行驗證后提交到源代碼管理倉庫中,之后源代碼工具會發(fā)出 webhook 觸發(fā)到持續(xù)集成系統(tǒng)中.當(dāng)構(gòu)建/測試完成后,會及時通過釘釘或郵件通知團隊(測試/研發(fā)/boss/產(chǎn)品經(jīng)理)集成狀態(tài),產(chǎn)品經(jīng)理或項目經(jīng)理收到通知后會在測試環(huán)境做驗收測試,這是一個比較完美的反饋環(huán).

假如測試通過驗收完畢后,持續(xù)集成系統(tǒng)會自動觸發(fā)部署到類生產(chǎn)環(huán)節(jié)或測試環(huán)境,或由專人手動部署到生產(chǎn)環(huán)境.

為什么要做本地集成

首先,代碼在遠程進行管理,每個人都會提交代碼,遠程的代碼倉庫會產(chǎn)生變化,所以在本地集成的時候要求進行代碼合并,以免出現(xiàn)分支沖突和代碼沖突.其次,不要依賴于持續(xù)集成系統(tǒng)給你結(jié)果,可能需要 30 分鐘的時間,不要讓開發(fā)人員等待,一定要先做本地集成.

如何做版本提交

再說一個提交的問題,我們盡量保證每一次提交都是一個完整的提交,也就是原子提交.

當(dāng)代碼變動你想創(chuàng)建提交時,這個提交應(yīng)該盡可能的小量,并且包含一個不可分割的特性(feature)、修復(fù)(fix)或優(yōu)化(improved).

拿每個產(chǎn)品開發(fā)都會遇到的 login 功能開發(fā)舉例,當(dāng)填完的用戶名和密碼傳到數(shù)據(jù)庫,做完驗證后給用戶返回一個結(jié)果.那什么是一個原子提交?比如,提交驗證一個用戶名,這是一個完整的 feature ；驗證密碼是否符合格式(6位/8位),這也是一個完整的 feature ；當(dāng)我驗證完用戶名和密碼后再傳到數(shù)據(jù)庫之后,查詢正確與否,這也是一個完整的 feature ；保證每次提交是一個完整的 feature 或修復(fù)了一個 bug,不要代碼寫成半截.

持續(xù)集成系統(tǒng)

這里講的是狹義的持續(xù)集成系統(tǒng),通常的 CI 系統(tǒng)收到提交之后會觸發(fā)構(gòu)建,構(gòu)建會有信息返回比如 commit id 、commit 信息、代碼變更等,收到代碼提交后會觸發(fā)自動構(gòu)建,接著安裝依賴進行編譯,并觸發(fā)質(zhì)量保證流程,也就是說自動化測試集.

自動化測試集包括代碼靜態(tài)檢查－單元測試－集成測試－驗收測試－性能測試,也會有壓力測試、回歸測試、monkey test等等一系列的測試.

接下來,我們具體講一下 fir.im 團隊如何進行持續(xù)集成實踐的.

fir.im 的敏捷環(huán)境

fir.im 是一個內(nèi)測分發(fā)平臺,我們也做了一個持續(xù)集成 CI 產(chǎn)品－flow.ci.先來看一下我們正在使用的敏捷環(huán)境：

• Trello 看板;
• 三個環(huán)境(類生產(chǎn)環(huán)境,測試環(huán)境,生產(chǎn)環(huán)境);
• CI 工具(Jenkins/flow.ci)

說一下 Git 分支管理

我們在應(yīng)用 3 個分支 —— master／develop／feature 分支,對 feature 命名會有一些要求,持續(xù)集成系統(tǒng)一定會反饋到 trello 的 kanban 里,所以對于 feature 分支我們也有這樣的命名 feature/fci-{card number} 以方便區(qū)分.

多分支如何做頻繁地持續(xù)集成?

master 分支,即線上分支.線上通常會有一些 hotfix, 任何產(chǎn)品都不可能避免線上的 bug ,這些 bug 需要在 master 分支進行修復(fù),修復(fù)完成后持續(xù)集成系統(tǒng)會告知已上線,收到團隊反饋,這些代碼會要求更新在 develop 分支上,之后所有團隊也會收到相關(guān)通知,那么 feature 分支會有變化嗎?答案是肯定的,因為頻繁的集成可以防止代碼偏離.這就是我們多分支構(gòu)建的策略.??

還有一個策略——不同的分支不同的構(gòu)建,持續(xù)集成系統(tǒng)跑完整個流程會很長,所以在 feature 分支頻繁度會比在本地構(gòu)建要高一些,但是也沒有那么高.為了保證持續(xù)集成系統(tǒng)能快速地收到反饋,需要在 feature 分支上做一些定制的 workflow ,所以我們做了代碼靜態(tài)分析和單元測試.

當(dāng) feature 分支的 card 做完之后(scrum 中 done 的含義是指測試驗收完畢),集成到 develop 分支,develop 分支會自動部署到測試環(huán)境,會跑一個整個自動化測試集,為什么是這樣的構(gòu)建策略呢?

本地集成的頻率非常高,遠程構(gòu)建對應(yīng)的是 feature 分支,會相對低一下.QA 環(huán)境對應(yīng)的是 develop 分支的構(gòu)建粒度.這樣的構(gòu)建每天都會產(chǎn)生,所以做完之后不要積壓,一定要保持上線節(jié)奏.?

kanban + scrum 結(jié)合的方式構(gòu)成我們每日構(gòu)建,這是一個整體的構(gòu)建策略和上線頻率.

fir.im 的持續(xù)集成系統(tǒng)演變過程

羅馬不是一天建成的,持續(xù)集成不是一開始就是完美的,每個開發(fā)者心中都有一個比較理想的自動化工作流——持續(xù)部署,大概會經(jīng)歷這幾個演變階段：

• 最初階段：提交代碼－自動部署；
• 一般進階：提交代碼－代碼靜態(tài)分析－自動部署,最簡單先再加入代碼靜態(tài)分析；
• 高級進階：提交代碼－代碼靜態(tài)分析－自動化測試集－自動部署；?

這是我們在用的自動化測試集,下面分別說下靜態(tài)檢查分析、單元測試、驗收測試、性能測試的具體用途.

Step 1. 靜態(tài)代碼分析

每個公司都會有自己的代碼規(guī)范,代碼靜態(tài)分析工具能夠保證代碼質(zhì)量,現(xiàn)成的工具有 java 的 FindBugs,ruby 的 rubocop 等.利用代碼檢查工具可以幫助團隊發(fā)現(xiàn)可重構(gòu)的地方,輸出產(chǎn)出 – HTML 報告,也會發(fā)現(xiàn)潛在 bug；有的代碼檢查工具還會檢查出一些安全漏洞.

這三點是代碼靜態(tài)分析最重要的作用.這里也分享一個 GitHub 地址(https://github.com/mre/awesome-static-analysis),列出一些主流語言的代碼分析工具,可以參考一下.

Step 2. “單元測試”

這里的 “單元測試”也加上了集成測試,畢竟創(chuàng)業(yè)公司要求資源最大化.程序員一定要寫單元測試,要克服開發(fā)的慣性思維,不要甩鍋.下面有一些注意的點和大家分享：

• 測試異常——不僅僅測試正確情況,也要主動測試異常；
• 減少耦合——保證獨立的可測試性；
• 功能分離——單元測試流太長,超過 20 分鐘的話要詳細想一下如何將功能單獨拆開,效率更高；
• 測試＝需求——從測試代碼看到每個 class 是干什么的,同時出現(xiàn) bug 時,第一時間是看測試,想想如何從測試中復(fù)現(xiàn)；

Step 3. 驗收測試

驗收測試是端對端的測試,從收到用戶名密碼到返回結(jié)果,是不是我們所期望的一個值,這是驗收 Acceptance Test,其實是驗收了整個功能.代碼靜態(tài)檢查和單元測試,保證了我們?nèi)绾卧趺慈懘a,驗收測試保證了寫正確代碼,符合開發(fā)需求.

flow.ci 做驗收測試比較多,用的是比較流行的框架 Cucumber + Selenium WebDriver,目前支持 3 種數(shù)據(jù)庫,5 種 git 倉庫,7 種 開發(fā)語言跑在 docker 容器云上,支持 iOS 構(gòu)建跑在 mac 機器上,要保證這些排列組合正常運行,這是 flow.ci 做驗收測試最核心的價值.

其實,持續(xù)集成是一個工作流,當(dāng) push 代碼的時候才會 run 起來,但是 flow.ci 本身系統(tǒng)也有外部依賴的特殊性,會依賴一些第三方的 sevice(比如 GitHub/GitLab 等),驗收測試應(yīng)該一直保持不斷地運行,也可以叫持續(xù)測試吧.因為我們永遠不能保證第三方的 api 會不會改變.

Step 4. 性能測試

我們的性能測試做的比較簡單,主要測試 api.因為 fir.im 做 app 的內(nèi)測分發(fā),我們需要性能測試保證 app 上傳下載的正常穩(wěn)定.性能測試是單用戶的,壓力測試是多用戶的,這是兩者之間的區(qū)別.

性能測試會有一些不確定性,有很多系統(tǒng)會產(chǎn)生緩存.flow.ci 的性能測試跑在 docker 上,是一個干凈獨立的環(huán)境,需要讓系統(tǒng)預(yù)熱運行一下.Locust/JMeter/LoadRunner是目前比較流行的性能測試工具. flow.ci目前用的是 locust,可以參考一下.

持續(xù)集成的可視化、數(shù)據(jù)分析

我們認為一個好的持續(xù)集成系統(tǒng)也要做到項目進度的透明化,最傳統(tǒng)的方式是發(fā)送相關(guān)的郵件,但實質(zhì)上有幾個人去看呢?為此我們采購了一個大的屏幕來解決這個問題,用來時刻提醒團隊的某個構(gòu)建結(jié)果.當(dāng)然也可以用閃爍燈或音頻的方式.

說到數(shù)據(jù)統(tǒng)計分析,整個 CI流程跑下來產(chǎn)生的很多數(shù)據(jù)也非常有挖掘的價值.比如,對于代碼靜態(tài)分析有多少 Offence、Risk、Bug,對于單元測試有失敗率、測試覆蓋率；對于驗收測試或性能測試有多少的失敗率,這些數(shù)據(jù)都有可能成為衡量一個程序員的標(biāo)準.

結(jié)語

CI 就像蓋樓房的腳手架一樣,沒有腳手架就沒辦法蓋出一個足夠高的樓,沒有 CI 就無法交付質(zhì)量足夠好的軟件!

文章來自微信公眾號：逼格運維說

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4103.html