最近一直在尝试设置构建服务器以帮助自动部署。
我的问题是人们使用像TeamCity这样的构建服务器将更改推送到生产（WebDeploy）服务器（以及测试服务器）吗？如果是这样，你每次都是通过从源代码控制重建或使用你推送到测试服务器的构建文件来做这件事（在构建测试服务器的时候也必须创建所有的web.configs）。
答案 0 :(得分：3)
使用您为测试环境部署生成的同一组构建文件通常是一个好主意，因为这是您可以保证构建的内容将保持一致的唯一方法（即在两个构建之间可能已经在构建服务器上安装了某些东西，或者您的VCS可能会返回一组略有不同的源代码文件。）
这最好在TeamCity中使用构建工件实现，构建工件将构建的输出收集到一个特殊的存储区域，允许它们在另一个构建配置中绘制下来供以后使用。 TeamCity docs http://confluence.jetbrains.net/display/TCD6/Build+Artifact
中的更多信息就您的配置而言，请考虑使用配置转换。这些允许您为每个目标环境提供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构建配置......是的，我一直在那里叹息）。
答案 1 :(得分：0)
在之前的项目中，我们首先使用CruiseControl.net和后来的TeamCity将更改推送到我们的测试服务器，我们使用了一个特殊的NAnt目标来触发部署。
在TeamCity中，我们有一个构建项目（或者在TeamCity中也称为目标？），只需手动启动即可触发安装。
使用安装了MSI软件包的远程PowerShell脚本完成安装。
答案 2 :(得分：0)
我决定尝试的是一个MSBuild脚本，它将所有配置转换为一个位置然后我正在尝试创建一个包（好的存档，因为我不想作为一个zip文件，而且我正在努力在此刻）。
所以我会这样：
第一次TeamCity配置：
第二次构建配置|
实现这一目标的任何帮助都会很棒