開發(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ī)范是一件值得深入討論的事情。

songjy