谈 DevOps 平台设计：版本号相关功能的设计

在设计 DevOps 平台时，笔者认为版本号的管理是一个绕不开的课题。可是，行业里似乎很少人提这个事，笔者觉得要谈一谈，所以就有了这篇文章。

笔者这三年在同一家公司里，换岗换了四个团队。团队的成员组成各异，有的团队都是在大型跨国企业跳槽过来的，有的团队大部人都是刚毕业的。

每到一个团队，团队运行一段时间，都会做一件事情：讨论该怎么定义这个版本号。版本号的制定，有些只有开发人员参与，有时会有产品经理参与，有时还有 PMO 参与。

经过这些讨论，我发现：一万人的眼里有一万个“版本号”。讨论的最后，基本上就是谁的嗓子大，听谁的。

所以，在讨论“版本号”之前，一定要搞清楚讨论各方对于“版本号”的理解，再深入讨论，否则，大家谈的都会是牛头不对马嘴的东西。浪费时间。

为什么对于“版本号”，各方的理解，差异会如此大。笔者认为，主要是因为他们关心的面不同。

APP产品经理关心的是该APP在用户界面上显示的版本号，比如当前爱彼迎的APP的版本号是：1.9.44.china。

对于后端开发工程师，关心的是网关服务的版本是1.2.1、客服服务的版本是4.11.1。

对于前端开发工程师，关心的是通用组件的版本是2.1.1、首页组件的版本是3.1.1。

而对于 PMO，他们可能只关心在 Staging 环境的最后一个版本是否为一个稳定的版本（这写在他们的管理规范里），保证不影响测试人员的工作，根本不关心具体的“版本号”是多少。

各方的关注点不同，不是问题，但是我们作为一个平台的设计必须对“版本号”有更深入的理解。

笔者分析各方的关注点，他们所说的“版本号”分布在以下两个层面：

认识到这点，我们设计DevOps平台，就会对两种版本号进行区别对待，进而设计出对团队非常有用的功能，最终帮助团队更好的实现交付。

为方便沟通，技术层面的版本号，如 Commit ID 我们称为技术版本号，业务层面的版本号，称为业务版本号。

但是版本号有什么用？仔细想想，除了产品经理发布时要定个版，后端服务的版本用于保证服务之间的相互引用或调用不出问题，就没有什么别的用处了。

也许是因为大家都不了解版本号的用处，也或者是认为它根本就不值得讨论，所以，笔者在国内的几个大的平台都没有看到版本号的相关功能的设计。唯一使用到版本号的地方就是在制品库，部署时需要指定制品的版本号。而业务版本号与技术号之间的关系被隐藏得很深，用户很难查到。

笔者不想一开始就谈它的好处。我直接上功能，下图是笔者臆想出来的。

笔者认为，DevOps 平台应该有的功能之一：能输出这么一幅图，暂定名为版本关系图。图中的方块下，同时标有业务版本号和技术版本号。而图中的系统之间的连接线是应用系统的调用链，读者可忽略。

版本关系图应该能提供以下信息：

这些信息能给用户带来的价值如下：

团队内信息更透明，沟通效率更高，可以有效避免某个员工成为单点。你不必等其他成员，自己也可以得到整个系统的版本信息。
可以提高团队成员的排错能力，因为当A发布新版本后，APP 首页打开变慢，有了版本关系，我们可以首根据整个平台的“版本事件”来排查问题。同时，团队也很快可以找到相应的代码变更，然后进行 review 及修复。
上图中，当 A 服务是一个集群时，我们还可以将部署的目标机器与版本号关联起来了。这样，团队就可以轻松的知道，哪台机器部署了哪个版本。

上图只是整个业务系统的某个时间点的“快照”。事实上，我们还可以在版本号上做更大的文章。比如让技术版本号与代码质量、构建速度等过程指标关联起来，这样我们可以在不同的版本之间进行对比。再比如计算两个业务版本号之间，代码质量的差异，长期积累下来这些数据后，我们就有能力计算出代码质量与业务指标之间的关系。

总的来说，版本号就是整个研发流程中的各项指标数据的枢纽。