在研發過程中，大家都知道"版本"，但是不同的人對"版本"的理解是不同的。大家都知道很重要，但是往往容易被忽視，特別是在持續交付過程中，筆者認爲相當重要。因爲只要有變更，就會有版本控制，隨之而來就是版本號設計，以及不同階段如何使用版本號。
不同角色對“版本”的理解
產品經理、客戶、市場、PMO- 產品這次發佈什麼”版本“？
從產品管理和售賣的角度，這個版本只是對於外部發布有用，比如客戶要了解發布版本的特性等等。簡單說，這個“版本”是我們研發過程的最終的交付目標，往往和產品規劃有關。
研發、測試- 昨天的“版本（包）”測試通過了嗎？
但是，達成這個交付目標，肯定是通過很多次代碼提交，多次提測才能達成的。 那麼過程中，需要一個唯一的ID來標記，研發過程每次構建的產出，並且要保證唯一性。這就是構建制品版本。
區別小結
持續交付流水線中的版本號
怎麼得到構建制品版本？
一般會用”時間戳“，"svn/git commid‘，"環境tag"來標記，這個都沒錯。
-
獲取代碼時候，通過svn/git log 獲得，並且在流水線過程中傳遞
-
....
-
對於編譯型語言，甚至會把這個版本加入到
assemblyinfo中，作爲版本升級的兼容性判斷 -
上傳製品時候，可以給製品文件名加上這個變量；如果對接CI/CD平臺，也需要把”構建版本“發送給CI/CD平臺，作爲製品的元數據
部署過程中如何使用？
在構建腳本中，預留佔位符“packagename-${build_id}”, 這樣你的部署腳本就可以做到了複用。
微服務構建發佈場景
比如，在微服務多倉庫構建過程中，也會出現版本號的使用場景，比如通過“指針方式”記錄代碼提交；在多服務協同開發過程中，這個也很重要。
總結
總的來說，版本號就是整個研發流程中的各項指標數據的樞紐。記住一點，通過“版本號”貫穿一起研發活動，不要忽視它。
因爲只要代碼提交，就會有變更，變更需要被追溯，這樣質量才能得到有效監管，通過持續集成的方式，任何的 變化都能快速找到並修復。
另外，版本管理也是配置管理的重要實踐之一，特別是對於大型團隊或組織，版本的混亂，必然意味協同和管理的混亂和無序，效率也不會太高。
