企業端如何推動持續整合開發流程

持續整合(continuous integration, CI),就跟測試一樣,在有時程壓力,以及新功能開發的優先下,常常是被忽略的流程之一。

明明很重要的事,為什麼會被忽略?

這時候我們就要想想為什麼重要,我想很多時候是因為不清楚為什麼要。

說到持續整合,我們就要先從開發的流程開始,一般一個專案開始開發,可以參考下圖:

enter image description here

可以看到每個階段都有其對應要處理的事項,而關於這些不同階段的事項所要解決的事情如下:

  1. Agile Development: 有效率的溝通,做最有價值的事
  2. Continuous Integration: 自動化測試,自動化建置,讓重覆的事情可以自動執行
  3. Continuous Delivery: 讓專案可以自動發布,隨時有穩定版本可以運作,加速 test 驗證
  4. DevOps: 確保運行環境正常,負責將上述各個機制建置及維護,還有一旦 production deploy 之後的維運。

當然,實際狀況絕對不是 DevOps 這個職位的人單一可以完成上述所有的整合,必須要專案開發人員與及規劃時皆已考慮才有可能順暢的進行。

上述每一個環節都是要避免所有不必要的浪費

  1. Agile Development: 避免用昂貴的人力(你)無效的溝通
  2. Continuous Integration: 避免用昂貴的人力(你)進行重覆測試,避免用昂貴的人力(你)進行重覆程式打包
  3. Continuous Delivery: 避免用昂貴的人力(你)進行 produciton deploy

除了解決不必要的浪費,還有避免人為錯誤,一旦所有程序都自動化後,錯誤將容易被排除驗證。

就像豐田式生產(TPS, lean production)所提倡的理念:杜絕浪費;每一次的浪費一旦被避免,也就表示有更多時間資源可以進行有價值的事!

最終就會像下圖一樣,一步一步改善,一步一步進化,成為專案的魔鬼終結者:)。

enter image description here

知道了持續整合的意義及目的後,我們可以開始來說明企業端如何推動持續整合開發流程。

需要知道的是,軟體開發的進化,其實不像生物進化那樣的漫長,也不是每個步驟都有多大的學問,最重要的是一開始就必須要知道每個步驟以及環節,所要解決的事情,以及要如何達到。

所謂持續整合,其實可以從幾個現在開發方式或工具來說起。

version control system

千萬不要說我們有在用版本控制,不過是用 FTP… 我想那也等於沒有版本控制,隨時都有可能造成檔案覆蓋,只要一不小心刪錯檔案,所有努力都會化為烏有...

目前主流的版本控制有:

  1. git
  2. svn

花一點時間了解一下相關的使用方式,想要初步了解,網路上都有很多教學資源,這將會是一個專案開始前最重要的準備工作。

one command line build

一旦你的服務開發完成,當然希望可以很方便的進行安裝,如何一行指令完成相關檔案的安裝,是可以努力的方向,任何語言都有對應的工具可以進行。

java:

  1. maven
  2. ant
  3. gradle

javascript:

  1. grunt
  2. gulp
  3. webpack
  4. npm script

其他語言相信也一定會有相關的 build script,搜尋一下相關的資訊,你將會有更多發現。

在專案一開始,就先把上面兩個基本功先搞定,將可以第一階段節省開發時間,比如一旦開發告一段落要進行 demo 時,就可以在 dev 機器,透過版本控制 command line tool 把專案下載下來,並且透過 one command line build 將 service 運行起來,如此,也就不用傳檔傳半天,安裝相關套件浪費了整天的時間,時間寶貴,不該將生命浪費再重覆的事情上!

有了基本的 build script 以及版本控制後,我們可以在往下一步邁進:auto re-generate data。

auto re-generate data

為什麼我們需要 auto re-generate data,舉例一個情境,假設我們要測試資料的刪除的功能,一般的程序會是:

  1. 建立資料
  2. 讀取資料
  3. 刪除資料

上述三個循環執行多次一點,我相信資料遲早有被刪除完的一天,這時候你要在重建資料以便下次在進行刪除測試,或是將資料庫備份還原?

何不直接一點,一旦專案啟動時,則 reset database,然後透過程式或是執行 sql 語法將測試資料進行建立,如此一來,一旦你的測試資料玩完了,只要重新起動將會是一個新的開始。

通常,這樣的作業也有對應的套件可以處理,又或者,上面介紹的 one command line build 就可以把這程序加進去,在 development mode 的情狀下,執行資料庫 reset,讓每次測試都是新的開始。

當然,讀者一定會想,若我們希望資料可以保留怎麼辦?這時候若你的 environment 是 production 當然就可以 skip 相關的處理,根據不同的情形給予不同的處理,這是可以變通的。

喔!對了,通常要在準備 database server 會是一個大工程,我們可以透過 local storage database 來進行,如:

來進行,都可以很快速的模擬實際資料庫的情形。

想必應該會有另外一個疑問,不同資料庫怎麼相容 sql 語法,可以再搭配 ORM-物件關係對映 技術,同樣以 java,javascript 為例,相關 library 如下:

都可以讓你再用程式操作 database 上有一定的幫助。

有了資料重現的機制,恭喜大家,我們已經有 auto test 的基本要求了!再來我們可以把測試資料建立在啟動 sevice 之前先行建立執行。

bootstrap service/server

想像一下在開發一個 website 網站,一旦我們需要驗證時,通常就是啟動 server 進行測試,在下一個循環開始時,重覆同樣的動作,如果讓這樣的動作利用程式來進行,步驟將會如下:

  1. 啟動 server
  2. 建立資料庫
  3. 建立測試資料
  4. 開始進行測試
  5. 確認驗證是否通過

每次測試都會重覆同樣的循環,這個循環有多快,將會影響你的開發速度,可以想像,若每個步驟都需要人力介入是多麽浪費的事,所以,如果我們能夠讓建立資料的部分也能自動化,又是一個更進一步的改善!

接著我們可以在更進階一點,想像另外一個情境,現在專案開發完畢,過程中我們可以很快速的進行專案 deploy 也可以很快速的啟動應用程式,每次啟動都是一個新的開始可以讓我們有全新的資料可以進行測試,但還是有個地方需要一直重覆,那就是整個專案所有細節需要用人工進行驗證。

one command line test

我想,這將會是最難一蹴可幾的地方,因為 test 其實是需要日常累積的,從每日開發養成習慣,一點一點累積,將為有越來越多 test 幫忙驗證相關程式穩定度。

但,常常遇到一個問題就是說既有的專案已經走到一個程度,該如何開始進行 test?我想從新的需求,還有舊有專案比較重要的功能開始補上 spec 將會是比較經濟實惠的開始。

一旦開始有些 test case 才能進行 CI 中的其中一環:auto test。

一般來說每個語言都有其 test framwork,舉例來說:

都可以提供你在測試上必要的功能,相信在進行時可以事半功倍。

有了之前的 one command line build 的經驗,test 也應該要 one command line 作為目標。

而有了之前 auto re-generate data 經驗,auto test 也應該要能夠在測試開始前將測試資料完成建立,如此就可以不停的重覆驗證,日以繼夜的確保專案的健康度。

OK,假設已經做到 one command line build,auto test 短期內可能也還沒辦法,請記得:「念念不忘,必有迴響」,念茲在茲都希望專案可以穩定發展,相信有一天不再擔心受怕不會是夢想,跳過比較需要時間醞釀的部分,我們可以開始架設 CI Server 了!

CI Server

市面上有很多,也有專書介紹,比較主流的有:

其實有很多,只要你有完成 「one command line build」 的實作,進階的「one command line test」,用起來都不太難,就像天下武功出少林一樣,可以以「one command line」貫之。

結論

每一個章節都是一個專門的技術,都是可以專文特別介紹的,在這邊提供相關資訊令讀者可以找到相關關鍵字以及資源進行研讀。

上述所有措施都是為了讓開發者可以專心於開發上,並且將重覆的動作利用程式的方式自動進行,如此每次節省的時間都是賺到的,剩下無法自動化需要創意的部分就是作為人類所需要處理的事,也就是你−最重要的資產。

持續整合,其實就是持續改善,每個自動化的環節,都可以進一步優化,一開始不必追求完美,先求有再求好並不是隨便,而是 lean 的精神的體現。

就像沒有 auto test 只有 auto build 還是可以開始架設 CI server 一樣,先能感受到它的好處,就有動力持續學習,持續改善,希望大家都可以務實的一步一腳印,讓專案運行的更有效率!