【JSDC客座文章】企業端如何推動持續整合開發流程

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

明明很重要的事，為什麼會被忽略？這時候我們就要想想為什麼重要，我想很多時候是因為不清楚為什麼要。

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

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

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)所提倡的理念：杜絕浪費；每一次的浪費一旦被避免，也就表示有更多時間資源可以進行有價值的事！最終就會像下圖一樣，一步一步改善，一步一步進化，成為專案的魔鬼終結者:)。

知道了持續整合的意義及目的後，我們可以開始來說明企業端如何推動持續整合開發流程。需要知道的是，軟體開發的進化，其實不像生物進化那樣的漫長，也不是每個步驟都有多大的學問，最重要的是一開始就必須要知道每個步驟以及環節，所要解決的事情，以及要如何達到。所謂持續整合，其實可以從幾個現在開發方式或工具來說起。

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 來進行，如：

• H2
• sqlite

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

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

• java: Hibernate
• javascript: sequelizejs

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

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

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，舉例來說：

• java: junit。
• javascript: mocha。

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

有了之前的 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

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

• jenkins：老字號
• travirs：免安裝
• ...

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

結論

每一個章節都是一個專門的技術，都是可以專文特別介紹的，在這邊提供相關資訊令讀者可以找到相關關鍵字以及資源進行研讀。上述所有措施都是為了讓開發者可以專心於開發上，並且將重覆的動作利用程式的方式自動進行，如此每次節省的時間都是賺到的，剩下無法自動化需要創意的部分就是作為人類所需要處理的事，也就是你−最重要的資產。持續整合，其實就是持續改善，每個自動化的環節，都可以進一步優化，一開始不必追求完美，先求有再求好並不是隨便，而是 lean 的精神的體現。就像沒有 auto test 只有 auto build 還是可以開始架設 CI server 一樣，先能感受到它的好處，就有動力持續學習，持續改善，希望大家都可以務實的一步一腳印，讓專案運行的更有效率！