用CI面對軟體開發團隊的難題

場景一：「咦？Roger，昨天加班到幾點才走呀？」

「唉，搞到很晚，程式在開發環境測試都沒問題，結果在SIT環境上build不過，查半天，才發現開發環境的某個JAR檔版本不對，搞好久……」

場景二：「Kevin很早就來了呀？昨天沒回去？」

「是呀，早上系統要上新功能，這次的需求範圍很大，約異動了一百多支程式，怕動到原有的功能，就也將原有的功能都逐一再測過，測試案例實在太多了，得花很多的時間再確認…」

場景三：「咦？Alex還沒要走呀？」

「唉，臨時被通報系統有問題，還在查問題的原因為何。奇怪，今天上版前還好好的呀，怎麼上了也就掛了，也沒改到什麼程式呀……」

上述場景，身為軟體開發團隊成員的你應該不陌生：工作時間常被突發事項所中斷，或是被一些非主要核心的工作事項所延誤，導致於增加自己的工作時間，搞得身心疲憊，工作品質也每況愈下。

軟體開發長久以來常見的痛

沒錯！致命的痛楚，常常是經年累月未明顯改善後的結果。你是否也遇過以下狀況，讓你傷透腦筋：

● 昨天才改好的程式，在整合時發現問題，原本來其他同仁的檔案內容覆蓋了，最糟的是自己也沒備份，必須從頭再來一次。

● 新功能都已經正式發布了，需求單位才又要求要回復先前的功能，因為沒有版本控管機制，程式碼已找不回舊的版本內容。

● 自己已經寫好的程式，在自己的開發環境測都沒問題，但丟到整合測試環境時就狀況連連，又得花上不少時間來找原因，不斷反覆測試花費了不少時間，最終還是沒測完整，一些嚴重的例外狀況或異常問題，都是在正式上線後，才逐一浮現。

● 當程式碼更新到正式環境後，原本可用的功能卻出現異常，最糟的是開發單位並不曉得，而是等到使用者單位反應才知道。

● 由於時程的關係，多個修改需求必須同一時間一起進行，多人同時修改相同的程式碼區段，使得版本卡住的問題影響開發順暢度，需花上許多時間調整，才可能更新成功。

● 只要有修改程式就得重新編譯封裝測試部署，以人工不斷執行這些工作的效率不佳，而且容易因無誤而出錯。

上述問題，不外乎都是該標準自動化的作業程序未能有效落實。這些問題，導致需要花上額外的時間來緊急處理，間接又影響其他已經排定的工作，造成開發人員不斷地加班趕進度，不斷出錯，落入永無止境的無窮迴圈。

持續整合的精神所在

首次聽到持續整合（Continuous Integration，CI）的人，對這名詞應該是一頭霧水，其實就是讓軟體專案順利進行的方法，搭配一些系統自動化的工具，落實在開發、建構、測試、部署各個階段，目的在於不斷地透過持續改善的方式，整合團隊投入的資源，讓軟體品質的成熟度更高。

所以近年來在軟體工程方法往輕量化，成果導向化的方向演進後，快速開發已經是現今軟體專案的最重要訴求，才能隨時因應需求面因為劇烈環境的變化。像是敏捷開發（Agile Software Development）、測試驅動開發（TDD）、極限編程（XP）方法論的實作理念中，皆提出持續整合的重要性，可見這種觀念越來越受到重視。然而「快速」不只是開發時間要快，相關的作業程序必須要能提升效率，否則瓶頸仍然無法突破。

只要程式碼內容有異動便整合，持續進行

以往的軟體專案，都會將整合測試時程定義在開發階段的末段，所以，全部的程式碼也是在那個時間點才來進行建置及整合。尤其大型專案的程式碼異動範圍較廣，所需開發時程較長，在整合測試時所會出現的狀況就會顯得有些失控，直接影響專案時程落實的準確性。

持續整合強調的是，開發團隊一旦進行程式碼修改，即刻進行整合測試驗證，好處在於及早發現及早治療，就不會讓整合遇到的問題被延後發現。

妥善的版本控管，包括程式碼及外部函式庫

只要是多人同時運作，必然會有程式碼共同使用的管理問題，所有更新的內容，均必須集中且完整地記錄下來，隨時因應不時之需。

在軟體的發展過程中，版本的分支、合併、回溯、比對，都會因不同的現實需求而受到要求來執行，所以只要你的軟體專案不只一個人開發，就必須建置良好的版本控管平臺。一併將自己開發的程式碼及外部函式庫版本同步納入管理，就可以確保在每個環境的版本一致，避開無法預期的錯誤。

將繁複的人工作業予以標準化、自動化

早期，任何談論軟體工程方法論都會提及這樣的想法，像是單元、整合、迴歸等測試自動化，以及寫程式時即同步撰寫文件、多人平行開發撰寫程式碼、整合測試環境自動構建作業的理想，只是觀念一直沒有配合適當的工具來落實，僅限於紙上談兵的階段。

軟體工程的「工程」兩個字，應該是盡可能將作業程序自動標準化，才能確保品質。實務上卻沒有充分利用系統自動化的機制或工具，反倒是以人力密集來填補這些不斷發生的問題，時間久了當然也身心俱疲。

持續整合觀念即在於解決上述開發環境及反覆流程所發生的問題，並做到「一指定江山」，理想上是做到只要按一個按鈕，系統就會自動進行軟體建構作業，連測試、分析、作業，都一併處理完畢。這樣的概念，目前已經有協同搭配的自動化工具可以協助落實，大幅提升效率。

軟體品質要求的提升

軟體品質的提升可分兩個層面，包括機器及人文。讓機器能運作順暢的程式碼，必須靠著精準且完整的測試作業才能達成，從開發階段的單位測試及整合測試，到使用者主導的情境測試，測試的項目實在太多，必須將重複進行的測試工作透過系統來落實。否則常因為時程壓力忽略測試作業，造成軟體品質低落。

而在人文方面，程式碼本身的易讀性亦是品質關鍵之因。程式碼是不斷由人所編寫修改，而且同一程式是由多人修改的。結合自動化構建作業、同步整理程式碼撰寫風格，並以一致化規範來格式化，能讓開發人員在最短時間拿到程式碼後即刻著手修改，亦是品質要求後所能達到的成效。

專案團隊協同運作更密切順暢

專案的協同運作上，免不了會有丟球、接球的合作狀況出現，就像大隊接力，除每一棒的跑者自身腳程的鍛練外，著重在能否以最短的時間順利接棒，整體團隊花費的時間才能有效縮減。

利用持續整合中所提到的協同運作系統平臺，專案團隊可藉此集中控管所有開發內容，包括所有外部、內部引用之資源，自行開發之程式碼，所有更新歷程均明確記錄；透過自動化的流程結合人工作業，輔以即時性的訊息通知，就可以節省無謂的等待時間，在建構完畢會將過程中出現錯誤的部分，直接派送到負責工程師，以利立即處理掌握時效。