SVN中的标签很便宜。它们是否足够便宜，使我们能够标记从CI框中弹出的每个成功构建（TeamCity，如果这有什么不同）？
答案 0 :(得分：8)
我的回答是否定的。这不是SVN特有的，它只是特定的好习惯。
CI构建不应该增加构建版本或版本号 - 它们只是一个完整性检查所有构建（嘿，它可能不会运行）。标记CI构建绝对没有意义。
修改
我们的质量检查部门从CI框中选择下一个可用的版本
您的质量保证部门不应该接触CI构建，而应该使用发布质量构建，这些构建通常比CI构建更多（即已插入版本号）适当的，编译已在发布模式而不是调试等完成。请记住，CI构建可能会编译，但它们可能是一堆垃圾，具体取决于已检入源存储库的内容。
这听起来像你所指的 CI build 应该被称为 build ，因为它是你唯一正在做的事情。将一组好的构建组合在一起是一项工作，但值得付出努力，有很多关于此的教程和白皮书，投入一些时间并阅读它，然后给你的QA部门每当他们说出“CI build”这些词时都会发出嘘声（因为这些构建应仅供开发人员使用）。
进一步修改：
有几个人评论“为什么CI版本不能发布质量？”。我将尝试以简洁的方式回答这个问题而不将其变成不适合SO的讨论。首先我要说的是，CI构建当然可以是发布质量。如果你能够实现这一目标，那么就给自己一枚奖牌。如果你属于这个类别，那么我猜你是一个拥有缓慢变化的代码库的小团队。
引用Wikipedia：
通常的做法是通过每次提交到存储库而不是定期调度的构建来触发这些构建。在快速提交的多开发人员环境中执行此操作的实际情况是，通常在每次提交后触发一个短计时器，然后在此计时器到期时或自上次构建后相当长的时间间隔后启动构建。
持续集成是一种软件开发实践，团队成员经常整合他们的工作，通常每个人至少每天集成一次 - 每天导致多个集成。每个集成都通过自动构建（包括测试）进行验证，以尽快检测集成错误。
这些都没有说CI构建不应该是发布质量。 但他们中的任何一个都不应该说它应该是。
当在一个合理规模的团队中工作时，在同一个分支机构工作时，使用每个CI构建实现发布质量很快就变得不切实际。 CI版本总是在办理登机手续后的一小段时间内启动，无法保证团队成员实际完成了办理登机手续，或者当该计时器结束并且构建开始时，其他人没有启动。
另一个需要考虑的想法是，在一个更大的团队工作时，常规的实践是在开发分支上进行CI构建，而Release / QA质量构建则在Release或QA分支上完成。这使开发团队能够继续实现功能，而不会污染QA将要测试的构建 - 当功能完成后，它们将合并到QA团队从中构建的分支。
<子> 我希望这能解释我对QA团队不使用CI构建的评论。任何进一步的讨论都应该在programmers.stackexchange.com或其他地方进行。
答案 1 :(得分：3)
由于Subversion在每个提交的全局修订号中都有基本的内置标记，因此没有必要。
您通常会标记标记重要步骤，而不是跟踪连续过程。