每次成功的CI构建后，我们是否应该为SVN存储库打标签？

Question

每次成功的CI构建后，我们是否应该为SVN存储库打标签？

svnversion-controlcontinuous-integrationteamcity

5

SVN中的标签是很便宜的。它们是否足够便宜，使我们能够标记从CI框（如果有任何区别，则为TeamCity）弹出的每个成功构建?

- Steve Dunn

4

如果每个构建都打标签，会有什么回报？标签通常用于突出项目历史中的“特殊”/“重要”点，并且通常是静态/只读的。过多的标签会增加混乱，使您难以找到所需的内容。 - Gishu

当我们进行构建时，我们的 QA 部门会从 CI 盒中选择下一个可用的构建。然后他们会花一些时间手动测试它，并在未来某个时候说“是的，版本1.2.3.4可以用于生产环境”。我们需要找到一种在源代码控制中标识版本 1.2.3.4 的方法。 - Steve Dunn

你知道构建的确切修订版本。为什么还需要标签呢？ - Aleš Roubíček

有一些内置的标识符可以唯一地标识一个构建。您可以使用修订号/变更集 ID/共享程序集版本（每次构建都会递增）。 - Gishu

2个回答

3

由于Subversion在每次提交中都本质上内置了全局修订号的标记，因此这是不必要的。

您通常会标记重要步骤，而不是跟踪连续过程。

- VonC

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

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

- slugster · Accepted Answer

我的回答是不行。这不是针对SVN的特定问题，而是针对好的实践的特定问题。

CI构建不应该增加构建或版本号码——它们只是一个检查所有内容是否“构建”的简单检查（嘿，它可能不能运行）。在CI构建中标记毫无意义。

编辑：

我们的QA部门从CI框中选择下一个可用的构建。

你们的QA部门不应该触碰CI构建，而应该使用“发布质量”构建进行工作，这些构建通常比CI构建做得更多（例如，在适当的位置插入版本号，以Release模式而不是Debug模式进行编译等）。请记住，CI构建可能会编译，但它们可能是一堆垃圾，具体取决于源代码库中检入的内容。
听起来你所说的“CI构建”应该被称为“构建”，因为这是唯一正在进行的构建。组合一个好的构建设置需要一些工作，但这是值得努力的。有很多关于此的教程和白皮书，花些时间阅读一下，然后每次他们提到“CI构建”时都给你的QA部门一点警告（因为这些构建只应供开发人员使用）。

进一步编辑：

有几个人评论说“为什么CI构建不能达到发布质量？”。我会尝试简洁地回答这个问题，而不让它变成不适合在SO上讨论的话题。首先，让我明确一点，当然可以通过CI构建来达到发布质量。如果你能做到这一点，那就更加厉害了，给自己颁发一枚奖章吧。如果你属于这一类人，则我猜测你在一个代码库变化缓慢的小团队中。

引用维基百科的话：

通常的做法是通过每次对存储库的提交触发这些构建，而不是定期安排构建。在快速提交的多开发者环境中实现这一点的实际操作是，在每次提交后触发一个短定时器，然后在此定时器到期后或自上次构建以来较长时间后开始构建。

再引用Martin Fowler的话：

Continuous Integration是一种软件开发实践，团队成员经常集成他们的工作，通常每个人每天至少集成一次-导致每天多次集成。每个集成都由自动构建（包括测试）进行验证，以尽快检测到集成错误。

两者都没有说CI构建不应该是发布质量，但也没有说它应该是。在一个合理规模的团队中，当团队成员从同一个分支工作时，很难在每个CI构建中实现发布质量。CI构建通常在提交后的一小段时间内启动，无法保证团队成员已完成其提交，或者在计时器触发并开始构建时，有人没有开始。

另一个需要记住的想法是，在较大的团队中工作时，一种常见做法是在开发分支上进行CI构建，而在发布或QA分支上进行发布/ QA质量构建。这使得开发团队可以继续实施功能，而不会污染QA将要测试的构建-当功能完成后，它们会合并到QA团队从中获取构建的分支。

我希望这解释了关于QA团队不与CI构建一起工作的评论。任何进一步的讨论都应该在programmers.stackexchange.com或其他地方进行。