以“敏捷”的节奏维持发布/分支？

Question

我们的软件产品能够根据客户的需求和更一般的路线图发展。

因为我们处于SCRUM项目环境中，所以非常重要的是一个新功能进入产品，然后我们面临以下选择：

• 在已经发布的分支中实现此功能（当然不是分支的重点）
• 建立一个新的分支 - 但是我们每三个星期就有一个分支，而且它不再是可以管理的了

不发布新功能不是一个选项，客户不希望等待长期里程碑计划来获得他们想要的功能，并且在客户端模块中移动功能并不总是不可思议 - 有时我们需要改变产品的核心......

鉴于这些限制，有没有人对良好做法有任何反馈？

Answer 1

我建议在我当前的环境中使用以下内容：像安全修复一样对待计划外功能。

• 每个计划版本（例如3.0,3.1）都会获得自己的版本号，以及源代码中自己的标记。发布后，你不要碰它。
• 计划发布后的新功能进入下一个计划发布（例如3.2）
• 如果您必须修改已发布的代码版本，则它是“计划外版本”并获取修补程序版本号（例如3.1.1,3.1.2）。所有变化：
  • 基于该版本的最新补丁在新分支中实现（例如，3.1.1是从3.1.0创建的，3.1.2是从3.1.1创建的）
  • 立即合并到主干，因此他们也会进入下一个计划版本
• 实施计划外功能后，将分支转换为标签（又称不要再触摸它），然后返回到主干中工作。

这样，每个计划外功能都会获得一个分支，但只有足够长的时间才能生成新版本并合并到trunk中。你几乎把所有的工作都放在一个地方 - 主干 - 而且没有很多合并的工作要做。

Answer 2

像（'new_feature_branch'）这样的新分支是为了实现与当前分支不兼容的development effort（如'release_branch'）

因此，如果您当前的release_branch不是非常活跃，您可以将它用于新功能（前提是您在开发此新功能之前定义标签，以防您需要取消该过程并继续回到之前这个新功能的状态）

如果在发布分支上定期（每3周）合并一个新分支，那么建立一个新的分支可能是一个很好的解决方案，然后被遗漏。如果你在release_branch上有一些活动（比如一些热修复bug），特别推荐使用它。那么这两项努力需要分开。

基本上，这一切都取决于您的merge workflow定义。

如果您希望我详细说明您认为我没有深入解决的一些选项，请留下评论。

Answer 3

在我的办公室，我们通常在任何给定的时间点从3个分支机构工作。

• 发布：这是标记和存储当前部署的代码的位置。如果我们需要做任何关键的错误修复，这就是工作的地方。部署时，我们通常会增加标记的修补程序部分（即1.19.0 - > 1.19.1）。
• QA：这是为客户准备的代码被标记和存储的地方。当我们开始新工作并且有一些代码目前正由QA进行测试以准备下一次交付时，将使用此分支。
• 主要：这是所有新工作的完成。

在我们需要在第四行开发的极少数情况下（由于非常紧张的发布时间表），我们偶尔会打开我们的沙箱代码行。虽然更典型的是我们将只有一个开发人员单独工作，而不是在主线被清除之前检查。

通过上面的分支策略，我们已经能够在每个sprint结束时通过交付进行主要功能更改。

Answer 4

听起来你并没有真正生活在Scrum环境中。 Scrum 要求团队在每个Sprint结束时完成，这应该不会持续超过四周（更可能是一到两周）。因此，无论如何，每隔几周，您就应该拥有一个经过全面测试，正在运行，可部署的系统。

我知道这样做的唯一方法是拥有全面的，完全自动化的客户和开发人员测试套件（如极限编程规定）。

我不确定为什么在这种情况下你需要分支机构，但我也不明白为什么它不可维护。根据我的经验，分支越短越好。