从树干或分支发布？

Question

我们最近（最近2个月）开始使用TeamCity进行部署。这让我们了解了很多关于实际使用SC，陷阱以及在一个有多个项目的团队中工作的事情。但是，我们仍然不清楚如何最好地使用树干，分支和标签。

我们目前的流程是：

• 要求工作单位。
• 为开发人员创建了新分支。
• 在分支中完成开发后，主干将合并回分支，以确保包含最近的更改。
• 此时分支已准备好进行测试，这就是我们的不确定性开始的地方！

我听说其他开发人员说我们应该只从主干发布，而且我确信在发布到生产时这是真的。但是，在分支准备好进行测试的阶段，我们应该合并回主干然后释放到我们的测试环境，或者我们应该这样做是不合适的？

我考虑的另一种方法是只有一个名为TEST的分支，然后总是从那里合并并释放到测试环境，但这种方法也许存在隐藏的陷阱。

请问关于这个主题的一些指导/建议吗？你怎么做的？

我不会在这篇文章中提到标签的主题，因为据我所知它可能会使问题复杂化。

提前致谢 dotdev

Answer 1

我发现在一个分支上强制所有开发都会迫使开发人员小心并考虑所有工作。我已经看到使用每个功能分支，但我总是发现它有问题：

• 我和母鸡一起玩很多时间。 “您是否签入了更改？”，“您是否已将更改发送到主干”，“您是否一直在使您的分支机构了解最新动态在主干“。我宁愿做实际的CM工作而不是纠缠开发人员。
• 始终将最后一分钟代码传递到主干，导致合并问题。你认为你已经准备好发布了，突然在发布日期前两天涌入了大量的工作。
• 在分支机构上工作的一个想法是，它允许您选择要发布的内容。您可以使用功能 A ，功能 B 和功能 C ，然后决定是否只发布其中一个功能，其中两个他们，或者他们三个！问题是这些功能并不是彼此独立的，您最终可能会同时发生多达50个或更多分支。合并从未像理论上那样顺利。
• 说到合并：合并是发展中最粗糙，最可怕的方面。它充满了危险，大多数开发人员都很擅长。

如果所有开发人员都在一个分支上工作，那么就会停止合并，因为没有任何东西可以合并。开发人员从不不知道某人的变更，因为它在分支机构中。开发人员将保持彼此一致。是的，你失去了挑选和选择功能的能力，但这最好在冲刺之前完成。

那么，我从行李箱中释放？不，我从分公司发布。您将在下一个版本中完成大部分开发工作。现在，它只是错误修复，你只需要一两个开发人员来测试测试中发现的错误。

这是您创建发布分支时的情况。大多数开发人员将继续使用 trunk （或任何你称之为的），并且发布中发现的错误在分支上得到修复。当您发布时，您可以标记并释放分支。如果您需要制作中间版本以修复错误，可以使用相同的分支。

例如：我们在1.2版本的trunk上工作。当我们完成功能完成的工作时，我将创建一个版本1.2分支。现在，版本1.2上的所有工作都在分支上，我未来发布的工作（可能是1.3）将继续在trunk上运行。当我们完成版本1.2的工作时，我们标记分支并从分支发布。

版本1.2中发现的错误迟早需要修复。 Trunk已经是1.3了。但是，我们只是在1.2分支上进行错误修复，然后从那里做1.2.1。

有时我需要功能分支。例如，我有一个功能需要一段时间才能完成，并在将来实施。在这种情况下，我将创建一个功能分支，并允许开发人员处理它。但是，开发人员必须继续将父分支合并到该功能分支中，以跟上所有更改。并且，当他们完成该功能的工作时，我们将父分支合并到功能分支中，测试并确保一切正常，然后将功能分支合并到父分支中，并确保父分支与功能分支匹配。

所以，回顾一下：

• 我们作为一个团队一起在 trunk 上完成所有工作。
• 当我们到达一些神奇的神秘点（功能完整或最后一个冲刺）时，我们会分支到发布分支。
• 一些 future 版本的主干上继续工作，而发布分支用于下一个版本。
• 当发布工作完成后，我们将从分支机构发布并标记。
• 我们不是教条主义者。有时我们会做功能分支。也许，如果你有一个非常小的开发团队，你可能不会在发布时分支。你只需从主干中释放出来，如果需要制作补丁，你可以在发布点进行分支并制作补丁。

重点是我们在不必要时尽量避免分支，并将合并保持在最低限度。我不关心合并算法有多棒，或者合并是多么自动化，合并是一个草率的过程，很少有人知道如何正确地做到这一点（或者至少要努力正确地做到这一点）。

创建一个分支就像创建一个分支：一旦你创建一个分支，你必须观察它并倾向于它，并确保它没有麻烦。

Answer 2

以下是我的建议：

1）在Trunk分支上进行所有开发并将其用于测试。我假设您有多个功能/错误同时处理。我会避免为每个功能创建单独的分支，除非您经常合并从主干到功能分支的更改。

2）准备好发布后，在此时从Trunk创建一个新的RELEASE分支。将分支部署到QA / Staging环境以进行测试。

3）开发人员可以开始处理新功能，并在创建RELEASE分支后开始检入Trunk的更改。测试期间发现的任何回归问题将首先在RELEASE分支中修复，然后合并回MAIN。

4）然后，任何对RELEASE分支中代码的更改都将被推送到QA / Staging进行进一步测试。

5）一旦发布完成，生产中发现的任何错误都将在RELEASE分支中修复并热修复为Prod并合并回Trunk。

我建议为每个RELEASE创建一个新分支，然后定期删除旧的RELEASE分支而不是使用标签。

所以我的建议是始终从RELEASE分支发布到生产。由于您使用的是teamcity，因此您还应考虑创建持续集成构建（即每次签入时构建项目）