開發(fā)人員提交代碼后,觸發(fā)Jenkins完成代碼編譯檢查和單元測(cè)試,Jenkins返回代碼檢查結(jié)果給Gerrit,人工Review后merge代碼,觸發(fā)Jenkins完成該項(xiàng)目的打包。Jenkins定時(shí)完成各個(gè)工程的集成打包,然后通過調(diào)用CMP的API觸發(fā)自動(dòng)化部署,部署完成后進(jìn)行場(chǎng)景化的集成測(cè)試,測(cè)試完成后卸除資源。
持續(xù)集成(Jenkins)
起初我們使用GitLab?Runner實(shí)現(xiàn)CI,在每個(gè)代碼工程中添加“.gitlab-ci.yaml”文件,不同項(xiàng)目各自創(chuàng)建和維護(hù)自己的.gitlab-ci.yaml腳本,這樣的實(shí)現(xiàn)可以解決各自工程的編譯測(cè)試和打包問題,在代碼工程數(shù)量較少時(shí),我們也使用了較長(zhǎng)一段時(shí)間。
現(xiàn)在我們的代碼工程數(shù)量已超過20個(gè),每個(gè)代碼工程都設(shè)置了訪問權(quán)限,如果需要專人維護(hù)CI腳本的話,那他需要能夠訪問所有代碼工程,顯然這樣是不合理的,而且把集成打包腳本放在哪個(gè)工程里都不合適。
考慮到Jenkins有強(qiáng)大的CI能力:通過安裝插件就能快速與Gerrit、GitLab集成,能夠參數(shù)化執(zhí)行各種類型的腳本。所以,我們使用Jenkins代替gitlab-runner完成CI,通過Jenkins可以統(tǒng)一管理各個(gè)工程的編譯、測(cè)試、打包,而且比較方便構(gòu)建流水線完成較多工程集成打包及測(cè)試。
持續(xù)部署(Ansible)
我們的產(chǎn)品由20多個(gè)服務(wù)組成,可部署在一個(gè)或多個(gè)虛擬機(jī)上,使用Shell腳本或Python腳本已經(jīng)很難完成這么多服務(wù)程序的自動(dòng)化安裝部署配置。
恰巧團(tuán)隊(duì)有使用Ansible做復(fù)雜系統(tǒng)部署的經(jīng)驗(yàn),Ansible的學(xué)習(xí)成本也較低,所以我們選擇使用Ansible?Playbook?實(shí)現(xiàn)這20多個(gè)服務(wù)程序的統(tǒng)一編排部署和配置,并且可以同時(shí)支持單節(jié)點(diǎn)和HA多節(jié)點(diǎn)自動(dòng)化部署。
我們?cè)O(shè)計(jì)Ansible?Playbook時(shí),將每個(gè)服務(wù)都獨(dú)立成一個(gè)角色,這樣保證了各個(gè)服務(wù)部署的獨(dú)立性,這種分布式部署架構(gòu)為將來容器化部署和微服務(wù)化奠定了基礎(chǔ)。
Ansible自動(dòng)化標(biāo)準(zhǔn)化部署不僅大大縮短了部署時(shí)間,也極大地降低了部署出錯(cuò)的概率。原先,按照HA架構(gòu)部署一套產(chǎn)品需要1天時(shí)間來完成各個(gè)服務(wù)的部署和配置,通過使用Ansible?playbook,我們只需要45分鐘,而且中間過程完全可以放手去做別的事情。
集成測(cè)試(Robot Framework)
目前,我們?cè)贘enkins中使用Robot Framework框架做集成測(cè)試。Robot Framework(以下簡(jiǎn)稱RF)是一個(gè)基于Python的、可擴(kuò)展的、關(guān)鍵字驅(qū)動(dòng)的測(cè)試自動(dòng)化框架。
選用RF的原因:
·一致性:目前公司的UI自動(dòng)化測(cè)試使用的就是RF框架,RF框架也完全有能力做集成測(cè)試,因此使用RF框架做集成測(cè)試,可以降低學(xué)習(xí)成本,提高可維護(hù)性。
·復(fù)用性:在安裝了Robot-Framework-JMeter-Library后,RF可以運(yùn)行JMeter腳本,并且將JMeter運(yùn)行結(jié)果轉(zhuǎn)為Html格式。公司目前性能測(cè)試用的就是JMeter,對(duì)于相同場(chǎng)景,只要小幅修改JMeter腳本即可將其復(fù)用到集成測(cè)試上面。
選用RF也存在一些問題:
·如果不復(fù)用JMeter腳本,編寫的API測(cè)試用例的成本非常高。
RF對(duì)于變量類型的規(guī)定堪稱僵硬(當(dāng)然,這么規(guī)定帶來的好處是方便類型檢測(cè)),RF中對(duì)于字典類型的創(chuàng)建非常麻煩,對(duì)于我們公司API請(qǐng)求中攜帶大量參數(shù)的情況,只能創(chuàng)建關(guān)鍵字來解決,不管是采取RF自帶創(chuàng)建字典的方法,還是創(chuàng)建關(guān)鍵字的方法,都比較浪費(fèi)時(shí)間(因?yàn)殡y以復(fù)用)。
·RF可以輕松擴(kuò)展關(guān)鍵字,也因此可能帶來亂擴(kuò)展關(guān)鍵字的問題,導(dǎo)致測(cè)試用例可讀性和可維護(hù)性差的問題。
在RF中,關(guān)鍵字其實(shí)就是Python/Java的類方法,因此擴(kuò)展起來非常容易,但是關(guān)鍵字一旦多起來,一個(gè)同事寫的測(cè)試用例,其他人(甚至他自己過了一段時(shí)間)維護(hù)就非常麻煩(需要回去看關(guān)鍵字是如何規(guī)定的)。因此需要嚴(yán)格規(guī)定關(guān)鍵字的創(chuàng)建規(guī)范是一件值得深入討論的事情。