最近一直在尝试设置构建服务器以帮助自动化我的部署. 我的问题是人们使用像TeamCity这样的构建服务器将更改推送到生产(WebDeploy)服务器(以及测试服务器)？如果是这样,你每次都是通过
我的问题是人们使用像TeamCity这样的构建服务器将更改推送到生产(WebDeploy)服务器(以及测试服务器)？如果是这样,你每次都是通过从源代码控制重建或使用你推送到测试服务器的构建文件来做这件事(在你为测试服务器构建的时候也必须创建所有的web.configs).
使用为测试环境部署生成的同一组构建文件通常是一个好主意,因为这是保证构建内容一致的唯一方法(即在可以在构建服务器上安装两个构建的东西,或者您的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构建配置……是的,我一直在那里叹息).