使用 Gradle 和 Jenkins 构建编号的最佳实践答案

【问题标题】：Best Practice for Build Numbers with Gradle and Jenkins使用 Gradle 和 Jenkins 构建编号的最佳实践
【发布时间】：2019-02-06 18:38:45
【问题描述】：

我们有一个使用 gradle、Jenkins 和 Git 的小型 Java 开发环境。我们使用内部构建的 Gradle 插件来增加内部版本号，并使用文件存储当前编号。构建号作为其版本数据的一部分被烘焙到每个构建中。内部版本号文件已签入项目的 git 工作区。

我们现在正在将 Jenkins 添加到 CI 环境中。 Jenkins 有自己的内部版本号，我们可以通过 env var $BUILD_NUMBER 访问它。

我们内部的 Gradle 内部版本号插件的缺点是它使用本地文件，因此多个开发人员的构建不会同步内部版本号。如果我们使用 Jenkins BUILD_NUMBER，那么这与 Gradle 内部版本号插件的顺序完全不同。

这种情况的最佳做法是什么？

【问题讨论】：

【解决方案1】：

如果您声明只有 CI 提供的构建对未来使用有效，那么您似乎必须依赖 Jenkins BUILD_NUMBER。

如果您希望 Jenkins 作业 BUILD_NUMBER 从特定值开始，请执行以下操作：

Manage Jenkins -> Script Console
Jenkins.instance.getItemByFullName("YOUR_JOB_NAME").updateNextBuildNumber(YOUR_BUILD_NUMBER)

【讨论】：

我认为这不适合我们，因为在开发人员/gradle 级别没有内部版本号的协调，因此我们可以让多个开发人员使用相同的内部版本号更新 Git。
对我来说，用相同的内部版本号标记不同的二进制文件不是一个好习惯。看起来它会提供更多的误解而不是利润。你的用例是什么？
实际上在我们公司我们有大约20个版本的特定服务同时在某个地方进行测试。所以我们在某些构建将成为最终发布版本之前使用以下BUILD_TIMESTAMP-GIT_COMMIT_SHORT 编号策略。它有助于在不浏览多个系统的情况下了解正在测试的确切内容以及它的年龄。
因此，如果您使用 BUILD_TIMESTAMP-GIT_COMMIT_SHORT，您的开发/测试构建看起来像“4.5.20180901-ab123ex”，其中“4.5”是 major.minor 版本？你为最终的构建版本做了什么？那是“4.5.${BUILD_NUMBER}”还是其他方案？
我们正在使用发布分支策略 - 分支名称与发布匹配，并且所有构建都与它相关联。对于后续操作，例如部署在我们使用 GIT_BRANCH 和 BUILD_TIMESTAMP-GIT_COMMIT_SHORT 组合的环境中。