以“敏捷”的节奏维护发布/分支？ [关闭]

Posted 2023-03-05

【中文标题】以“敏捷”的节奏维护发布/分支？ [关闭]

【英文标题】：Maintaining releases/branches in an "agile" rhythm? [closed]

【发布时间】：2008-10-30 16:05:07

【问题描述】：

我们的软件产品可以根据客户的需求和更通用的路线图发展。

因为我们处于 SCRUM 项目环境中，所以经常会出现新功能进入产品的情况，然后我们面临以下选择：

在已发布的分支中实现此功能（不是真正的分支） 创建一个新分支 - 但是我们每三周就有一个分支，它不再可维护了

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

考虑到这些限制，有人对好的做法有任何反馈吗？

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

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

【参考方案2】：

一个新的分支，如（'new_feature_branch'），用于实现与当前分支不兼容的development effort（如'release_branch'）

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

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

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

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

【参考方案3】：

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

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

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

通过上述分支策略，我们能够通过在每个 sprint 结束时交付来进行重大功能更改。

【参考方案4】：

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

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

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