需要基于trunk的开发建议

问题描述:

在做了多年的功能分支和挣扎了很多分支并合并恶梦后,我一直在寻找分支策略方面的优秀资源。功能分支确实为我们提供了一种很好的隔离功能,以非常细化的方式管理发行版,以便发布哪些功能。然而,他们提出的问题(很多分支机构,合并冲突)远比他们提供的好处多得多。需要基于trunk的开发建议

我们在后端使用Oracle数据库(使用5000个对象)。我们也有多个团队在同一产品的不同领域开展工作。我们使用Visual Studio和TFS(无DVCS)。

我们创建的分支越多,我们需要在这些分支(每个分支 - 一个数据库实例)的功能测试中给出适当的隔离,这是另一组问题。

我们正在采用scrum并正在寻找适合我们的发布周期(每年4次)和CI构建的分支模型。我们计划为每个版本进行5次常规冲刺和1次强化冲刺。

从分支模型的特征,我们重新设计我们的分支模式,一个很简单的分支像下面 -

Branching Model

发展分支正在为我们的“树干”(中继线基础的发展)和所有开发人员(所有团队)正在对该分支进行承诺(季度发布),测试人员正在此分支进行测试,并且CI服务器(Jenkins)每天都在建设该分支。我们只是需要一个干净的MAIN在任何时候安全作为“最后一次释放真相的单一来源”,由于多种原因而经常使用。

维护分支是我们的错误修复分支(修补程序),并在一年中发布多次(不论季度发布)。我们宁愿不直接在主分支上工作,因为想要有一个“干净的”主分支。如果没有进行“手动”/功能测试,我们不希望代码进入Main。一旦错误修复发布完成,代码将从维护 - >主要 - >开发合并,以将错误修复集成到开发中。

我们通常不需要TBD中建议的“发布分支”,因为我们将持续进行维护分支中的错误修复,从维护版本中释放,然后将更改合并到主要(然后开发)。我们只维护“最新版本”,如果需要以前的版本修复,我们需要从主标签中创建一个旧版本分支。

我们是否修改了基于主干的开发,以至于将来会出现问题?你有什么建议?

参见:

http://paulhammant.com/2013/12/04/what_is_your_branching_model

http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723

你应该从已公布的标签的维持性分支,只有当你遇到一个错误。实际上这是一个发行版分支,应该为发行版命名。说rel_1.1。当你推出1.2版本时,很显然你不会回滚,删除rel_1.1。