1

目前我们正在使用团队城市进行自动测试和部署到测试/登台服务器。我们的解决方案由几个共享一个公共域的 .net web api:s 和 mvc 项目组成。工作流程如下（简化）：

  1. 开发人员检查他对 svn 的更改
  2. Teamcity 运行一个 msbuild 脚本，负责解决方案的配置转换、测试和打包。然后将解决方案部署到测试服务器（如果测试通过）。

这真的很好用，但我们不确定如何最好地部署到我们的发布服务器以及工作流程应该是什么样子。想象一下，我们有很大的“释放”按钮。然后应该遵循哪些步骤？由于这个问题非常模糊，我试图通过以下问题使其更加具体：

  1. 当按下按钮时，我们想标记当前的 svn root。团队城市可以做到这一点，还是我应该反过来，即创建一个标签并让团队城市使用它而不是根？如果是这样，我如何告诉团队城市使用哪个标签？或者我应该使用最新的构建工件吗？

  2. 与 1 相关。如何处理发布工件/标签的版本控制（命名）？

  3. 出于某种原因，使用 msdeploy 将解决方案部署到我们的发布服务器是否存在不好的做法？我应该考虑手动处理部署步骤吗？

  4. 是否应该手动处理数据库迁移？

我还应该考虑什么？

编辑： 我发现这篇博文回答了关于如何创建 svn 主干的自动标记/标签的问题。

4

1 回答 1

2

我面临着类似的情况。

一种方法：在 TeamCity 中构建链

解决它的一种方法是添加构建链，其中您的第二个构建配置基于第一个构建配置。您可以通过以下方式执行此操作（在 TeamCity 7/8 中）：

  1. 添加第二个构建配置
  2. 在依赖项选项卡中指定快照依赖项
  3. 如果需要，在“依赖项”选项卡中指定工件依赖项（并将它们标记为“从同一链构建”以使用上游工件。

不要在第二个构建配置中添加构建触发器；然后，您必须单击Run它以使其运行。

如果需要，这还允许您从不同的存储库中提取配置和数据。

但我不知道你对谁可以按下运行按钮有多少控制......到目前为止，似乎任何可以登录并查看项目的人都将拥有这种能力。

有关详细信息，请参阅有关构建链的TeamCity 7或TeamCity 8文档。

替代方法

最后这变得有点混乱，所以我正在寻找BuildMaster来接管它的工作流程部分；TeamCity 仍将处理构建，BuildMaster 将负责促销和部署。

于 2013-11-18T21:05:13.853 回答