iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 27
0

前二天已經介紹了 Ohara 測試程式的部份了,今天主要會介紹有關於 Ohara 的 QA,QA 存在的目的就是要讓軟體的品質保證更穩定,因為 Ohara 是 Open Source 所以開發的人多,所以很難去控管每個人寫出來或修改的程式碼是否會影響到其它地方而產生一些沒有預期到的 Bug 或是每一個人寫的程式碼 code style 習慣都會不太一樣,例如有些人習慣程式碼一行要寫非常長,有些人習慣每一行只能有 80 個字之後就換行,這樣不一致就會造成其它閱讀程式碼的人困擾,因此 Ohara 會要求 code style 要一致,這個部份 QA 也會幫忙做檢查。

Ohara 的 QA 是使用 Jenkins,在開發者把程式碼送到 github 上時並且有開 PR (Pull Request) 時,就會觸發 Jenkins 的執行,針對在這次開 PR branch 的程式碼去跑 QA,在 QA 的執行主要會做以下幾件事:

  1. 切換到 PR Branch 的程式碼

  2. 做程式碼版本的檢查,如果是很舊的版本程式碼就有可能會收到 QA 的錯誤訊息。例如目前 Ohara 的版本已經到 0.9.0 如果拿 0.4.0 的程式碼來跑 QA 就沒辦法執行 QA

  3. 在 PR 裡貼上版本號的 label

  4. 需要先將 PR Branch 的程式碼和 master 的程式碼進行 rebase 的動作,這樣才能確保 PR Branch 的程式有更新到最新的狀態,避免因為其它人先合併到 master 裡,而造成跑 QA 的程式碼是較舊的狀態,這樣會導致之後合併到 master 裡才發現程式碼有 bug

  5. 使用 gradle 指令執行 code style 的檢查、license header 的檢查、compiler 程式碼…等等的工作。

  6. 檢查 java docs 和 scala docs 撰寫的格式是否正確

  7. 檢查 Ohara 的文件是否有撰寫正確以及把文件 build 出一個 html 檔,讓開發者能確認文件是否有撰寫錯誤。(ohara 的文件是使用 rst 來撰寫)

  8. 使用 git diff 指令, 找出有哪些程式碼有做修改。然後去執行有修改模組的單元測試程式,會這麼做的原因主要是因為執行 QA 的環境資源有限,如果有很多人送程式碼進來就會造成 QA 系統的負擔過大,在執行測試時很容易發生 timeout 的 exception,而且後面送程式碼進來的人也會等很久,才能跑 QA。 所以就會希望測試能夠在最短的時間內跑完,避免耗用過多的系統資源。因為每一個模組的測試都是獨立的所以測試上的執行不會有問題。

  9. 如果有修改整合測試的程式碼或是在 Ohara 開 PR 裡的最下面 comment 輸入 retry it,也就會執行整合測試的部份。昨天有介紹到整合測試程式撰寫的部份,在 QA 裡就會指定在 ohara-it 模組下 build.gradle 寫的參數設定,連到外部系統做測試,像是連到 Oracle database 做 JDBC Source Connector 的整合測試。以下是在 QA 裡面設定連到外部系統的設定:

EXTRA_PROPERTIES="\ 
  -Pohara.it.k8s=$K8S_URL \ 
  -Pohara.it.k8s.nodename=$K8S_NODES \ 
  -Pohara.it.postgresql.db.url=$POSTGRESQL_URL \ 
  -Pohara.it.postgresql.db.username=$POSTGRESQL_USERNAME \ 
  -Pohara.it.postgresql.db.password=$POSTGRESQL_PASSWORD \ 
  -Pohara.it.oracle.db.url=$ORACLE_URL \ 
  -Pohara.it.oracle.db.username=$ORACLE_USER_NAME \ 
  -Pohara.it.oracle.db.password=$ORACLE_PASSWORD \ 

然後在 QA 執行 gradle 的 script 如下:

gradle clean ohara-it:test ${EXTRA_PROPERTIES} 

以上的寫法就可以讓 QA 在跑整合測試時,連到相對應的外部系統像是Kubernets、postgresql、oralce database....執行整合測試的部份。

以下是開 PR,然後 QA 正在執行的畫面:
https://ithelp.ithome.com.tw/upload/images/20191012/201034568xnLCkqLbt.png

在上圖看到黃點的部份,代表此模組還沒執行完成,當 QA 執行完成的畫面如下:
https://ithelp.ithome.com.tw/upload/images/20191012/20103456MRUBhPSP2m.png

如果測試失敗會看到紅色叉叉,這時侯可以按下 Details 連結去看詳細的 log 內容,有時侯是因為 QA 忙錄造成測試 timeout exception,這時侯想要再重跑一次 QA 可以直接在 PR 的最下面的 comment 輸入 retry 關鍵字,就會全部的把之前跑過的模組重新再跑一次,畫面如下:
https://ithelp.ithome.com.tw/upload/images/20191012/20103456KGeGQGCx0B.png

如果只想跑單一個模組,我們可以輸入 retry 後面放 ohara 的模組名稱 retry ${MODULE_NAME},舉例如下:

retry connector  

輸入以上的字串就只會執行 connector 的測試

今天已經介紹了有關於 Ohara QA 的部份了,明天會介紹 Ohara 關於開 PR (Pull Request) 流程的部份。


上一篇
Day 26 關於 Ohara 的測試程式 (二)
下一篇
Day 28 關於 Ohara 開 PR (Pull Request) 的流程
系列文
用30天介紹 open source 專案 Ohara 30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言