在研发过程中，大家都知道"版本"，但是不同的人对"版本"的理解是不同的。大家都知道很重要，但是往往容易被忽视，特别是在持续交付过程中，笔者认为相当重要。因为只要有变更，就会有版本控制，随之而来就是版本号设计，以及不同阶段如何使用版本号。

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

产品经理、客户、市场、PMO- 产品这次发布什么”版本“？

从产品管理和售卖的角度，这个版本只是对于外部发布有用，比如客户要了解发布版本的特性等等。简单说，这个“版本”是我们研发过程的最终的交付目标，往往和产品规划有关。

研发、测试- 昨天的“版本（包）”测试通过了吗？

但是，达成这个交付目标，肯定是通过很多次代码提交，多次提测才能达成的。 那么过程中，需要一个唯一的ID来标记，研发过程每次构建的产出，并且要保证唯一性。这就是构建制品版本。

区别小结

持续交付流水线中的版本号

怎么得到构建制品版本？

一般会用 ”时间戳“ ， "svn/git commid‘，"环境tag" 来标记，这个都没错。

• 获取代码时候，通过svn/git log 获得，并且在流水线过程中传递
• ....
• 对于编译型语言，甚至会把这个版本加入到 assemblyinfo 中，作为版本升级的兼容性判断
• 上传制品时候，可以给制品文件名加上这个变量；如果对接CI/CD平台，也需要把”构建版本“发送给CI/CD平台，作为制品的元数据

部署过程中如何使用？

在构建脚本中，预留占位符“packagename-${build_id}”, 这样你的部署脚本就可以做到了复用。

微服务构建发布场景

比如，在微服务多仓库构建过程中，也会出现版本号的使用场景，比如通过“指针方式”记录代码提交；在多服务协同开发过程中，这个也很重要。

还有在微服务的发布部署过程中，也会用到相关的版本号。

总结

总的来说，版本号就是整个研发流程中的各项指标数据的枢纽。记住一点，通过“版本号”贯穿一起研发活动，不要忽视它。

因为只要代码提交，就会有变更，变更需要被追溯，这样质量才能得到有效监管，通过持续集成的方式，任何的 变化都能快速找到并修复。

另外，版本管理也是配置管理的重要实践之一，特别是对于大型团队或组织，版本的混乱，必然意味协同和管理的混乱和无序，效率也不会太高。