发布分支的时间安排

另一个需要考虑的问题是:

考虑在主干上保留渐进式代码(最活跃使用的代码假定是朝向新的最新版本的代码)。从头部分支(或者如果你已经标记了它,则是以前的基线版本),以供bugfixer团队使用。如果他们愿意的话,他们可以定期修复bug并从主干中进行合并,以获取最新开发的更新。

另一方面,新的发布工作在主干上进行,主干可以被指定为始终表示“当前”或“生产”环境中的内容。如果您想把以前版本的补丁恢复到curent版本中,您可以从bugfix分支合并回主干。

这个模型也可以在下一个发布标签之后迭代。

在我的经验中,这有助于最小化合并,因为错误修复的数量会减少,所以这意味着需要时可以将更少的文件合并回主干。在大多数情况下(我说的不是全部:-)的bugfixing上的开发人员的数量将减少,因此这再次意味着需要合并的文件的数量更少。

Hth.

对于这些问题,我强烈推荐Git/Mercurial。:)

但既然我知道这不是一个选择,我只能说,对于这些类型的问题,没有100%的好答案。一般来说,我倾向于在流程中尽可能晚的时候才进行分支,因为与cvs/svn的分支和合并往往是重量级的流程。延迟分支过程的时间越长,在许多方面就越好。但是,正如开发新特性的团队所知道的,这只能持续这么久…在某种程度上,延迟新功能的成本超过了延迟合并的好处。

在我现在所处的位置,这通常会导致在新版本发布前1-2周(有时甚至更短)出现分支。但准确的时间总是根据驱动发布的特定压力和即将发布的新功能而变化。

在SVN中,分支并不一定是一个痛苦的过程,特别是在最新版本的Tortoissesvn和SVN客户机中。它需要一些VCS和回购的知识,但这对于任何软件开发人员都是必需的。

需要考虑的是在开发的每个阶段有多少新代码和可能发生多少修改。通常,sprint/release阶段会生成比bug修复阶段更重要的变更集。这意味着,更明智的做法是立即进行分支,并在出现错误时合并较小数量的错误修复。在大多数情况下,等待分支会导致更混乱的合并。

早期的分支还使您的bug修复程序暴露得更多,因为它们可以由Sprinting开发人员在单元测试和新特性的功能测试期间执行。更多的暴露=更好的无缺陷修复。

一旦你进入一个版本的特性冻结阶段,你就必须做一个分支,这样下一个版本的开发团队就不会继续破坏你想要睡觉的版本。试图延迟分支的时间超过这个时间只会导致更多的问题。

如果您使用功能分支,那么这就更容易了。所有的修复都发生在主干中,您保留了一个RC分支,在那里您将发布,并且可以在进行测试发布之前从主干到主干进行大规模合并。功能分支从主干合并,只有在功能准备就绪时才能合并回主干。虽然这听起来会导致更多的合并,但它使所有的合并非常简单。

这类似于使用DVC获得的工作流,只是所有的分支都在普通的视线中,而不是分散在开发人员的机器上。

越晚越好。