我们是否应该在每次成功构建CI后标记SVN回购？

SVN中的标签很便宜。它们是否足够便宜，使我们能够标记从CI框中弹出的每个成功构建（TeamCity，如果这有什么区别的话）？

我的答案是否定的。这不是SVN特定的，只是特定于良好实践

CI版本不应增加版本号或版本号-它们只是一个健全的检查，以确保所有版本都（嘿，它可能不会运行）。标记CI构建绝对没有意义

编辑：

我们的QA部门从CI框中选择下一个可用版本

您的QA部门不应该接触CI版本，相反，他们应该使用发布质量版本，这通常比CI版本对他们做的更多（即在适当的情况下插入版本号，在发布模式下进行编译，而不是调试等）。请记住，CI构建可能会编译，但它们可能是一堆垃圾，这取决于已签入源存储库的内容。
这听起来像是你所说的CI构建应该被称为构建，因为它是你正在做的唯一一个。整合一套好的构建是一项工作，但值得付出努力，关于这一点，有很多教程和白皮书，投入一些时间阅读，然后在QA部门每次说出“CI构建”一词时给他们一个耳光（因为这些构建应该只供开发人员使用）

---

进一步编辑：

一些人评论道：“为什么CI构建不能保证发布质量？”。我会尽量简明扼要地回答这个问题，而不会把这个问题变成一个不适合这样做的讨论。首先让我说，当然CI构建可以是高质量的。如果你能做到这一点，那么给自己更多的权力，给自己一枚奖章。如果您属于这一类，那么我猜您属于一个代码库变化缓慢的小团队

引述：

通常的做法是通过每次提交到存储库来触发这些构建，而不是定期安排构建。在快速提交的多开发人员环境中执行此操作的实用性是，通常在每次提交后触发一个较短的计时器，然后在计时器过期时或自上次生成以来的较长时间间隔后启动生成

并引述：

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

他们都没有说CI构建不应该是发布质量但他们也没有说应该这样。

当在一个规模合理的团队中工作时，在同一分支下工作，很快就不可能在每个CI构建中实现发布质量。CI构建总是在签入后的一小段时间内启动，不能保证团队成员实际完成了签入，或者当计时器计时结束并且构建启动时，其他人还没有启动

要记住的另一个想法是，当在一个更大的团队中工作时，常规做法是在开发分支上进行CI构建，而发布/QA质量构建是在发布或QA分支上完成的。这使开发团队能够在不污染QA将要测试的构建的情况下继续实现特性——当特性完成后，它们就会合并到QA团队从中获取其构建的分支

我希望这能解释我对QA团队不使用CI构建的评论。任何进一步的讨论都应该在某地或其他地方进行。

---

由于Subversion在每次提交的全局修订号中基本上都内置了标记，因此不需要这样做

---

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

标记每个构建的回报是什么？标记通常用于突出显示项目历史记录中的“特殊”/“重要”点，并且通常是静态/只读的。许多标签会增加更多的混乱，使您很难找到您想要的内容。当我们进行构建时，我们的QA部门会从CI框中选择下一个可用的构建。然后，他们会花一些时间手动测试它，并在将来的某个时候说“是的，build 1.2.3.4适合生产”。我们需要一种在源代码管理中识别版本1.2.3.4的方法。您知道版本的确切版本。为什么需要标记？还有其他一些内置标识符可以唯一标识生成。。您可以使用修订号/变更集id/共享程序集版本（随着每个版本的增加而增加）为什么CI版本不能具有发行版质量？每个版本都应该具有发行版质量-可能可交付。但并没有很好的理由标记每个构建。@Ivo，@rarous，我添加了进一步的编辑来解释我的意思。简言之，这一切都归结为什么是实用的，什么是不实用的。