颠覆与持续集成

Question

对不起,如果这个问题的答案已经存在,我还没有找到它们.

我是一个Web开发团队的成员,我们维护着一个门户网站.发布管理适用于Subversion.这是我在向门户添加新功能时的工作方式:

• 通过复制Trunk创建一个新分支
• 在那个部门发展
• 定期将Trunk中的更新合并到该分支中(我想知道Framework-Changes是否会破坏我的代码,然后再转到UAT/Integration,例如)
• 将分支重新集成到主干中以使其生效

现在我们遇到了持续集成的问题:

• 每X周定期上线
• 计划在不同日期上线的几个分支机构存在
• 每隔X小时,Integration Server会执行Trunk checkout并将所有分支(应明确转到Integration System)合并到其中
• 已合并到每个分支(见上文)的Trunk更新现在生成树冲突

什么是最佳实践？重新集成不适用于合并多个分支,因为只要集成了一个分支,工作副本就不再干净了.但是,必须以某种方式实现持续集成......

如果将Trank更改合并到每个分支中,则会创建不同的修订.但文件应该具有相同的内容并且相同.是不是有一个合并选项说"如果两个新的/更改的文件相同则忽略冲突"？

谢谢你的帮助.

Answer 1

您所描述的不是持续集成,因为以下要求:

每隔X小时,Integration Server会执行Trunk checkout并将所有分支(应明确转到Integration System)合并到其中

Real Continuous integration包括以下步骤:

• 从一个特定分支更新源代码(trunk例如).
• 构建生成可以执行或部署的构建工件的源代码.有时这个阶段还包括运行单元测试和检查.
• 显示构建状态,无论是否成功:绿色或红色.

如果您有多个分支,则意味着您需要为多个分支配置多个构建计划,以便分别为每个分支执行持续集成.

因此,您所描述的内容可能没有最佳实践,因为合并应始终手动执行.这是由于合并冲突造成的.它们经常发生,只能手动解决.持续集成无济于事.

如果你只是与术语混淆并想要执行你所描述的内容,我会说你的开发过程有点缺陷.也许,您不需要同时从多个分支执行合并.您经常提供的所有开发都应集中在一个分支中.大多数情况下,这样的"一个"分支将是主干.

在您的情况下,似乎有价值的开发分散在几个分支之间.那是不对的.一旦您确定某些功能应该包含在即将发布的版本中,它应该集成到一个(可能是父级)分支中,并作为代码库的一部分保留在那里.尽量减少你拥有的分支机构数量.

总结一下,

1. merge all branches从您的流程中排除步骤(这不是自动完成的).
2. 请手动合并.
3. 如果您确定需要始终使用分支,请分别为这些分支配置持续集成.
4. 否则(您不需要一直保留分支,并且一旦开发完成就可以很容易地重新集成到父分支中)将分支数量减少到最小.

祝好运!