在研發過程中，大家都知道"版本"，但是不同的人對"版本"的理解是不同的。大家都知道很重要，但是往往容易被忽視，特別是在持續交付過程中，筆者認為相當重要。因為只要有變更，就會有版本控制，隨之而來就是版本號設計，以及不同階段如何使用版本號。

不同角色對“版本”的理解

產品經理、客戶、市場、PMO- 產品這次發布什么”版本“？

從產品管理和售賣的角度，這個版本只是對于外部發布有用，比如客戶要了解發布版本的特性等等。簡單說，這個“版本”是我們研發過程的最終的交付目標，往往和產品規劃有關。

研發、測試- 昨天的“版本（包）”測試通過了嗎？

但是，達成這個交付目標，肯定是通過很多次代碼提交，多次提測才能達成的。 那么過程中，需要一個唯一的ID來標記，研發過程每次構建的產出，并且要保證唯一性。這就是構建制品版本。

區別小結

持續交付流水線中的版本號

怎么得到構建制品版本？

一般會用”時間戳“，"svn/git commid‘，"環境tag"來標記，這個都沒錯。

• 獲取代碼時候，通過svn/git log 獲得，并且在流水線過程中傳遞

• ....

• 對于編譯型語言，甚至會把這個版本加入到 assemblyinfo中，作為版本升級的兼容性判斷

• 上傳制品時候，可以給制品文件名加上這個變量；如果對接CI/CD平臺，也需要把”構建版本“發送給CI/CD平臺，作為制品的元數據

部署過程中如何使用？

在構建腳本中，預留占位符“packagename-${build_id}”, 這樣你的部署腳本就可以做到了復用。

微服務構建發布場景

比如，在微服務多倉庫構建過程中，也會出現版本號的使用場景，比如通過“指針方式”記錄代碼提交；在多服務協同開發過程中，這個也很重要。還有在微服務的發布部署過程中，也會用到相關的版本號。

總結

總的來說，版本號就是整個研發流程中的各項指標數據的樞紐。記住一點，通過“版本號”貫穿一起研發活動，不要忽視它。

因為只要代碼提交，就會有變更，變更需要被追溯，這樣質量才能得到有效監管，通過持續集成的方式，任何的 變化都能快速找到并修復。

另外，版本管理也是配置管理的重要實踐之一，特別是對于大型團隊或組織，版本的混亂，必然意味協同和管理的混亂和無序，效率也不會太高。