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

Question

尽管有简单的要求，但我无法定义和自动化构建过程：

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

我有什么：

• C ++，Red Hat Enterprise Linux 5.x，Subversion开发环境。
• 构建机器（实际上是虚拟机）
• 带有#defines的version.h文件，用于major，minor和buildnumber。
• 用于递增version.h buildnumber的脚本。
• 一个rpmbuild规范文件，用于导出已标记的Subversion源，构建并生成rpm安装程序包。

问题：

• 假设每个项目有多个开发人员，什么时候应该增加内部版本号并签入version.h文件？构建机器？某种Subversion钩子？预建或后期制作？

感谢那些愿意花时间与构建流程分享经验的人。

-Ed Linux新手。以前的Windows C ++ / .NET开发人员。

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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