使用自动构建系统进行版本控制

Question

使用自动构建系统进行版本控制

c++version-controlbuild-automationversioning

4

我们最近转向了一个自动构建系统（是内部的，不是Hudson或Teamcity）。我们的版本号存储在头文件中，并被一些cpp和资源文件包含。它还被安装程序使用。其格式为"A.B.C.D"，其中：

- A 多年未变 - B 很少更改（主要版本） - C 随着次要版本的更改而更改 - D 当新的次要版本（错误修复）交付给QA时更改

迄今为止，在构建新版本的负责人开始构建之前，手动递增"C/D"（通常是"D"），然后检查更改并开始构建。该版本在该人成功构建应用程序之前保持不变。

自动构建系统的移植自然而然地使我想摆脱手动更改版本号的步骤。

如何处理这个问题？

- 每当进行新的构建时，无论是QA构建还是内部测试构建（即我正在测试我没有破坏任何东西的功能），我是否应该递增D？ - 递增步骤是自动构建系统中的任务吗？ - 在递增之后，我应该提交版本文件吗？ - 如何避免版本控制中有大量的噪音？我不想有大量的“版本递增”提交。 - 如果构建失败怎么办？仍然递增版本并提交吗？

- Idan K

5个回答

1

每当创建一个新的构建（无论是QA构建还是内部测试构建，例如我正在开发某个功能并想测试是否存在损坏）时，我是否应该增加D？

是的，更改您的流程，使D随每个构建（成功或失败）而增加，而不是随每个交付给QA的构建而增加。

有几个构建，有些工作，有些不工作，由于失败的构建与好的构建具有相同的ID，所以无法区分它们，这可能非常令人沮丧。但是如果每次构建编号都增加，即使在同一天或同一小时，您也不必考虑它们了。

构建系统自动递增构建号码（D）即可。

递增后，我应该提交版本文件吗？如何避免我的版本控制中有大量噪音？我不想要大量的“版本递增”提交。

版本控制存储专门用于记录详细噪声。

我会检查版本更新并提交，这可以在SVN中显示合理的标签来说明之前更改所包含的构建版本，让构建系统忽略由构建系统或被识别为版本更新提交的提交。

然后，要查看版本历史记录，您应该使用适当的工具来过滤历史记录以显示您需要的视图，在某些情况下，排除版本提交标签。

如果您选择不为每个构建提交版本号，则最好将版本号保存在单独的文件中，以避免意外更新。

如果构建失败怎么办？还要增加版本号并提交吗？

仍需增加版本号，除非构建成功，否则不会提交版本号。在版本控制之外，您可能会遇到各种故障，这些故障无需记录 - 构建服务器磁盘空间不足，服务器崩溃，编译器在同时构建32位和64位，调试和发布aix，linux和windows构建时出现问题......

- Greg Domjan

0

您可以考虑使用.NET程序集的约定，如class System.Version文档中所述。引用如下：

Build [您的C]: 构建号的差异表示对同一源代码的重新编译。当处理器、平台或编译器发生变化时，可能会使用不同的构建号。

Revision [您的D]: 具有相同名称、主要版本和次要版本号但修订版不同的程序集旨在完全可互换。修订号较高的程序集可能用于修复先前发布的程序集中的安全漏洞的构建中。

- MarnixKlooster ReinstateMonica

0

你打算如何自动化这个过程？我的意思是，什么系统会知道“这个构建是发布版本！”。在我看来，版本号中的所有数字都是相关的。如果下一个发布（D + 1）需要两个构建，那么A.B.C.D+2就是下一个版本吗？听起来有点可疑。如果确实需要在DLL和EXE上有这些信息，我宁愿在版本号之上添加构建号码。

我认为构建号码不是附加到二进制文件的相关信息，除非您从不同的构建中分发版本A.B.C.D的文件（无论如何都不应该这样做！）

我会设置构建服务器将工件（DLL、EXE、MSI、PDB等）存储在一个目录中，该目录的名称包括构建号码和版本号，然后从那里刻录DVD/其他介质。如果您需要从版本回溯到特定的构建，您可以使用此信息，前提是您保留了您的发布存档（建议！）。

- Jörgen Sigvardsson

0

我建议使用autorevision。

您仍然可以保留A.B.C.D格式的标签，并使用脚本创建在构建时生成所需信息的头文件。

- dak180

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Gilbert Le Blanc · Accepted Answer

每次进行新的构建（无论是QA构建还是内部测试构建，即我正在开发某个功能并希望测试是否有任何问题），我是否应该增加D？

Eclipse Foundation添加了一个E元素，即构建日期和时间。我认为这对于内部测试构建是一个好主意。至于QA构建，您可以选择是否使用E。

增量步骤是否是自动构建系统中的任务？

这似乎很合理，但您必须有一种告诉该任务您正在进行哪种构建的方法。

如何避免版本控制中出现大量噪音？我不想有大量“版本已增加”的提交。

将版本控制文件与源代码一起提交。

基本上，您的开发构建过程应按以下顺序进行：

1.从开发源代码构建产品。 2.如果构建成功，则增加版本号。 3.提交源代码和版本控制文件。 4.再次从您的版本控制系统构建产品。 5.如果构建失败，请撤销源代码和版本控制文件提交。

这个测试可以检验你的构建和构建过程。第二次构建不应该失败，但如果失败了，那么就是过程中出现了问题。

你的生产构建过程将从第二步开始，跳过第三步。

如果构建失败怎么办？还是要增加版本并提交吗？

我的 E 是自动递增的。 :-) 对于其他元素 A、B、C 或 D，我会说不要增加。