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

标签: dev | 发表时间:2019-11-08 00:00 | 作者:
出处:http://itindex.net/relian

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

一万个人的眼里有一万个“版本号”

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

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

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

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

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

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

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

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

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

重新认识版本号

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

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

  1. 技术层面:程序员关心线上跑的是哪份代码(对应的是Git\SVN中的Commit ID)、运维关心线上跑是哪个版本(对应的就是具体哪个包)。

  2. 业务层面:方便终端用户识别的版本号,产品经理也属于这一层面。

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

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

版本号相关功能设计

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

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

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

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

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

  1. 系统应用之间的版本依赖。

  2. 系统内部所依赖的组件的版本。

  3. 能根据某系统的版本查到目前直接依赖于或间接依赖于它的其他系统。

  4. 各系统的版本变迁信息。

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

  1. 团队内信息更透明,沟通效率更高,可以有效避免某个员工成为单点。你不必等其他成员,自己也可以得到整个系统的版本信息。

  2. 可以提高团队成员的排错能力,因为当A发布新版本后,APP 首页打开变慢,有了版本关系,我们可以首根据整个平台的“版本事件”来排查问题。同时,团队也很快可以找到相应的代码变更,然后进行 review 及修复。

  3. 上图中,当 A 服务是一个集群时,我们还可以将部署的目标机器与版本号关联起来了。这样,团队就可以轻松的知道,哪台机器部署了哪个版本。

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

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

后记

版本号和其它数据的关系的价值,笔者认为被大大低估了。希望本文能给 DevOps 平台设计者带来不一样的想法。


图片地址:https://pixabay.com/zh/photos/road-drone-aerial-trip-travel-4564817/

相关 [devops 平台 设计] 推荐:

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

- - IT瘾-dev
在设计 DevOps 平台时,笔者认为版本号的管理是一个绕不开的课题. 可是,行业里似乎很少人提这个事,笔者觉得要谈一谈,所以就有了这篇文章. 一万个人的眼里有一万个“版本号”. 笔者这三年在同一家公司里,换岗换了四个团队. 团队的成员组成各异,有的团队都是在大型跨国企业跳槽过来的,有的团队大部人都是刚毕业的.

谈DevOps支撑平台实施收益和价值02(10.21)

- - 人月神话的BLOG
在9.18日自己谈过一篇DevOps平台实施收益和价值的文章,在当时主要提到了以下三点. 企业研发管理过程的标准化和规范化. 协助企业进行微服务架构转型的关键支撑. 今天准备进一步来扩展谈下里面的一些关键内容. 记得在几年前自己的一个朋友,原来是做工程设计咨询的,但是在规划设计项目中逐渐发现了有不少的信息化软件开发需求,刚开始的时候走的全部外包但是发现不好管理和持续.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

DevOps,你真的了解吗?

- - IT经理网
与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少. 根据CA的一项 调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作. DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后.

DevOps的“定义”:DevOps究竟要解决什么问题?

- - InfoQ - 促进软件开发领域知识与创新的传播
近些年来,DevOps 在我们身边出现的频率越来越高了. 各种大会上经常出现 DevOps 专场,行业内的公司纷纷在都招聘 DevOps 工程师,企业的 DevOps 转型看起来迫在眉睫,公司内部也要设计和开发 DevOps 平台……这么看来,DevOps 似乎无处不在. 可回过头来想想,关于 DevOps,很多问题我们真的想清楚了吗.

你的团队里没有DevOps文化?

- Quantum - LinuxEden开源社区-Linux伊甸园
本文是从 Do you have a DevOps Culture. 全球很多的系统负责人和程序开发者都在 撰写 、 聚会 和 讨论 关于DevOps的事:如何能更加有效的协作、让我们更快的创造商业价值. 阅读全文 | 邮件推荐 | 评论回复.

再谈DevOps实践和价值(12.11)

- - 人月神话的BLOG
今天再谈下DevOps过程实践和实际的收益价值问题. 对于DevOps先引用网上的一段总结如下. 这里我们先分析一下DevOps是什么. 大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化,其实这样理解很片面. 其实我们不难从Patrick提出DevOps的过程得出结论,DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应,也就是DevOps = Dev Agile Ops Agile.

2019十大最佳DevOps工具

- - IT瘾-tuicool
【编者的话】DevOps落地重要的一方面是选好工具集,本文介绍了最流行的DevOps工具. 开发和运维的集成翻开了软件开发的全新篇章. 如果你还是DevOps的新手,或者正在寻求改进已有流程的方法,那么第一道关卡就是调研哪些工具最适合你的团队. 本文整理了工具列表,为大家选择所需的工具提供详实的参考信息.

平台型产品的设计思路

- - legene的用户体验设计
简单的说,自己不干,而是提供一个平台,让别人去干的产品. 比如淘宝就是一个平台,它自己不卖东西,而是让买家和卖家在这里交易,它提供帮助、服务和监管的作用. 很多人可能觉得淘宝、天猫的设计逻辑并不复杂,但其实你看到的只是产品的一小部分,即面向买家C(Customer)的部分. 面向卖家B(Business)的部分则要复杂的多,当然还有面向开发者D(Developer)的(比如淘宝开放平台).