您如何处理每个Sprint的多个分支/开发人员的集成代码？

42

刚接到一个电话，开发人员对每个sprint中将其故事集成到master分支表示担忧。开发人员所有代码都在自己的分支中，并且在冲刺结束时，他们都合并到一个主分支中。

然后，让一名开发人员（通常是同一位开发人员）负责确保所有内容都与其他开发人员的代码很好地集成在一起（大多数更改都在同一页面上。例如，数据显示故事，数据过滤故事和SLA指标）。

我们如何减轻这种负担并使我们的代码更容易合并在一起？从我的角度来看，让PO或SM以更有效的方式对故事进行优先级排序，以便我们在同一sprint中没有此类依赖关系可能会解决某些问题。其他人如何解决呢？还是这只是过程的一部分？

— 小甜饼
source

18

您是否没有完成持续集成的开发分支？

— Kayaman

13

我在这里与Kayaman在一起，这的最佳实践是实现持续集成。

— RandomUs1r

27

合并日快乐！每当您的问题与The Daily WTF上的问题过于相似时，您就知道自己遇到了麻烦。

— user3067860

尽早合并，经常合并：{编写将失败的最小测试代码（红色），编写将通过（最小）最小的生产代码（重构），重新测试，合并}未完成。

— ctrl-alt-delor

1

首次入住可获胜！永不止息！:-)

— ChuckCottrill

88

如果您使用的是Git，则每个开发人员都将从develop分支转移到自己的功能分支，以确保他们与当前基准的距离不算太远。他们可以每天执行此操作，因此耗时超过两天的任务可以保持同步并合并问题，而它们仍然很小。

开发人员完成工作后，就会创建拉取请求。批准后，将合并到develop分支中。

该develop分支应该始终有工作代码，并准备随时释放。当你真正做一个版本中，您合并develop到master和标签它。

如果您拥有良好的Continuous Integration Server，则它将在签入更改时建立每个分支，尤其是对于拉取请求。如果构建失败或自动测试失败，则某些构建服务器会与您的Git服务器集成，以自动批准或不批准请求请求。这是查找潜在集成错误的另一种方法。

— 贝琳·洛里奇
source

73

重要的部分（仅在您的答案中暗示）是分支应该在准备好后立即合并，通常只有1-5次提交，而不仅是在sprint结束时。每个功能/故事一个分支，而不是每个开发人员一个分支。这要求故事确实很小，即最多需要两天。

— 阿蒙（Amon）

@amon，同意。添加了“功能分支”一词，但尝试使此答案保持较小。关于这一过程，有很多很好的文章会做得更深入。

— Berin Loritsch

5

不要在自己的分支上保持孤立。这就是合并地狱开始的方式。使用主线开发，将正在进行的工作隔离在功能切换或其他运行时配置之后。

— Rob Crawford

3

@Zibbobz我的团队对那些使用显式的“功能分支”，基本上将其视为与develop分支一样，但仅用于与该更改相关的拉取请求和提交。通常，根据必须分开保留多长时间，每隔几天就会有人将变更内容从开发合并到功能中并解决所有问题。这样，合并时分支就尽可能相似。请注意，这仅适用于真正的重大更改

— reffu

9

“隔离功能切换或其他运行时配置背后的工作”您只是通过进入config hell来避免合并hello。“合并地狱”对一个开发人员而言只是一个问题，只需定期同步即可轻松避免，拥有大量临时配置对于所有未来的开发人员来说永远都是地狱。

— 立方

23

我曾在一个团队中工作，遇到同样的问题。我们发现，整合之前花费的时间越少，难度就越小。我知道大多数教持续集成的人都谈论每隔几分钟提交一次，实际上我们大概每小时左右提交一次。

我们还发现仅建房还不够。我们需要一个良好的测试覆盖率级别，以确保我们不会意外破坏彼此的代码。

— 丹尼尔
source

2

这也是我的经验。提交的频率实际上并不重要，但是一旦快速提交，集成/合并提交就可以节省大量的工作量。我曾经在一个项目中，我们有三个不同的开发分支，每个分支都有几个月的工作量。合并它们并不好玩。我从那个错误中学到了很多东西：)

— 阿蒙（Amon）

4

是的-这就是“持续集成”的含义！您正在不断将您的更改与其他开发人员的更改集成在一起！

— Rob Crawford

@罗布，同意。我的发言并不是要暗示持续集成不是连续的。只是我们没有完全实现理想，而接近理想仍然看到了很多好处。

— 丹尼尔（Daniel）

12

保持分支的生命周期短（听起来您已经在执行此操作）。
让您的测试结果说明一切。
不要等待冲刺结束。

您甚至不需要为此订阅TDD。您只需要进行一些测试即可证明您的开发人员的功能正常工作。这些可能包括单元测试和集成测试，但理想情况下将是对关键功能的一对自动化的端到端测试。标准回归包内容。

然后，合并完成后，您可以一起检查自动化测试报告，并验证是否已成功集成所有内容。

我同意其他答案之一，作者说Git PR可以通过让每个开发人员合并自己的作品来解决此问题。

我认为还有一点很重要，可以留到最后一段。我建议您对每晚的构建进行手动测试，而不要等到冲刺结束。开发人员应在功能完成后立即合并，以便尽快对其进行集成，部署和测试。

— 谎言
source

6

别

根据您的语言和您正在编辑的文件，每个开发人员都可能无法在自己的分支上对其进行编辑。例如，在C＃中，我发现最好只有一个人一次编辑任何UI设计器文件。这些是自动生成的文件，因此有时有时会在没有明显原因的情况下移动代码-这对大多数合并工具造成了严重破坏。

这意味着某些故事可能会阻止其他故事，直到完成UI工作为止。和/或，将创建一个新的故事以仅布局UI，而其他故事则实现功能。或者，也许一个开发人员完成了所有UI工作，而其他开发人员实现了该UI的功能。

与此相关的是，如果您知道多个故事都将涉及同一文件，则可能只想避免同时处理它们。不要将它们全部拉入相同的sprint中，或者直到完成一项或多项操作后才开始对它们全部进行处理。

— a
source

老实说，使用的版本控制工具对于成功进行分支和合并至关重要。即使使用C＃代码以及大概的WinForms或WebForms代码，您必须使用的代码通常也不会发生太大变化。如果是这样，也许您需要在玩代码之前做一些模型化。基于XAML的UI也同样稳定，常规代码和中间代码不检查。

— 帐户berin Loritsch

2

@BerinLoritsch WinForms设计器代码的确可以进行很多更改，即使在视觉上进行了很小的更改。我发现代码行本身是相同的，但是顺序却大不相同-尤其是当多个开发人员同时进行编辑时。也许这是VCS工具的问题（我们已经使用了几个，也许我们只是使用了错误的工具），但是对我们来说，稍微改变一下过程要简单得多。

— mmathis

2

@BerinLoritsch我必须至少在这里第二次获得胜利表格（从未使用过网络表格）。Winforms UI设计人员喜欢随机地对设计器文件中的所有代码进行重新排序，以响应表单上某处的微小变化。除非您在每次提交之前手动撤消重新排序（在复杂的表单上可能很容易花费10或15分钟的时间），否则设计器文件的历史记录绝对是无用的，并且如果有2个人同时在表单的UI上工作，将导致来自地狱的合并冲突。锁定通常是一个很糟糕的选择，但是使用Winforms确实是最少的麻烦。

— Dan Neely

@DanNeely，这只是我们团队从WinForms代码迁移过来的原因之一。另一个原因是设计师非常脆弱，而且我们的某些复杂形式无论如何都无法以视觉方式进行编辑。我们最终不得不直接在后面的代码中进行更改-可能是为什么我在那儿不记得太多的动荡。那以及我们使用高密度显示器的用户确实将我们推向了WPF。一个痛苦的过程，学习曲线很高，但最终会得到很好的回报。无论如何，积压中的大多数故事都是针对应用程序的不同部分的。

— Berin Loritsch

@BerinLoritsch在这里也一样。在过去的十年中，Win Forms在我的上一份工作中占了我账单的很大一部分，但我很高兴将来不再碰它。

— Dan Neely

2

避免延迟和大量合并的另一种可能方法是功能标记：使用（理想情况下是动态的）可配置标记保护更改，以防止更改在预期之前变为活动。

这样，您就可以将所做的更改尽早地合并到一个master或联合开发分支中，而不会破坏任何内容。然后，其他开发人员可以将这些更改合并回其功能分支（或相应地对其分支进行基础调整）。

正如其他答案已经指出的那样，这应该与持续集成解决方案结合起来。

功能标记还有其他好处（例如，它们使A / B测试变得容易）。有关更多信息，请参见Martin Fowler的本文。

— 弗洛里安·布鲁克（Florian Brucker）
source

0

我们遵循针对每个功能的单独开发分支的方法，然后将这些分支合并到QA分支，以在集成测试环境中进行测试。

回归和集成测试完成后，我们可以轻松地将准备使用的功能移至发布分支。

如果一切顺利，我们将发布分支合并回主分支。

— Emarshah
source

0

简而言之，提交和合并通常会减少合并冲突的机会，并且将大大减少冲突。另一部分确实是由负责人计划的，这可以进一步确保工作顺利进行。

其他答案给出了有关提交最佳实践的深刻见解，只需遵循这些最佳实践，您就可以减少绝大多数合并问题。几乎肯定有必要进行更多的合并，但是对于规模较小的团队，您的每人分支方法可能效果很好。当然，进入更可扩展的实践并没有太大的伤害！

但是，似乎没有人解决您最重要的问题之一-当您都触及相同的代码区域时该怎么办。在这里，有一位熟悉代码库并可以识别不同任务相关性的领导很有用。如果他们没有安排工作和提交的时间，那么您很可能最终会遇到合并冲突和逐行解决的问题。对于较大的团队来说，组织任务\时间安排要困难得多，但是对于较小的团队，则有可能识别这些冲突任务。然后，主管甚至可以将所有相关任务转移给同一工程师，以完全避免冲突。

— 火星
source