svn - 以“敏捷”的节奏维护发布/分支？

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 创建的）
  • 立即合并到主干，因此它们也进入下一个计划发布
• 在实现了计划外的功能之后，你将分支变成一个标签（也就是不要再碰它了）并回到主干中工作。

这样，每个计划外的功能都会获得一个分支，但只需要足够长的时间来发布新版本并合并到主干中。您几乎可以在一个地方（主干）完成所有工作，并且没有很多合并工作要做。

Answer 2

像（'new_feature_branch'）这样的新分支用于实现与当前分支不兼容的开发工作（如'release_branch'）

因此，如果您当前的 release_branch 不是很活跃，您可以将其用于新功能（前提是您在开发此新功能之前定义了一个标签，以防您需要取消该过程并返回此新功能之前的状态）

建立一个新分支可能是一个很好的解决方案，只要它在发布分支上定期（每 3 周）合并回来，然后被排除在外。如果您在 release_branch 上有一些活动（例如一些热错误修复），则特别推荐。那么这两种努力需要保持分开。

基本上，这一切都取决于您的合并工作流程定义。

如果您希望我详细说明一些您认为我没有深入讨论的选项，请发表评论。

Answer 3

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

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

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

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

Answer 4

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

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

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