使用 Jenkins、内部版本号和 svn 修订版管理程序版本答案

【问题标题】：Managing the program version with Jenkins, build number and svn revision使用 Jenkins、内部版本号和 svn 修订版管理程序版本
【发布时间】：2016-05-03 08:40:06
【问题描述】：

我们目前正在将 Jenkins 用于 CI。我选择了 Jenkins，因为我们在许多不同的平台（linux、windows、嵌入式系统）上部署了许多程序。这对我们有很大帮助，但我们很难正确管理程序版本号。一些开发人员使用他们自己的符号，我希望将所有内容标准化...

我考虑了两个基本版本号：

#define MAJOR  1
#define MINOR  0

我想增加两个额外的数字，比如：

#define BUILD_NUMBER 66
#define SVN_REVISION 77

但我遇到了问题：

首先，例如程序 FooServer 依赖于 X 库（我们开发的），每个库主干可能有不同的 SVN 版本。那么，如果应该包含一个 SVN 修订号，使用 FooServer 修订号或项目 SVN url（程序 + 依赖项）的最高 SVN 修订号是否更相关？

其次，我考虑使用 Jenkins BuildNumber 变量将程序与 Jenkins 中的（存档）作业链接起来。我只是想知道它是否真的足够相关。

此外，我需要在版本字符串中添加一个信息，以区分夜间快照构建（不是开发人员构建）和在生产中部署的版本。也许通过添加附加信息？

最后，这些#define 当然会存储在构建时生成的 cpp 头文件中，并且永远不会提交到 repo。为了防止开发人员从他们的工作站构建发布（我们遇到了太多这样的问题）。在 SVN repo 上，头文件仍处于开发阶段：

#define MAJOR 1
#define MINOR 0
#define BUILD_NUMBER X
#define SVN_REVISION dev

嗯，欢迎您的体验。我们团队的开发人员不希望有太多的约束，但另一方面我需要建立一些符号规则以提高鲁棒性。

【问题讨论】：

关于您的第一个问题：是否所有程序和 lib 代码都驻留在同一个存储库中？
大部分，是的。有一些例外，但我们目前正在将它们迁移到同一个 repo 中。
如果所有代码都在同一个存储库中，那么最高修订号就足够了。至少在过去的几年里对我来说已经足够了:-)

标签： c++ svn jenkins versioning

【解决方案1】：

如果所有代码都在一个 SVN 存储库中，则只需使用最新的修订号即可。实际上，如果某些库更改并触发项目的新构建，那么新构建不应与旧构建具有相同的 rev，因为它不一样。

我没有发现在编译中包含内部版本号有多大用处。使用构建日期可以提供更好的构建标识。有一个名为 ZenTimestamp Plugin 的插件，它为您提供了一个 BUILD_TIMESTAMP 变量，以便在您选择的日期格式的脚本中使用。

如果您正在为作业本身的每个构建归档 PDB 之类的事情，构建编号可能仍然对您有用。我将它们存储在其他地方，以 SVN 版本命名，所以它不是真的必要。

您的最后一步是明智的。我们（我工作的公司）也这样做，只是在 SVN 中甚至没有硬编码。

我不知道您如何处理跨平台项目，但我们使用 CMake 生成项目，因此我们只需在配置时生成包含正确值的头文件（#define REVISION dev 等）。这样，Jenkins 构建步骤可以使用 SVN_REVISION 和 BUILD_TIMESTAMP 变量的内容生成 CMake 预加载配置文件。在此阶段添加其他信息很容易，例如是生产版本还是夜间版本。

【讨论】：