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

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创建的)
  • 立即合并到主干,因此他们也进入下一个计划发布
• 在实现计划外功能后,您将分支转换为标记(也就是不要再触摸它)并返回到主干中工作.

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