在持续交付中构建版本控制

Question

关于持续交付中的版本控制,我有一些具体问题.我想我了解全球工作流程或多或少是这样的:

1) Code
2) Push to version Control
3) Continuous Integration (unit, integration and end-to-end auto testing)
4) Artifacts deployment

版本控制怎么样？如何管理构建版本？

假设我们正在开发一个基于Maven的语义版本项目:major.minor.build.

当开发人员提交对VCS的更改并且CI服务器执行构建时,CI服务器是否应增加构建版本并在VCS中创建标记？

这个构建版本是否存在于源代码中？如果是这样,在每次推送到VC​​S之后,开发人员应该更新项目,因为CI服务器在项目上提交了更改(版本增量).

我有点困惑,我想以实用的方式理解CD工作流程.

Answer 1

一般来说,你应该:

1. 手动管理的版本号.
2. 任意数量的"参考"数字.

如果你关心semver或者你必须提供其他工具/库的兼容性信息,第一点是至关重要的.只有你能分辨出一个新的"发布"是否会破坏任何东西 - 最流行的指示系统遵循semver版本规则.

第二点("参考"号)对您来说可能重要,也可能不重要.您通常不需要多个CI/CD版本的版本号(每个流行的CI/CD服务都有一个构建版本号ID,它指的是特定的"构建").这个数字的要点是,如果需要,您可以快速检查工件的相关CI/CD构建/日志.

如何合并两个(或更多)部分？

拥有单独的"版本"和"构建"数字并不罕见.事实上,每个iOS项目默认都有.在这种情况下,您手动管理"版本"号码,并自动管理单独的"构建"号码.构建号可以是工件的名称,也可以在有人检索--version二进制信息时打印(例如:$ brew info- >0.9.5 (git revision 18c48; last commit 2015-11-02)

或者,您可以向semver(x.x.x.BUILDNUM)添加新组件,使用semver 的最后一个组件(x.x.BUILDNUM- 如果您有严格的增量,我不建议这样做BUILDNUM)或者只是在工件名称中包含"build"编号.

这些都是可能性,你必须选择最适合你的情况.您必须定义这些数字的含义并决定数字的呈现位置(例如,它应该是--version呼叫的一部分还是应该只是文件名的一部分).

编辑:反思您的问题"应该CI服务器增加构建版本并在VCS中创建标记吗？" - 我永远不会推荐这个.CI服务器也可能存在问题,您永远不应该从CI流程修改代码.意外覆盖(例如强制推动)某些事情可能非常危险.这就是为什么最好只使用CI/CD服务公开的Build Number.