如何不重新构建即可将预发布构建升级至生产环境并嵌入新版本号

核心解决方案 #

行业通用做法是采用双版本号体系拆分管理：

• 二进制文件内置不可变构建版本号，格式为主版本.次版本.修订版.构建流水号，构建完成后永久不变，唯一作用是做产物溯源，不需要带ci/rc这类环境标识。
• 包/容器的外层发布版本号遵循语义化版本规范，可根据所处的feed层级增加/修改/去掉ci/rc后缀，这个版本号仅作为包的对外标识，不需要和内置的二进制版本号完全一致。

针对你提出的三个具体问题：

• 是否意味着我们可以直接将1.2.3-ci-xyz从低层feed向高层feed升级，不需要重新打包更换版本号？

完全可以。ProGet原生支持包提升能力，默认就是直接同步原包到高层级feed，不需要修改包内容也不需要重新构建。如果团队需要按环境区分版本标识，直接给包打对应标签即可，不需要改动包本身的版本号。

• 若1.2.3版本的包内部包含1.2.3-ci-xyz版本的二进制文件，是否不符合规范？

不属于违规情况。只要在包的元数据或者发布说明里明确标注内置二进制对应的构建版本，保证可溯源即可，目前几乎所有中大型团队的发布流程都采用这套逻辑，核心是为了避免重复构建带来的产物不一致风险。

• 我们是否应该在构建时就直接使用三位版本号，去掉ci/rc这类后缀？

不需要。ci/rc后缀可以快速标识包所处的测试/发布阶段，非常适配多feed的管理场景，你只需要把这类后缀放到包的外层版本号里，不要内置到二进制文件中即可。

内容的提问来源于stack exchange，提问作者Max Cascone