就像我們上次提到的，很多提供服務的網站都會準備一部機器作為預備。而這部機器往往不單只是作為主要伺服器的備份，也經常作為開發新功能的測試機器。這在版本控制的觀念中，應該可以對比為開發中版本跟穩定版本，而這也就是系統的開發線。
整個系統在開發的過程中，隨著時間的進展，總是會有不斷的更新。或是修護程式的錯誤，或是開發新功能。於是我們沿著時間往前走去，就是整個系統的開 發線。不過在這條線上會有許多的分岔點，包括最基本的，也就是剛剛說的：開發中版本跟穩定版本。其他在每次不同的釋出版本也會產生一個分岔，當然，這時候 分岔出去的程式碼常常會合併回原來的線上。但是這樣的分岔卻是必要的。因為當我們在釋出某個版本後，系統的開發線會繼續前進，但是就在同時，使用者會回報 發現的程式錯誤。那麼我們就必須依照使用者回報的版本，修正程式的錯誤，而同時不影響目前程式的進行。
依照目前台灣許多軟體公司的作法，就是找出這個錯誤的原因，然後直接修改目前正在進行的版本。這樣的問題很可能讓這個錯誤產生更多的問題，尤其如果 當你的系統架構已經有所變動的時候更是如此。不過就算你修正錯誤了，接下來的問題你可能可以想像出來。因為你修正的基礎和使用者所使用的並不相同，下場通 常不會太圓滿。
另一個常見的狀況通常是一個公司有數個客戶，於是他們就把幾乎 70% 相同的程式碼存了好幾份，而每一份都是完整的程式碼。這樣似乎沒甚麼大不了的，不過每一份程式碼都由不同的工程師維護。而最常見的狀況則是大家都在差距不 太多的時間點修改同一個錯誤，這樣實在非常耗費人力，而且顯然不太明智。
當然，這樣的狀況也容易造成程式無法重用的情形，不過這似乎是後話。
其實比較容易的作法應該是保留開發線上的作為核心 (core) 版本，也就是公司產品的核心，然後針對不同的客戶產生出不同的分支 (branch)。如此一來，只要有人維護核心的部份，每次修正的問題或新增的功能都能根據每個分支的需要進行整合。而如果某個客戶的需求非常實用，也可 以把這個分支產生出來的新功能整合回核心的開發線，一但測試沒有問題，就可以讓其他分支使用，聽來應該是非常有效率的作法。當然也是版本控制對於系統開發 的功能。
Post a comment