如何實施與導入持續整合

前一回提到持績整合所帶來的好處，但相信很多人在研究一些軟體工程方法論的書時，心中大都會浮現以下問題，或遭遇一些無法控制的狀況：

●研讀了不少軟體工程的書，像UP、Agile、XP、Scrum等觀念都很棒，但真的專案在進行時，還是不知道要如何套用進來？

● 軟體工程方法是一回事，實做又是另外一回事？因為專案團隊的成員對方法論都不熟，不斷嘗試錯誤未能全然掌握方法的精髓，常常走許多冤枉路，才有一點點進展。

● 軟體專案計畫派不上用場，時間上根本不足以允許你妥善規畫，可能老板的一句話就將原有的規畫全盤打破，當專案被時程壓力所限制後，所有的方法論就拋諸腦後。

● 新方法的導入造成現行作業的衝擊，團隊成員浮現抗拒心態，造成想推也推不動。

持續整合的範疇

持續整合的範疇，可依專案組織的現況及現有可用資源，來決定需要導入的項目。一般而言，可分以下項目分別導入建置：

● 版本控管（Version Control）
於多人開發的專案團隊，版本控管的議題算是最基本，也是最重要的項目，準備一個版本控管資料庫 （Repository） 是必要的。軟體開發的生命周期過程，必然會面臨程式碼版本的分支（Branch）、貼標（Tag）、合併（Merge）、回溯（Revert）、比對（Compare）等需求。良好的版本控管機制可提供好的工具，來協助開發人員面臨這樣多變的需求，以利在短時間內能產出正確可部署的軟體版本發布。

目前坊間常見的版本控管機制，包括付費及免費、集中及分散式控管，種類甚多，評估導入的因素可依專案團隊同時使用人員的多少，開發工具是否能整合，建置成本及時間的長短等因素，來分別思考，來找出適合開發團隊使用的方案。

● 測試自動化（Auto-Testing）
軟體測試的類型繁多，主要都是為了確保軟體品質而搭配使用，測試作業的繁複常不易在有限的專案時程內被全然落實，有時亦會為了方便行事，忽略了部分測試作業，或是避開重測，但常常事後發生異常的點，都是這些被忽略的地方。

利用人工來進行測試作業是十分累的，所以將繁雜且重要的測試工作自動化是必然的，將各項重要的測試工作及測試範圍涵蓋度的檢測，連同程式碼建構作業時以系統自動執行必要測試的項目一併處理，當出現異常錯誤時再由人工介入處理，才能將時間有效花在刀口上。

不過想到要多寫這些測試程式，相對又增加一定比重的開發時間，對開發人員勢必又造成負擔。當然也可以配合一些測試程式碼的產生工具，來快速生成測試作業時的基本所需。

● 建構自動化（Auto-Build）
建構自動化的用意在於及早發現程式可能的錯誤，在未擴大影響範圍之前便先行處理，而持續整合的精神亦可以透過設置頻繁自動建構的方式 （例如系統每60分鐘自動執行建構作業的執行），結合自動通知機制，讓開發團隊成員可以得知目前最新版本的建構結果。

建構作業的項目，除整合前項測試外，亦可加入許多提高軟體品質的作業，例如程式碼撰寫風格的格式化，方便後續開發人員撰寫時閱讀；以及，針對程式碼內容反向生成參考文件，以利程式與文件內容一致化；或是利用靜態程式碼掃描工具，一併檢測程式隱含的效能及安全性問題而及早修正等。

● 錯誤通報及後續追蹤處理機制的整合
軟體開發團隊必然有問題追蹤系統 （Issues Tracking System），其中錯誤問題的來源可能是日常外部單位的通報、系統自動監控的示警、軟體建構過程中發生的編譯錯誤或測試失敗。然而這些事項的分派及後續處理狀況的追蹤，理想上也必須能透過系統自動化的方式來進行，才不致於造成工作分派環節的瓶頸所在。

持續整合對專案團隊各角色的衝擊為何？

新方法及工具的導入，對既有專案團隊的影響，會歸因於所選擇導入的方式，主要的影響如下：

● 每位開發人員應盡可能不斷地將修改後，可以成功建構（build）的程式碼內容隨時交付（commit）至程式碼資料庫（Repository）中進行整合，相關動作的執行可以每日多次，頻率可以提高。

● 開發人發必須嚴守交付可成功構建的程式碼，尤其是在每日下班前確保這個動作無誤。

● 開發團隊必須撰寫額外的測試程式。開發人員需要針對自行開發的元件及服務，完成測試程式的撰寫；而系統設計師也必須針對跨元件或整合服務流程，進行測試程式碼的撰寫，搭配程式碼構建時的測試自動化作業，以確保程式碼品質。

●整合構建時若出現錯誤、測試自動化過程若出現錯誤結果，亦須立即處理修改。

●開發人員必須隨時確保自己的工作版本，與目前版本控管資料庫中的程式碼一致。

這些都是作業原則及開發紀律的要求，落實於軟體開發作業更能有效發揮持續整合的精神，執行的方式會因採用的工具不同而做法不一。嚴格說來，對於每個專案成員的現行作業方式並不會有太大的衝擊，也許需要短時間適應一些工具的使用及自動化平臺的建置，但這僅為一次性的短期影響，而且不會投入太高的成本，包括人力及軟硬體需求。

開發團隊每天進行持續整合的作業流程

對於開發人員而言，每天早上上班前會先將版本控管平臺裡最新狀態的程式內容，更新到自己的工作環境中；同時前一天每日建構版本（Daily Build）的作業是否有發出錯誤通知，需要自己立即處理的問題; 接下來隨即進行今日的開發工作進度，檢視問題追蹤系統中被指派的工作項目，進行程式碼的修改及測試。一旦開發好的元件完成自己的單位測試後即交付至版本控管平臺上，若有任何更新交付後的程式碼在自動建構作業過程中有問題，亦會即時收到通知而立即處理。

而專案經理每日亦透過建構平臺所提供的建構結果報告，了解每次建構版本的編譯及測試範圍及結果是否符合預期，當結果出現錯誤時，需及時聯繫涉及的開發人員及時進行問題處理；而在開發進行中，交付程式碼期間出現多人編輯而發生版本衝突時，需要協調相關人員進行程式碼合併作業以利順利交付。而上線版本的決定，則會依據開發進度及測試狀況，部署至其他測試環境，來提供不同的測試目的，以利進行測試。

持續整合的價值何在？

以上利用持續整合的實務做法，最重要的是從已經被壓縮的專案時程中，以系統自動化的方式擠更多的空間出來，讓專案團隊能更從容地做好原本應該完成的工作，甚至可以應對其他千奇百怪的突發狀況。

持續整合實施後，整個軟體開發的進度隨之透明化，每個專案成員隨時都可以確切掌握目前版本的進度及品質狀況，大幅降低以往專案甚多不可知的風險，而對於開發人員亦對自己所撰寫的軟體品質更具信心，確定任何時間所建構的版本，都是可被部署且執行的。