2

使用 TFS,我们有以下内容:

  • 主要基线
  • 每个开发工作的开发分支。这些被合并回基线。
  • 随每个版本创建的版本分支。错误修复在这里进行、发布并合并回基线。
  • 使用搁置集,如果需要,我们可以在开发分支之间共享代码,而不会污染基线。对代码审查很有用。
  • 当我们将开发更改交付到基线时,我们有一个自动构建启动并自动将我们的更改放置在测试服务器上。

问题是业务分析师在测试服务器上之前无法看到我们的更改,目前在测试服务器上获取我们的更改的唯一方法是将它们检查到基线中。因此,如果 BA 发现有问题,不幸的是,该代码已经处于基线状态,我们将不得不费力将其取回。

有没有一种方法可以改变我们的分支策略或流程,让 BA 得到他们想要看到的东西,而不会污染我们的基线?

4

2 回答 2

4

你的分支策略听起来正是我们在我公司决定的。我认为问题不在于您的分支策略,我认为问题在于您必须检查基线的更改才能将它们应用于测试服务器。

在我的公司,直到在生产中推广和运行更改才会检查到基线中。发布分支是部署到测试服务器的内容......如果发现错误,或者 BA 想要更改某些内容,我们不必经历从基线中删除更改的痛苦。

但是,如果您有很多并发版本,那么在将所有版本移动到生产之前将它们合并在一起可能会变得很痛苦,因为您要在流程的后期才合并到基线中。在我的公司,我们有一个非常严格的发布时间表,并且尝试一次只发布一个版本来投入生产。正因为如此,等待将发布合并到基线直到发布被提升到生产中并没有给我们带来任何问题,或者到目前为止的额外工作......

你多久发布一次?您能否将发布分支部署到您的测试服务器上,并让基线代表当前在生产中部署的内容?

(我会对此发表评论,但我仍在努力获得该特权......)

于 2011-03-22T18:22:38.850 回答
1

我不喜欢这种方法,我建议:

包含稳定代码的主要基线。只有在成功发布后,代码才会从相应的发布分支合并到这个分支中。

从 Main 为每个版本创建的 Release 分支。该分支将用于生成发布版本并将部署到测试环境。

从发布分支创建的开发分支,它将用于开发工作,并在我准备好对我的构建进行测试时合并到发布。

于 2011-03-22T18:40:08.810 回答