您的构建和发布步骤是什么？何时增加内部版本号？

Question

尽管要求很简单，但我在定义和自动化构建过程时遇到了麻烦：

1. 每个版本都应该有一个唯一的版本号。
2. 每个标记的版本都应该是可重现的

我有什么：

• C++、Red Hat Enterprise Linux 5.x、Subversion 开发环境。
• 构建机（实际上是虚拟机）
• 一个 version.h 文件，其中 #defines 用于主要、次要和内部版本号。
• 增加 version.h 版本号的脚本。
• 一个 rpmbuild 规范文件，用于导出标记的 Subversion 源、构建和制作 rpm 安装程序包。

问题：

• 假设每个项目有多个开发人员，应在何时增加内部版本号并签入 version.h 文件？造机？某种颠覆钩子？预构建还是构建后？

提前感谢愿意花时间分享构建过程经验的人。

-埃德 Linux新手。前 Windows C++/.NET 开发人员。

Answer 1

为什么不修改您的构建过程，使其从存储库中获取最新的修订号并将其用作构建号？

假设 svn 包含了构建产品的所有元素，这应该为每个潜在的不同构建提供一个唯一编号，并且可以轻松匹配构建时代码库的状态.如果有其他元素会随时间变化，您可以添加另一个连接到修订号的项目 - 可能是日期/时间值。

您永远不必担心手动增加它，因为每次开发人员提交时，他们都会自动增加修订号。

Answer 2

不要将内部版本号直接存储在您的文件中，使用 subversion 修订号（或其他一些单调递增的值，如日期/时间）作为构建标识符。过去，我使用了 date -u +"%Y%m%d%H%M%S" 的值，因为我们使用的是 CVS 而不是 SVN。

Answer 3

我们有多达 40 多名开发人员组成的团队为我们的产品添加代码。每个开发人员将他们的更改提交到产品的中心位置。这形成了代码提交的有序列表。然后，脚本会根据上次发布的配置和当前轮次中任何先前提交的更改将每次提交并集成到测试版本中。每次代码提交编译后都会运行单元测试，本轮添加的任何验收测试也会运行。每天结束时，都会针对不断发展的构建运行单元测试和回归测试。

每周两次，提交的代码更改列表被打包，这成为产品的新发布配置和代码库更新。