从测试/暂存到使用teamcity发布服务器

Question

目前，我们正在使用team city自动测试和部署到测试/临时服务器。我们的解决方案包括几个共享一个公共域的.net web api：s和mvc项目。工作流程如下（简化）：

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

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

1. 按下按钮时，我们想标记当前的svn root。这是团队城市的可能吗？或者我应该走另一条路，也就是说，创建一个标签，让团队城市使用它而不是根？如果是这样，我如何告诉团队城市使用哪个标签？ 或者我应该使用最新的构建工件吗？

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

3. 使用msdeploy将解决方案部署到我们的发布服务器有什么不好的做法吗？我应该考虑手动处理部署步骤吗？

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

我还应该考虑什么？

修改 我找到了this blogpost，它解答了如何为svn trunk创建自动标记/标记的问题。

Answer 1

我面临着类似的情况。

一种方法：在TeamCity中构建链

解决它的一种方法是添加一个构建链，其中第二个构建配置基于第一个构建配置。你这样做（在TeamCity 7/8中）：

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

不要为第二个构建配置添加构建触发器;然后，您必须点击Run才能允许它继续。

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

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

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

替代方法

最后这有点混乱，所以我正在考虑BuildMaster而不是接管它的工作流程部分; TeamCity仍将处理构建，BuildMaster将负责促销和部署。