DVCS是否会阻止持续集成？

假设有一个由十个敏捷开发人员组成的团队。每天他们每个人都从董事会中挑选一项任务，并对它做出一些更改，直到（直到一天结束）他们已经完成了任务。所有开发人员都直接通过主干签入（Google风格，每次提交都是候选版本，使用功能切换等）。

如果他们使用的是像SVN这样的集中式CVS，那么每当其中一个提交时，构建服务器就会针对其他9个开发人员的工作进行集成并测试其更改。构建服务器几乎将全天连续运行。

但是，如果他们使用的是git之类的DCVS，则开发人员可能会等到完成任务后，再将所有本地提交一起推送到中央存储库。直到一天结束，他们的更改才会被整合。

在这种情况下，SVN团队更加频繁地进行集成，并且比git团队更快地发现集成问题。

这是否意味着DVCS比老式的集中式工具更不适合连续团队使用？你们如何解决这个推迟推送的问题？

免责声明：我为Atlassian工作

DVCS不会阻止持续集成，只要开发人员定期将其远程推送到其自己的分支，并且CI服务器已设置为可以构建已知的活动分支。

传统上，DVCS和CI存在两个问题：

• 集成状态的不确定性 -除非开发人员一直定期与master进行合并并运行构建，否则您不知道合并更改的状态是什么。如果开发人员必须手动执行此操作，则可能不会足够频繁地完成它以尽早发现问题。
• 构建配置的复制和偏移 -如果必须从“主”构建中复制构建配置以创建分支构建，则分支的配置可能会很快与其复制的构建不同步。

在Bamboo中，我们引入了构建服务器检测由开发人员创建的新分支的功能，并能够基于master的构建配置自动为分支设置构建（因此，如果更改masters build config，它也会更改分支配置反映变化）。

我们还有一个称为合并策略的功能，可用于在分支构建运行之前使用master的更改来更新分支，或者将成功构建分支中的更改自动推送到master，以确保尽快对分支之间的更改进行一起测试。

无论如何，如果您想了解更多信息，请参阅我的博客文章“通过持续集成使功能分支有效”

我的小团队在一两年前改用DVCS，而我公司的其他成员也于几个月前效仿。在我的经验中：

• 使用集中式VCS的人们在进行大型项目时仍然倾向于推迟提交。这不是DVCS特有的问题。他们将拥有变更集，这些变更集要等待几天才能提交。最大的不同是，如果他们在此期间的某个时间犯了一个错误，或者计算机崩溃了，则需要花费更多的精力进行修复。
• 我们使用提交工作流，其中每个开发人员都在各自的命名分支上工作，并且只有审阅其代码的人员才可以将其更改合并到头部。这减少了提交导致问题的可能性，因此，当构建服务器生成错误消息时，人们会特别注意。这也意味着其他开发人员可以继续在自己的分支上工作，直到确定要解决的问题。
• 在DVCS上，人们确实倾向于在将代码与头部合并之前花费更多的时间进行编程。因此，它的确会给构建的连续性带来一些滞后。但是，差异并不足以抵消DVCS的优势。

我最近观察到大约19个使用Mercurial over SubVersion的项目（我是一个颠覆性的极客）：开发人员通过在自己的分支上工作并仅在服务器工作几天或几周后进行集成，才开始真正成为个人主义者。这引起了严重的集成麻烦和担忧。

我们面临的另一个问题是持续集成服务器。仅当将提交同步到服务器时，我们才会收到问题通知（例如测试失败）。

马丁·福勒（ Martin Fowler ）似乎写了这句话在他的网站上。

也就是说，我提到的某些项目每天至少进行一次同步，以减少问题。因此，回答您的问题，我确实认为DVCS 可能阻止持续的集成并增加个人主义。但是，DVCS不是直接原因。

不管他们使用的VCS是什么，开发人员仍然负责。

轻声地说，您基于推理的想法非常不稳定。开发人员可能要等到团队/管理/流程完成任务才能完成任务。

以一种或另一种方式（“等待”或“匆忙”），共享干线或隔离分支来进行分支称为分支策略，并且如果您研究在线提供的信息，则会发现选择特定策略与该策略基本无关。 VCS是集中式或分布式的。

说，对于像Mercurial这样的分布式VCS，您可以轻松找到频繁合并的强烈建议：

首先，经常合并！这使得每个人都可以更轻松地进行合并，并且您会更早地发现冲突（这些冲突通常源于不兼容的设计决策）...

通过研究上述建议，可以很容易地发现，这些吸引因素与分发Mercurial无关。

现在，让我们来看一下集中式VSC Subversion的情况。通过研究在线信息，可以在最流行的策略中找到所谓的稳定主干和不稳定主干 -每种策略对合并的频率都有相反的影响。您会发现，人们选择一种或其他方式来做事，甚至都没有注意将VCS集中化。

• ^{我已经看到与集中式VCS发生严重延迟的合并（甚至受到la脚管理的鼓励），并且当团队/管理人员认为这是正确的方法时，经常与DVCS进行合并。我见过没有人关心VCS是分布式还是集中式地决定一种或另一种方式。}

综上所述，这似乎是DVCS阻止持续集成的正确答案？会是沐。

是否分发VCS对此没有实质性影响。

我的经验恰恰相反，使用svn的团队不会持续几天，因为他们正在处理的代码会导致主干无法为其他所有人编译而不会浪费时间进行手动合并。然后在冲刺快要结束时，每个人都会犯错，合并疯狂会发生，事情将被覆盖并丢失，必须予以恢复。CI系统将变为红色，然后将指向手指。

Git / Gitorious从来没有这个问题。

Git允许您在方便时提取并合并其他人的更改，这不是因为其他人检查了某项内容并且您要检入，而是需要20分钟的手动合并时间。

Git还允许您提取其他人的提交，合并代码，然后将工作版本推送给其他人，这样他们就不必根据您的更改来猜测应该合并什么。

像Gitorious这样的人可以通过合并请求作为代码审查的中介者，这使得管理许多分支和许多贡献者变得非常轻松。

设置Jenkins / Hudson来跟踪Git存储库中的所有活动分支也非常容易。当我们从SVN迁移到Git时，我们对CI有了更多的关注，并且对存储库的状态有了更多的反馈。

构建服务器很便宜。只需让您的CI服务器接起您所知道的所有分支机构即可。

Jenkins支持检查多个git存储库，并从单个工作中的任何存储库中获取“最新”存储库。我确信其他工具也有类似的解决方案。

这个旧问题刚刚被标记为新问题的重复，并且由于许多答案都引用了一些过时的想法，因此我认为我应该发布更新的问题。

五年前似乎不太常见的一件事是在将请求合并到主服务器之前，在请求请求分支上运行CI测试。我认为这反映了一个不断变化的态度，虽然合并经常是可取的，分享每一个变革大家，只要你把它，是不是最佳的。

DVCS催生了一种更加分层的集成提交模式。例如，我经常与坐在我旁边的开发人员非常紧密地合作。我们将每天从彼此的分支机构中抽出几次。今天，我们每隔几个小时就通过推送请求请求的更改与另一位开发人员合作。

我们正在对构建脚本进行大量更改。Jenkins在本地将每个PR分支与master合并并运行测试，因此我们以这种方式获得了自动反馈，而不会打扰任何需要全新构建的开发人员。公关准备好合并以在我们的三个开发人员小组之外进行掌握和共享的时间可能会再过大约一天。

但是，如果某人迫不及待地将我们的更改合并到master，因为他们的更改取决于我们的更改，那么他们可以在本地合并我们的dev分支，然后继续他们的工作。这就是许多习惯CVCS的人所想念的。使用CVCS，共享更改的唯一方法是将它们合并到中央存储库中，这就是为什么经常合并更为重要的原因。使用DVCS，您还有其他选择。

我想说DVCS更有利于持续集成。合并对他们并不那么令人讨厌。但是，这确实需要更多的纪律。您应该在本地提交之后进行跟踪，并从基础拉出以进行合并，然后在任务完成时推送（在进行下一个操作之前）。

当我的团队切换到Git时，我们明确地安排了流程，以便将推送与完全在较早的VCS中的提交一样对待，并且可以根据每个人的选择来频繁/不频繁地进行本地提交。这样，无论我们使用的是DVCS还是集中式VCS，CI系统都没有区别。

答案是肯定的，也不是。

这里的区别是直接提交到中央CI查看的中央存储库，然后将更改推送到中央CI查看的中央存储库。您可能会发现的“问题”是DVCS用户实际上可能没有定期执行该推送。

我想说这是DVCS的固有设计功能，并不是为了将您的更改一直推送到中央服务器而设计的-如果可以的话，您最好使用CVCS。因此，答案是在开发人员中实施更好的工作流。告诉他们每晚更改。简单！

（如果您的SVN用户不是每天晚上提交的，请告诉他们-完全相同的问题）。

Git不会阻止持续集成。您基于中继的工作流程是。

这听起来可能违反直觉，但是：如果开发人员在功能分支上工作，则可以鼓励他们在自己的计算机上频繁集成（并要求在提交功能以进行合并之前进行集成）。相比之下，基于主干的工作流程则倾向于较大的提交，因此集成频率较低。

我坚持认为，基于Google风格的基于主干的工作流程与诸如Git之类的VCS相比适得其反，因为它们很容易合并。我建议您改用以下方法：

• 将功能分解得足够小，以至于没有一个需要花一两天的时间才能开发出来。
• 每个功能都是在私有分支上开发的。
• 开发人员经常在私有分支上进行集成（git fetch origin; git merge master）。这样工作时，我通常一天会做很多次。
• 当开发人员提交分支进行合并和审阅时，CI服务器将进行自动构建。合并仅在此通过时发生。

这样就可以实现：小的提交，频繁的集成以及可追溯的历史记录哪些提交属于哪个功能。正确使用分支是Git值得拥有的一切的关键，因此避免分支是一个大错误。

有很多很棒的技术解决方案，例如@jdunay，但对我们来说，这是一个人的问题-就像养成人们经常致力于svn的环境一样，这也是一个人的问题。

对我们有用的是：（将“ master”替换为当前活动的dev分支）

1. 来自主的频繁合并/重新设置
2. 足够频繁地掌握

3. 对引起合并地狱的事物的意识，例如某些重构，并通过交流来缓解。例如：

   • 确保每个人在午餐前都推
   • 在午餐期间执行并推动重构
   • 确保每个人午饭后都拉