为了减少沟通协作时不必要的摩擦成本，加快效率，我们有必要构建一套简单，清晰的制品版本确定和迭代的流程。
1. 前言
一直以来，我们的版本管理都是相当随意的。规范和共识的缺失，大量的人工操作造成的不确定，导致研发，测试，运维团队之间的协作过程中，往往需要反复确认彼此之间对于每个发布出来版本的理解是否一致，造成大量的摩擦成本。
为了减少沟通协作时不必要的摩擦成本，加快效率，我们有必要构建一套简单，清晰的制品版本确定和迭代的流程。
注意，本文讨论的是流程，而非被争论了无数次的 X.Y.Z这样的版本号含义，以及每次更新应该修改哪个版本号这种当下ROI非常低的问题。
2. 思路概览
总体上来说，一个制品的版本号分为 alpha，beta，release三类版本。
- 制品发布版本必须以 alpha版本开始，以 beta或release结束。
- alpha版本只能由机器打包而来。beta版本只能由 alpha版本 Prormote(提升, 进阶) 而来。
- release版本则只能由beta版本 Prormote(提升, 进阶) 而来。
所以三者之间的关系是： alpha版本 >>> beta版本 >>> release版本 。 实行这样的单向迭代。
3. 遵循的最佳实践
依据【DEVOPS】最佳实践和指导思想 中的，大概有这么几条：
- “只生成一次制品”
- “唯一可信任源”
- “一切皆版本控制(配置管理)”
- 工具的连通性
其它几条准则：
- 不允许本地打包，先提交再打包。提交之后进行界面化打包 。 “版本迭代非常快，每天可能要打好几个版本”，这并不能算理由，在我们的流程下，你哪怕一天打包100次，那我也会都给你存放起来。供其它使用者挑选。（如果担心存储的问题，请放心，我们会在何时的时候进行定期删除）
- 打包过程中产生的元信息，应该是浏览器前端界面可查，也应该是可以命令行可查。（例如：java -jar xxx.jar -DVersion）。样例图参考VS Code：
4. 实现
直接来一个表格对比：
| 版本类别 | 来源 | 对应禅道操作 | 涉及人工操作 | 范例 | 范例说明 |
|---|---|---|---|---|---|
| alpha | 由机器拉取代码库中的代码进行自动化集成打包生成 | “新建版本” | 1. 输入版本说明性信息 2. 点击"打包"按钮 | XXX-2022050716-alpha（版本号完全由机器自动生成） | 1. XXX为标志性前缀，保持唯一，望文知意。 下同。（注意：这个名字要和禅道里的产品或项目中之间存在"简单推导"的联系，方便之后自动同步——例如这边打包，那边就在禅道中自动创建一个版本 ; 这边将alpha版本提权为beta版本，禅道那边对应创建一个发布） 2. 2022050716 粒度到 小时，由机器打包时刻自动生成。如果小时都重复，直接认定为同一个版本。 3. 这个版本是从代码库由机器自动化打包而来，将由测试人员进行部署验证。在最终的制品出去前，这个版本号是最多的，每次机器打包得到的就是 alpha版本。 4. 自定义段内部使用 _ 分隔（例如XXX_YYY）; 段与段之间使用 - 进行分隔。 4. 这个版本也是之后做过期制品清理时候的重点区域。 |
| beta | alpha基础上，经过测试人员验证认可，再由负责人进行Prormote(提升, 进阶)而来。 | “发布” | 1. 选择待提升的alpha版本 2. 输入X.Y.Z版本号 3. 点击"进阶"按钮 | XXX-0.0.1-beta（人工指定中间的 0.0.1 版本号 ） | 1. XXX。说明见上方。 2. 0.0.1，由人工指定而来。 3. beta版本。这类版本只能由上面的 alpha 版本 Prormote(提升, 进阶)而来，在经过各方认可之后，将某个已经存在于制品库中的alpha 版本提升了beta版本，开始对外提供内部测试使用。 3. 点击"进阶"后，自动化流程将会把对应的alpha版本复制一份，更名为对应的beta版本，同时会记录两者的关系。 |
| release | 在 beta 基础上，经过内测验证认可，由产品经理进行Prormote(提升, 进阶)而来 | “发布” | 1. 选择待提升的beta版本。 2. 点击"进阶"按钮。 | XXX-0.0.1-release （完全由机器自动生成，无人工输入性操作） | 1. 基本同上。这类版本只能由上面的 beta 版本 Prormote(提升, 进阶)而来 2. 这里不允许出现输入的情况，直接选择版本点击提交，自动化流程将会把对应的beta版本复制一份，更名为对应的release版本，同时会记录两者的关系。 |
最后做一下界面化操作展示：（界面秉承越简单越好。用户需要输入的越少越好，最好不需要输入（默认值都算输入内容））
-
alpha 版本打包
-
beta版本打包
-
release版本打包
5. 结束语
很多时候，当聊到DevOps建设时候，一般不会过多提及配置管理这一项。
但这不是代表其不重要，恰恰相反，相关方是已经假设你做好了这一项得，因为配置管理属于基础条件，如果配置管理你要是做不好，那DevOps后面的部分你就没有继续做的必要性，付出的努力得不偿失。
可是，还有一些实践常常被人们所忽视，但这并不代表它们已经被淘汰或者是不那么重要了。恰恰相反，它们同样是 DevOps 能够发挥价值的根基，配置管理（Configuration Management）就是其中之一。它的理念在软件开发过程中无处不在，可以说是整个 DevOps 工程实践的基础。
对传统行业来说，全流程可追溯的能力从来不是可选项，而是必选项。像最近流行的区块链技术，除了发币以外，最典型的场景也是全流程可追溯。
6. 补充 - 思路来源
其实上面的规范形成，其实参考了不少内容，但启发最大的还是下面这张非常有名的DevOps流程图：
