在设计 DevOps 平台时，笔者认为版本号的管理是一个绕不开的课题。可是，行业里似乎很少人提这个事，笔者觉得要谈一谈，所以就有了这篇文章。
一万个人的眼里有一万个“版本号”
笔者这三年在同一家公司里，换岗换了四个团队。团队的成员组成各异，有的团队都是在大型跨国企业跳槽过来的，有的团队大部人都是刚毕业的。
每到一个团队，团队运行一段时间，都会做一件事情：讨论该怎么定义这个版本号。版本号的制定，有些只有开发人员参与，有时会有产品经理参与，有时还有 PMO 参与。
经过这些讨论，我发现：一万人的眼里有一万个“版本号”。讨论的最后，基本上就是谁的嗓子大，听谁的。
所以，在讨论“版本号”之前，一定要搞清楚讨论各方对于“版本号”的理解，再深入讨论，否则，大家谈的都会是牛头不对马嘴的东西。浪费时间。
为什么对于“版本号”，各方的理解，差异会如此大。笔者认为，主要是因为他们关心的面不同。
APP产品经理关心的是该APP在用户界面上显示的版本号，比如当前爱彼迎的APP的版本号是：1.9.44.china。
对于后端开发工程师，关心的是网关服务的版本是1.2.1、客服服务的版本是4.11.1。
对于前端开发工程师，关心的是通用组件的版本是2.1.1、首页组件的版本是3.1.1。
而对于 PMO，他们可能只关心在 Staging 环境的最后一个版本是否为一个稳定的版本（这写在他们的管理规范里），保证不影响测试人员的工作，根本不关心具体的“版本号”是多少。
重新认识版本号
各方的关注点不同，不是问题，但是我们作为一个平台的设计必须对“版本号”有更深入的理解。
笔者分析各方的关注点，他们所说的“版本号”分布在以下两个层面：
- 技术层面：程序员关心线上跑的是哪份代码（对应的是Git\SVN中的Commit ID）、运维关心线上跑是哪个版本（对应的就是具体哪个包）。
- 业务层面：方便终端用户识别的版本号，产品经理也属于这一层面。
认识到这点，我们设计DevOps平台，就会对两种版本号进行区别对待，进而设计出对团队非常有用的功能，最终帮助团队更好的实现交付。
为方便沟通，技术层面的版本号，如 Commit ID 我们称为技术版本号，业务层面的版本号，称为业务版本号。
版本号相关功能设计
但是版本号有什么用？仔细想想，除了产品经理发布时要定个版，后端服务的版本用于保证服务之间的相互引用或调用不出问题，就没有什么别的用处了。
也许是因为大家都不了解版本号的用处，也或者是认为它根本就不值得讨论，所以，笔者在国内的几个大的平台都没有看到版本号的相关功能的设计。唯一使用到版本号的地方就是在制品库，部署时需要指定制品的版本号。而业务版本号与技术号之间的关系被隐藏得很深，用户很难查到。
笔者不想一开始就谈它的好处。我直接上功能，下图是笔者臆想出来的。
笔者认为，DevOps 平台应该有的功能之一：能输出这么一幅图，暂定名为版本关系图。图中的方块下，同时标有业务版本号和技术版本号。而图中的系统之间的连接线是应用系统的调用链，读者可忽略。
版本关系图应该能提供以下信息：
- 系统应用之间的版本依赖。
- 系统内部所依赖的组件的版本。
- 能根据某系统的版本查到目前直接依赖于或间接依赖于它的其他系统。
- 各系统的版本变迁信息。
这些信息能给用户带来的价值如下：
- 团队内信息更透明，沟通效率更高，可以有效避免某个员工成为单点。你不必等其他成员，自己也可以得到整个系统的版本信息。
- 可以提高团队成员的排错能力，因为当A发布新版本后，APP 首页打开变慢，有了版本关系，我们可以首根据整个平台的“版本事件”来排查问题。同时，团队也很快可以找到相应的代码变更，然后进行 review 及修复。
- 上图中，当 A 服务是一个集群时，我们还可以将部署的目标机器与版本号关联起来了。这样，团队就可以轻松的知道，哪台机器部署了哪个版本。
上图只是整个业务系统的某个时间点的“快照”。事实上，我们还可以在版本号上做更大的文章。比如让技术版本号与代码质量、构建速度等过程指标关联起来，这样我们可以在不同的版本之间进行对比。再比如计算两个业务版本号之间，代码质量的差异，长期积累下来这些数据后，我们就有能力计算出代码质量与业务指标之间的关系。
总的来说，版本号就是整个研发流程中的各项指标数据的枢纽。
后记
版本号和其它数据的关系的价值，笔者认为被大大低估了。希望本文能给 DevOps 平台设计者带来不一样的想法。
