最近一直在尝试设置构建服务器来帮助我的部署自动化。
我的问题是人们是否使用像 TeamCity 这样的构建服务器来将更改推送到生产 (WebDeploy) 服务器（以及您的测试服务器）？如果是这样，您是通过每次从源代码控制重建还是使用推送到测试服务器的构建文件来做到这一点（在为测试服务器构建时还必须创建所有 web.config）。
【问题讨论】：
标签： .net asp.net teamcity web-deployment-project
使用为测试环境部署生成的构建文件集与为产品部署生成的构建文件集通常是一个好主意，因为这是您可以保证构建中的内容一致的唯一方法（即在两个构建之间，可能已经在构建服务器上安装了一些东西，或者您的 VCS 可能会返回一组略有不同的源代码文件）。
在 TeamCity 中，最好使用构建工件来实现这一点，它将构建的输出收集到一个特殊的存储区域，允许将它们绘制到另一个构建配置中以供以后使用。更多信息请参阅 TeamCity 文档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 构建配置......是的，我去过那里 sigh)。
【讨论】：
在之前的项目中，我们首先使用 CruiseControl.net 和后来的 TeamCity 将更改推送到我们的测试服务器，我们使用了一个特殊的 NAnt 目标来触发部署。
在 TeamCity 中，我们有一个构建项目（或者它在 TeamCity 中也称为目标？），只有手动启动来触发安装。
安装是使用安装了我们的 MSI 包的远程 PowerShell 脚本完成的。
【讨论】：
我决定尝试的是一个 MSBuild 脚本，它将所有配置转换到一个位置，然后我正在尝试创建一个包（以及存档，因为我不想要作为 zip 文件，这就是我正在努力的与此刻）。
所以我会这样：
第一个 TeamCity 配置：
第二次构建配置|
对实现这一目标的任何帮助都会非常有用
【讨论】：