我们应该在每次成功的CI构建之后标记我们的SVN回购吗？

Question

SVN中的标签很便宜.它们是否足够便宜,使我们能够标记从CI框中弹出的每个成功构建(TeamCity,如果这有什么不同)？

Answer 1

我的回答是否定的.这不是SVN特有的,它只是具体的好习惯.

CI构建不应该增加构建或版本号 - 它们只是一个完整性构建的健全性检查(嘿,它可能不会运行).标记CI构建绝对没有意义.

编辑:

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

您的质量保证部门不应该接触CI构建,而应该使用发布质量构建,这些构建通常比CI构建更多(即已在适当的位置插入版本号,编译已在发布模式下完成)调试等).请记住,CI构建可能会编译,但它们可能是一堆垃圾,具体取决于已检入源存储库的内容.
这听起来像你所指的CI构建应该只被称为构建,因为它是你唯一正在做的.将一组好的构建组合在一起是一项工作,但值得付出努力,有很多关于此的教程和白皮书,花一些时间阅读它,然后给你的QA部门每当他们说出"CI构建"这些词时(因为这些构建应仅供开发人员使用).

进一步编辑:

有几个人评论说"为什么CI版本不能发布质量？" .我将尝试以简洁的方式回答这个问题而不将其变成不适合SO的讨论.首先我要说的是,CI构建当然可以是发布质量.如果你能够实现这一目标,那么就给自己一枚奖牌.如果你属于这个类别,那么我猜你是一个拥有缓慢变化的代码库的小团队.

引用维基百科:

通常的做法是通过每次提交到存储库而不是定期调度的构建来触发这些构建.在快速提交的多开发人员环境中执行此操作的实际情况是,通常在每次提交后触发一个短计时器,然后在此计时器到期时或自上次构建后相当长的时间间隔后启动构建.

引用Martin Fowler的话:

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

这些都没有说CI构建不应该是发布质量.但他们中的任何一个人都不应该这样说.

当在一个合理规模的团队中工作时,在同一个分支机构工作时,每个CI构建实现发布质量很快就变得不切实际.CI版本总是在办理登机手续后的一小段时间内开始,无法保证团队成员实际完成了办理登机手续,或者当该计时器结束并且构建开始时其他人没有启动.

需要记住的另一个想法是,在更大的团队工作时,常规的实践是在开发分支上进行CI构建,而Release/QA质量构建则在Release或QA分支上完成.这使开发团队能够继续实现功能,而不会污染QA将要测试的构建 - 当功能完成后,它们将合并到QA团队从中构建的分支.

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