8

我们的开发/发布周期是这样的：

  1. 开发者创建一个特性分支，实现一个特性
  2. 开发人员表示功能已准备好进行验收测试 (UAT)
  3. 测试人员部署功能分支并接受（或拒绝）功能

接受的功能然后由测试人员合并到主分支中，因此将在下一个发布周期中发布（我们每周部署主干/主代码）。

我们对合并冲突感到沮丧，因为当测试人员对功能进行 UAT 并发现它不会干净地合并时，在其中工作的开发人员通常会转向其他事情。

我们正在考虑一种解决方案，TeamCity 会自动将每个功能分支与当前主分支合并，并且任何导致合并冲突的构建都被视为失败的构建 - 这将使我们尽早了解有问题的合并，以便我们可以修复他们早点。

TeamCity 似乎没有对此工作流程的内置支持（即，当分支 X 发生推送时，结帐 master，将分支 X 合并到它上面，构建，单元测试，创建包）。有没有人使用 TeamCity 和 Github 创建了类似的工作流程——也许是使用自定义 msbuild 目标？

编辑：我应该澄清一下我们正在使用 Github，但我们目前没有使用拉取请求 - 听起来这是我应该调查的事情。:)

4

1 回答 1

2

如果您使用的是 Github 和 Pull Requests，请查看 Hadi Hariri 的博客文章，了解如何在与 master 合并后获取 pull request：

http://hadihariri.com/2013/02/06/automatically-building-pull-requests-from-github-with-teamcity/

Github 对每个拉取请求进行自动合并，并且生成的合并可用（尽管几乎没有记录）

git fetch origin +refs/pull/298/merge

其中拉取请求 id 是 298。因此，所有合并的拉取请求都可以使用通配符代替 Teamcity 中的 id 获取并自动构建。分支规范如下所示：

+refs/pull/*/merge

编辑：您说您没有使用拉取请求，所以我想您可以使用一些 git 命令来执行此操作。我自己还没有尝试过，所以这些只是一些帮助你入门的技巧。

  1. 使用 Teamcity 中的分支规范功能来获取分支。设置结帐模式以签出代理上的代码
  2. 在构建步骤中，将主分支合并到目标分支中。如果 master 在代理上不可用，您可能必须先获取它。如果出现任何错误，则构建失败。

要检查合并冲突，这些策略之一应该有效。

于 2013-06-16T21:38:57.973 回答