Continuous Delivery


「continuous delivery book」的圖片搜尋結果

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。
  1. CI
    1. 我們選定的 CI 是用 TeamCity,其實 Jenkins 也不錯,但是比較起來商業化的軟體在易用性及介面上,還是略勝一籌,加上之前也都是在用 TeamCity,我覺得用 TeamCity 可以更快上手。
  2. Unit Test
    1. Unit Test 使用 Google Test,為何捨棄原本的 Boost Testing Framework?一個原因是它在 mock/stub 這一部份還不及 Google Test 完整,因此我們選用了 Google Test。
  3. UAT (User-Accaptance-Testing)
    1. UAT 的部份則是使用 Robot Framework,沒有特別原因,只是因為有其它同事正在用,就一起用吧 XD
  4. Qt/QML Testing Framework,
    1. GUI Application 的測試,有一點很重要的是要以 HANDLE、object ID 來操作,而避免使用”圖形”的方式來操作,因為你的 GUI 有非常大的機率會調整,只要一改,你的 test case 就要全部重來了。但是 QML Application 裡頭是沒有所謂的 window handle 的,跟傳統的 Windows Application 不大一樣,而目前市面上只有 Squish 有辦法去對 QML Application 做到使用 object ID 來操作。(Ubuntu 的 testing tool 似乎也有,但沒有深入研究)
    2. 但我們並沒有使用 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 的目標。這個系統會自動完成下面的工作:
  1. 有團隊成員 commit code 之後,開始進行 build,然後執行全部的 unit test
  2. 通過 unit test 之後,自動打包成準備釋出的 installer.exe
  3. 接下來自動依序發佈到不同平台的 VM 上去進行測試。
  4. 系統呼叫 sikuli,自動在各個 VM 裡頭執行 installer.exe,並完成軟體的安裝。
  5. 安裝完畢,會呼叫 Robot Framework 開始進行 UAT (User-Acceptance-Testing)。
  6. 完畢,產生報告。
有了 Continuous Delivery,現在 RD/UX/PO 都隨時可以下載最新版的”已測試過"軟體來使用,再也不用等人手動去 build 出來了。
更多技術細節,就等其它人分享了 :)

0 comments