一說版本控制，就會思索着是不是來大談svn git或者是branch model。
然而這些東西似乎已經被業界說爛了。網上幾乎隨處可見這些如何切分支的文章。而我們通常忽略的是爲什麼這麼做，以及如何在一定的原則下去做，從而最大化的獲得配置上和執行上的自由度。
現在社會，再談版本就不再是過去我們從開發的角度來談的版本了。而是說，這個軟件產品對於用戶來說的版本。過去我們會說這個產品在alpha或者beta，上線以後叫大版本就是幾代幾代之類的，小版本就是大版本的補丁了，會有固定的小版本號。
這些再對應入我們產品開發團隊所對應的大小版本的發佈週期以及發佈計劃。
爲此我們給出一部分執行管理的原則，來幫助最大化減小發布錯誤的損失和風險。
-
大版本號，一定來自於產品團隊對於商業發佈的明確定義，需要定義清楚爲什麼那天發佈，發佈內容有什麼商業意義。測試和開發團隊需要商量此次的發佈需要的測試以及質量指標。產品以及市場也要爲此定義明確的驗收指標。例如，產品的上線前必須完成80-90%的單元測試條件覆蓋率。不允許有超過10個的critical缺陷。開發對於代碼質量在交付給產品驗收之前，需要完成代碼掃描，不得超過多大的threshold就是門檻閾值。
-
小版本號，理論上說，開發提交的每一個變更號對應的就是一個明確的版本編號。這個版本編號就是我們的小版本號。也需要明確的需求說明，改動影響說明。
-
小版本號還可以細分，哪些是專門針對新需求的，哪些是專門針對線上緊急修復的，還有一部分是內部重構更新的。這些都要能有有全面的體現。
當理解這些基本客戶訴求產生的原則後，我們需要考慮的就是如何給與足夠的控制。通常這些我們是習慣於交給集成或者發佈的專員進行的，但是過去這麼做就無形中加大了許多集成和發佈專員的勞動力，導致他們做了許多重複無用的勞動。爲了減少這些無用的勞動，我們需要做如下調整
-
需求的提交由開發者自行維護自己需求的分支
-
缺陷的修復由集成或測試統一開具分支，當結束一個修復週期後進行合併。
-
大版本的上線由集成開具分支，並在對應的確切日期時間點進行切分支操作
-
所有分支在合併時，必須提交pull request指令等待專人審覈後方可合併
-
缺陷，需求，重構等分支都要有明確的編號，便於快速識別。例如，缺陷修復版本bugfix，需求版本req，重構版本refactor等等。可以在具體的commit消息中嚴格規定。
-
內部發布給具體的測試服務器需要有明確的服務器發佈版本的管理列表，例如，測試機01，目前版本bugfix009，測試預生產機01，目前版本req010。這樣測試或者產品人員在驗收時可以明確知道自己要測試的機器是否有自己所需要的版本的產品被部署了。
-
軟件產品也應該在特定位置有明確標註當前最新的版本號。例如，大版本號，001，小版本號，req001。這樣，萬一我們沒有及時找到版本列表，也可以最快的通過軟件本身發現版本號。
如何執行，這個環節我們都知道知易行難。無數人無數組織倒在了開始行進的道路口，因爲無從下手。我們的建議是
-
明確哪些人，對哪些版本負責
-
明確哪些版本需要做什麼級別的測試
-
明確發佈各類不同需要的版本，大致的週期
-
版本號規則的命名
-
定義並且階段調整版本計劃。周知計劃。
-
建立版本的持續集成機制
-
所有發佈的歷史需要有羅列