持續整合下的版本控管做法

在軟體開發過程中，程式碼的保存一直是不容忽視的工作事項，而這常受到許多不可抗力因素影響，像是硬碟故障、檔案被誤刪或覆蓋，而造成事後甚高的補救成本。

人有失足，馬有亂蹄，因為程式總會寫錯，需求規畫也可能隨時變更內容，所以，系統總是會需要回復到先前開發的版本。

然而版本控管當然不只是程式碼備份，它可以詳盡記錄程式碼內容異動歷程，是這種工具最基本的功能，以最少的檔案空間記錄最完整的版本資訊，讓開發者可以實際找出所想要的程式碼版本內容。

而為同時能方便維護，版本控管工具也提供了軟體分線管理的概念，讓軟體的管理者可以依特定需求在同一時間發展不同的軟體版本，而將彼此的影響程度降到最低。

另外，軟體開發通常需要多人協同運作，此時就會團隊運作必須解決同一份程式碼同時被多人編輯的問題。版本控管工具提供了成熟良好的機制，發出警訊提醒管理者及相關開發人員及早處理，以避免未預計的狀況不斷發生而延誤開發時程。

版本控管在做什麼？

一般版本控制軟體的系統架構，以集中式管理為主，而且，系統會以儲存庫（Repository）的方式，將所有欲被控管的檔案內容保存下來，包括在開發過程中所有對程式碼的新增、修改、刪除等動作。

軟體開發人員透過簽出（checkout）的方式，取出指定版本的程式碼內容，在開發環境針對自己的程式碼修改驗證無誤後，即可利用版本控管軟體將修改的程式碼檔案交付（commit）到儲存庫中。一旦交付，版本控管平臺會自動賦予一個修訂版本編號（reversion），做為未來版本管理的主要鍵值。

版本控管平臺允許用專案（project）的方式，來分別定義管理不同範圍的程式碼，而開發人員依其權限的設定，可將指定專案的程式碼內容更新（update）至自己的工作環境（workspace）中，開發者在交付程式碼內容時，版本控管工具會依版本編號來判斷是否可以直接交付，或是出現版本內容衝突（conflict）的警示，讓開發人員進行後續程式碼內容比對（diff）及協調處理。

版本規畫的實務運用

版本控管工具都支援版本標籤（tag）及分支（branch）的機制，以利管理者在軟體發展的生命周期中方便管理。

這兩種方式的使用時機如下：

當軟體開發至可部署發行的版本（release）時，此時就會以標註tag的方式，以利未來快速調出版本內容。標籤的命名方式可結合日期，版控工具的trunk/tags/branches層級編號，對外發布的版本編號，主要發布功能，或是問題編號等資訊以利人為判讀。

然而分支的運用，常見的實務運用像是自有軟體產品的公司，會有預定的產品發展計畫。而實際導入在客戶端時，必然會針對客戶需求進行部分客製化調整，此時這個客製化版本即可利用分支的方式來後續開發管理。規畫出分支的版本，是可以不用再合併（merge）回主版本的。

另一種常見的狀況是同時進行多項需求平行開發時，彼此可能會因為修改在針對軟體加入新功能，而此功能之開發所需時間較長，擔心新功能開發過程中因舊功能發生錯誤需要修復而造成困擾。所以會將較費時的需求，規畫一套獨立分支版本，未來開發完畢再合併回原主版本。

程式碼的合併是有風險的，所發生的內容衝突都會造成不可預期的額外工時，包括了合併程式碼、測試驗證，甚至重新設計等。

相關工具與評估選用的考量點

從早期的CVS，廣泛採用的SubVersion，以及最近較常被討論的Git等，都是活躍於開放源碼界、常用的方案，若你考慮付費的平臺，像IBM Rational Team Concert、Microsoft Team Server等，亦包含版本控管的產品線。

而選用的考量上，有以下幾點：

● 是否與目前開發團隊的開發工具無縫整合？

版控的相關功能必須要能整合在現有的整合性開發環境（IDE），若在開發過程中切換多個視窗，來處理頻繁的程式修改動作，不易提高工作效率。

● 版本控管平臺是否支援Web介面操作使用？

除開發人員會透過client工具直接存取，若平臺也提供Web介面提供相關資訊，非開發人員想要了解內容則可以不用再安裝工具，可直接用瀏覽器的方式查看，應用上會更方便。

● 管理上的方便性？

由於大部分版本控管系統採集中化方式管理，當將所有的專案都往上頭一一建置後，其扮演的角色就日益重要。在可用度及備份機制的完整性上也必須一併考量。

另外，由於近期雲端概念的盛行，也可考慮採用既有的服務提供平臺來處理軟體版本控管的需求，除了提供可存取性外，也能節省實體硬體設備及平臺維運的成本。知名的像是Sourceforge、Google Code、github、BerliOS Developer，都有類似服務。

● 是否支援其他理論規範？

像CMMI、ITIL、PLM等，大型企業已經逐漸重視，視為企業流程標準化的參考依據。若公司已經計畫導入類似的作業流程，所選擇的解決方案必須要同步考量是否滿足這些規範的需求才行，否則屆時可能會面對系統重新移稙的成本。

● 是否支援多站點架構（multisite）？
實務上常見以外包方式進行專案開發，甚至外包對象會是跨企業，甚至跨到對岸去，所以版本控管的架構是否能有效支援多點管理，其中針對不同站點之間的資料複寫及同步、權限控管，都很重要，而且它們都是十分複雜的機制。

除了導入工具，專案團隊還需要……

系統只是個協助存取程式碼的工具，然而當軟體開發團隊欲應用在實務上時，有一些良好習慣的養成及作業規範，是必須先形成共識的，例如：

● 當開發者接獲需求欲開始進行開發前，必須先利用版本控管工具，取得目前儲存庫中最新版本的程式碼內容再開始作業。

● 只要開發者撰寫程式碼到一個階段，就將可建構的版本隨時交付至程式儲存庫中，並落實log註解內容的撰寫，以保持儲存庫中的程式碼是最近狀態，且是可被成功編譯建構的。

● 在交付程式碼時當發生與現有版本內容衝突的情況，從修改歷程記錄中得知前一版修改人員，進而主動與其討論解決。

● 開發人員每日下班前，必須將工作環境中可建構的版本交付出來，千萬別將程式碼保留在簽出狀態，人就下班了，相信當遇到程式碼內容衝突時，不在場的人常是犧牲的對象。

● 結合自動化建構工具的整合，專案經理在得知建構作業發生錯誤時，必須立即通知相關程式碼負責人員一起處理即時修復，以利開發作業能持續進行。

我認為，這些規範的落實比選用那一套版控工具要重要得多，故在評估導入時必須強化宣導，否則持續整合之價值無法有效彰顯。

最後，你只要思考一個問題：當正式版本軟體因不可抗力之因素無法取得，或正常運作，是否可以從現有的版本控管平臺，重新完整建構一份出來完成系統復原作業，你就會知道要應將那些內容納入控管。

作者簡介：

陳宏一

交通大學資訊管理研究所碩士

目前任職於某數位行銷公司技術經理，曾任職於南亞科技資訊部工程師、資迅人網路研發副理、艾群科技產品研發部經理，專精於OOAD、 J2EE 相關技術、Open Source、資料庫設計、軟體開發流程及專案管理等；取得SCJP、SCWCD、SCJD、SCEA、ITIL等認證。曾經歷大型社群及電子商務網站、 WAP/3G行動加值服務、CTI/CRM客服系統架構規畫設計等。