1

对于每个故事，我们都会在 Git 中使用一个分支。这在本地工作得很好，但在最终确定功能时会出现问题，因为我们（当前）只将 master 推送到我们的测试环境（IIS）。请注意，我们在 TFS 旁边使用 Git，因为 TFS 仍然是我们的主要 VCS。

我们正在使用 TeamCity 来构建我们所有的分支机构。如何在不污染主分支的情况下在测试机器上测试和审查代码？为每个分支创建多个 IIS 应用程序？这可以是自动化的，但似乎是做作的。

为了澄清，我们需要能够在我们的测试环境中同时测试不同的版本。

4

3 回答 3

1

总而言之，我在 IIS 中创建了多个应用程序，一个用于团队中的每个开发人员（开发和测试），然后 3 个插槽仅用于测试目的。

在 teamcity 中，我们针对每个分支运行每个构建，但不再自动部署。原因是我们允许拉取我们的构建，但不强制升级。

当功能分支上的所有开发工作完成后，我们合并到 master 中，然后立即与 TFS 同步，以便我们的 master 分支同步。这允许我们将每个变更集的每个功能合并到下一个阶段。

于 2013-09-06T12:24:12.027 回答
0

请注意，拥有同一个应用程序的多个测试版本可能真的很混乱！！

你可以采用GitHub Flow之类的东西：

  • 每个功能一个分支
  • 功能完成后，您将其部署到测试环境
  • 如果一切正常，您可以将功能合并到主控

如果这对您来说不是一个可行的解决方案，我看到的唯一选择是部署多个 IIS 应用程序。这可以使用WebDeploy 之类的工具相对轻松地完成，但是您必须考虑使用“清理策略”来删除过时的 Web 应用程序。

于 2013-07-28T15:36:20.903 回答
0

我认为您正在寻找--dry-run开关：

-n, --dry-run
除了实际发送更新之外，做所有事情。

git push --dry-run ...
于 2013-07-26T22:42:29.053 回答