Docker怎麼用之研發篇｜解決QA任務塞車 優化測試效率

今年2月，有5年網站開發經驗的KKBOX資深工程師巫秉澔，才剛到職就接到第一個任務。他要進入KKBOX音樂串流服務旗下售票平臺KKTIX的團隊，負責打造一套持續整合CI系統，來解決KKTIX研發團隊QA任務塞車的問題。

就像常見的開發流程，研發團隊成員完成一項功能後，就會需要建立一個QA環境來驗證所開發的功能符合設計要求。KKTIX研發團隊約有10人，負責幾個專案，每個專案同時都會有多個功能同時開發，每個功能也會產生很多分支版本的程式碼，因此，每天經常會有好幾個完成開發的分支版本程式必需要進行QA。

因為KKTIX研發團隊為了統一測試環境，所有人使用同一個設定檔，也會啟動同一個資料庫，所以，所有人都將QA任務丟到同一個QA伺服器上執行，經常同時有4個任務要執行。為了建立一次QA的環境可能得花上一個小時，若同時有好幾個QA任務要執行，開發人員就得等上半天才能得知結果，有時遇到頻繁地程式小修改，也得發布多次的QA任務，很容易就會導致QA任務大塞車。

另一個更大的問題是，巫秉澔解釋，有時前一次QA任務結束後，沒有辦法徹底清除資料庫內的測試資料，還會影響到下一次的QA任務，導致測試結果出錯。尤其像KKTIX使用的Elasticsearch 搜尋引擎，前一次QA任務的索引資料有時很難清空，下次測試就會出現網頁呈現結果和預期不一樣的現象。

為了能夠讓QA任務平行化，巫秉澔使用了開源CI系統Jenkins搭配輕量級虛擬化技術Docker來建立CI系統，並用Container虛擬化來解決QA環境隔離不全的問題。

KKTIX的程式碼使用了Github版本控管服務來管理，巫秉澔起初是設計當Github每次收到Pull Request要合併分支程式碼的需求時，就會自動通知Jenkins伺服器來執行QA。

巫秉澔沒有使用Jenkins內建的Docker外掛，而是自己用Build Script來Build一個Docker Image檔案，並在Docker中執行這個Docker Image來建立QA環境，同時執行QA程式。PM確認過測試結果後，可以在Jenkins網頁上按下一個Merge按鈕，通知Github將分支程式合併到專案程式碼中。

不過，後來，因為有些程式分支版本只是修改文句用詞，或是程式碼重構，並不影響程式邏輯，所以，巫秉澔取消每次Pull Request就Build的設計，增加手動Build的選項。

將所有基礎服務打包成Base Image

巫秉澔沒有將不同的Stack分成不同的Image（例如Nginx一層，MySQL一層），而是將基本環境需要的軟體，包括了Ubuntu、Nginx、Ruby/Rails、PostgreSQL資料庫、Redis資料庫、ElasticSearch搜尋引擎等，都打包到同一個Docker Image中作為Base Image。

然後再以此Base Image為基礎，來產生QA所需的Docker Image，開發人員所用的Go語言執行環境，以及Port管理工具等QA需要的工具。另外巫秉澔也用Base Image來建立Test任務需要的Test環境Image。Test環境中則多了Firefox瀏覽器和Selenium網頁自動化測試工具。巫秉澔表示，因為兩者用途不同，但是所需的基礎環境一樣，就可以一次做兩件事。原本巫秉澔要在測試環境中安裝Chrome瀏覽器，不過會不穩定因而不用。

最後再利用定期執行的腳本程式每天凌晨自動依據Base Image Dockerfile來建立新的Base Image，這個新版Base Image就是最新版本的執行環境。等到第二天，研發團隊成員建立需要的QA環境或Test環境時，就是套用了最新版本的執行環境，也就可以統一每一個人所用的執行環境。

利用ONBUILD指令來取得最新版的程式碼

巫秉澔另一個秘訣是利用Dockerfile的ONBUILD指令，這個指令可以在Base Image的Dockerfile中，設定QA Image或Test Image建立時要執行的動作。巫秉澔會在ONBUILD中呼叫外部的腳本程式，來執行將研發團隊開發的最新版程式碼複製到Image中的動作。

因為在ONBUILD指令中的程式會等待在建立QA Image時才會執行，也就能確保，當第二天開發人員建立QA Image時候，會自動將最新版本的程式碼加入QA Image中。因為是呼叫一個外部腳本程式，因此，開發人員還可以修改這個腳本程式的內容，來進行每一次QA需要的客製化配置調整，例如要這次使用哪些特定埠。

KKTIX以Docker優化持續整合和測試作法

看大圖