TeamCity自动生成到生产

最近一直在尝试设置生成服务器以帮助自动化我的部署。TeamCity自动生成到生产

我的问题是是人在使用构建服务器像TeamCity的推更改生产（WebDeploy）服务器（以及测试服务器）？如果是的话，你每次都要通过源代码控制进行重建，或者使用你推送到测试服务器的构建文件（在构建测试服务器时还必须创建所有web.configs）。

来源

2011-09-13 user203538

最好的资源我遇到任何帮助： HTTP：//www.troyhunt。 com/2010/11/you-deployment-it-wrong-teamcity_26.html＃comment-308937644 – user203538

Google“teamcity msdeploy”，您将找到大量关于如何设置的资源。例如[http://www.agileatwork.com/automatic-deployment-from-teamcity-using-webdeploy/](http://www.agileatwork.com/automatic-deployment-from-teamcity-using-webdeploy/） – terjetyl

它一般是用同一套您的测试环境中生成的部署为您督促部署构建文件是一个好主意，因为这是你能保证什么地方到构建将是一致的唯一途径（即在两个版本之间可能已经在构建服务器上安装了某些东西，或者您的VCS可能会返回一组稍微不同的源代码文件）。

这是最好的TeamCity与使用构建工件，其收获的您构建成一个特殊的存储区域，让他们输出的实现，以供以后使用另一个构建配置中提取。在TeamCity的文档http://confluence.jetbrains.net/display/TCD6/Build+Artifact

更多信息至于你的configs去，可以考虑使用配置转换。这些允许您为每个目标环境使用不同的Web.config，使用不同的连接字符串，环境常量等。有关MSDN的更多信息http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx

如果您实际上打算使用TeamCity部署到生产环境，可能需要考虑使用TeamCity权限来锁定这些设置，以便只有受限制的组才有权运行这些构建配置（在我们的商店中，这实际上是确保Dev和Ops团队之间职责分离的必要条件）。作为一个额外的预防措施，建立一个单独的构建代理只是为了你的Prod构建，并保持禁用，直到你需要它（防止你意外运行一个prod构建配置......是的，我一直在那里叹息）。

来源

2011-09-14 00:28:08

在我们使用的第一CruiseControl.net后来的TeamCity推动改变我们的测试服务器以前的项目，我们使用了一种特殊的恶性目标触发部署。

在TeamCity的，我们有一个积累的项目（或它在TeamCity的称为目标吗？）只用手动启动触发安装。

安装使用安装我们的MSI软件包的远程PowerShell脚本完成。

来源

2011-09-13 18:26:46

我决定尝试一个MSBuild脚本，它将所有配置转换为一个位置，然后我试图创建一个包（因为我不想将它作为zip文件进行存档，所以我是我）在此刻挣扎着）。

所以我有这样的：

1 TeamCity的配置：

变换分析网络。CONFIGS
构建以位置
MSDeploy于TEST

第二构建配置|

MSDeploy生产与构建文件和现场配置

与实现这一目标将不胜感激

来源

2011-09-15 09:14:23 user203538

TeamCity自动生成到生产

回答

相关问题