版本控制這個題目可以寫上好幾本書, 甚至要延伸上去就是 Software Engineer 軟體工程的範籌, 甚至包含測試的環節來看, 這就是個過大的議題, 也是 30 篇寫不完的, 我也看到有人寫有關版本控制的鐵人文章, 畢竟這個現在已經是個顯學了, 理論上就不用花太多心力來著墨細節, 但不一樣的是以 HA 的角度來看這議題多少還是有點不一樣.

的確在更新版本的時候, 是最容易發生 Runtime Error 的 Downtime 的狀況, 甚至有時測試環境測完還是很正確時, 一到上線 Production 環境, 就是甚麼都有問題, 我就曾經預過一個程式設計師, 居然會去 Update Primary Key 更新主鍵,造成系統完全 Hold 不住的狀況....
無論是作版本控制或測試平台, 當然都是為了避免錯誤, 或者是發生錯誤後及時的補救, 在某方面也就是利用軟體, 資料, 硬體的 Redundence 來去做到 High Availbility, 尤其就像是所說的: "事實上出問題往往不是發生問題, 而是問題是被產生的, 尤其是內部造成的機會是最高的."

在複雜系統中, 最大的問題就是單元測試 Unit Test 以及系統整合測試 System Intergration Test, 尤其是 HA 要求的是低 Downtime, 甚至在 Update/Upgrade 都要求效率的情型下, 說要停機更新是盡量避免, 所以最後也是部份更新, 向下相容, 但也是因為要求部份更新向下相容, 系統與程式就變得更複雜了, 通常我們知道, 若是要能更線上即時更新, 其資料以及程式都還在跑, 當系統更新時就要處理其相關問題, 就有幾種方法.

**1. 先將一部份的資訊流停下來, 然後等到結束時再更新, 這是最不好的狀況.

2. 直接更新一個可以同時處理新資訊與舊資訊的系統, 但會造成多餘的負荷.

3. 先上一個可以相容的元件, 一面處理舊資訊, 一面產生新資訊, 然後等到全部都是新的資訊流時, 再上更新的元件.**

而事實上 Runtime 是最不可預期的, 說到測試環境跟真實環境再怎樣也無法 100% 相同, 最後還是要有還原計劃.

任何大型系統, 是不可能不用版本控制, 甚至有人是堅信版本控制是最基本的事, 也因為是最基本但也最容易被遺忘, 所以有人就主張一開始就要架構在版本控制的系統下做開發, 不能偷懶.

在實務上我也知道即使真的有測試, 真的有做版本控制, 會出問題的機會還是太多了, 加上資源有限, 說要真的去做這個又是跟 "功能面" 無關的事, 也是最容易被犧牲, 或者是被縮小範圍與規模的實作, 在系統開發中, 的確不得不否認資源的條件限制是最明顯, 但也是最困難解決的事, 最後也是看經驗與智慧做取捨.

畢竟從來沒有說過 HA 是便宜且一定要的事, 只是當你吃過虧後, 才會知道這是重要, 要花更多資源的事.