构建管理/持续集成最佳实践

您的团队如何处理构建？
我们使用Cruise Control,但是(由于缺乏知识)我们面临一些问题 - SVN中的代码冻结 - 构建管理
具体来说,当代码不断被检入时,如何使特定版本可用？

通常,您能否讨论在发布管理中使用的最佳实践？

我非常惊讶这不是重复,但我找不到另一个.

好的,这是交易.它们是两个独立但相关的问题.

对于构建管理,关键点在于您应该拥有一个自动,可重复的构建,从头开始重建整个软件集合,并一直到您的可交付配置.换句话说,你应该每次都有效地建立一个候选版本.许多项目并没有真正做到这一点,但我已经看到它燃烧了人们(读"被它焚烧")太多次了.

持续集成表示,每当代码发生重大变更事件(如签入)时,应尽可能重复此构建过程.我已经完成了几个项目,每晚都会变成一个版本,因为代码足够大,需要花费几个小时来构建,但理想的是设置你的构建过程以便有一些自动机制 - 就像一只蚂蚁脚本或make文件---只重建受更改影响的片段.

您可以通过某种方式处理提供特定版本的问题,从而保留每个构建的所有受影响工件的确切配置,因此您可以将可重复构建过程应用于您具有的确切配置.(这就是为什么它被称为"配置管理".)通常的版本控制工具,如git或subversion,提供了识别和命名配置的方法,以便可以恢复它们; 例如,在svn中,您可以为特定构建构建标记.您只需要保留一些元数据,以便了解您使用的配置.

你可能想阅读一本"实用版本控制"书籍,当然关于CI和Cruise Control在Martin Fowler网站上的内容是必不可少的.

看看持续整合:最佳实践,来自Martin Fowler.

好吧,我在一年前找到了一个相关的帖子,我参加了.您可能也觉得它很有用.这就是我们如何做到的.

将帖子

我们使用Cruise Control作为集成工具.我们只处理trunk,这是我们案例中的主要Subversion存储库.当有可能发生复杂的冲突时,我们很少会为新的故事卡拉出一个新的分支.通常,我们为版本发布提取分支并从中创建构建并将其交付给我们的测试团队.同时我们继续干线工作,等待测试团队的反馈.一旦测试完毕,我们就会从分支创建一个标签,这在我们的案例中逻辑上是不可变的.因此,我们可以随时向任何客户发布任何版本.如果发布中存在错误,我们不会创建标记,我们会修复分支中的内容.在将所有内容修复并由测试团队批准后,我们​​将更改合并回主干,并从特定于该版本的分支创建新标记.

所以,我们的想法是我们的​​分支机构和标签并没有直接参与持续集成.将分支代码合并回主干会自动使该代码成为CI(持续集成)的一部分.我们通常在分支机构中针对特定版本执行错误修正,因此我认为它并不真正参与CI过程.相反,如果我们开始在一个分支中开始创建新的故事卡,那么我们就不会将该分支保持太长时间.我们尽快将它合并回主干.

准确地说,

当我们计划下一个版本时,我们手动创建分支

我们为发布创建一个分支,并修复该分支中的错误以防万一

在获得所有好处之后,我们从该分支创建一个标记,这在逻辑上是不可变的

最后,如果有一些修复/修改,我们将分支合并回主干