Continuous Delivery
http://www.taaze.tw/sing.html?pid=11100723738
本書獲得《Dr. Dobb’s Journal》肯定，榮獲第21屆Jolt獎。
打造優良的軟體開發團隊，除了要大家有敏捷的觀念外，基礎建設也是非常重要的。前一陣子唸完了 Continuous Delivery 之後， 便開始計畫要把不足的部份補完（如果不知道 Continuous Delivery 有什麼好處，可以先上網查查，或著看看書 XD），在幾位同學的努力之下，花了一個多月把缺的部份補上，包含架設CI Server、夠好用的build script、Robot Framework for QML、Unit Test integration。
- CI
- 我們選定的 CI 是用 TeamCity，其實 Jenkins 也不錯，但是比較起來商業化的軟體在易用性及介面上，還是略勝一籌，加上之前也都是在用 TeamCity，我覺得用 TeamCity 可以更快上手。
- Unit Test
- Unit Test 使用 Google Test，為何捨棄原本的 Boost Testing Framework?一個原因是它在 mock/stub 這一部份還不及 Google Test 完整，因此我們選用了 Google Test。
- UAT (User-Accaptance-Testing)
- UAT 的部份則是使用 Robot Framework，沒有特別原因，只是因為有其它同事正在用，就一起用吧 XD
- Qt/QML Testing Framework，
- GUI Application 的測試，有一點很重要的是要以 HANDLE、object ID 來操作，而避免使用”圖形”的方式來操作，因為你的 GUI 有非常大的機率會調整，只要一改，你的 test case 就要全部重來了。但是 QML Application 裡頭是沒有所謂的 window handle 的，跟傳統的 Windows Application 不大一樣，而目前市面上只有 Squish 有辦法去對 QML Application 做到使用 object ID 來操作。（Ubuntu 的 testing tool 似乎也有，但沒有深入研究）
- 但我們並沒有使用 Squish，而是讓我們的程式原本就具備這樣的”可測性”，也就是說我們自己做了一個 python library，可以讓開發人員透過這個 python library 來操作我們的 QML Application。而 Robot Framework 就是透過這個 python library 來完成 keyword-driven testing。不知道什麼是 keyword-driven testing 的話，可以參考 http://kb.froglogic.com/display/KB/Article+-+Keyword-driven+testing+with+Squish+and+Robot+Framework
就這樣，透過上面四個元件的合作，我們完成了 Continuous Delivery 的目標。這個系統會自動完成下面的工作：
- 有團隊成員 commit code 之後，開始進行 build，然後執行全部的 unit test
- 通過 unit test 之後，自動打包成準備釋出的 installer.exe
- 接下來自動依序發佈到不同平台的 VM 上去進行測試。
- 系統呼叫 sikuli，自動在各個 VM 裡頭執行 installer.exe，並完成軟體的安裝。
- 安裝完畢，會呼叫 Robot Framework 開始進行 UAT (User-Acceptance-Testing)。
- 完畢，產生報告。
有了 Continuous Delivery，現在 RD/UX/PO 都隨時可以下載最新版的”已測試過"軟體來使用，再也不用等人手動去 build 出來了。
0 comments