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