TeamCity 自动构建到生产
最近一直在尝试设置构建服务器来帮助自动化我的部署。
我的问题是，人们是否使用 TeamCity 等构建服务器将更改推送到生产 (WebDeploy) 服务器（以及测试服务器）？如果是这样，您是通过每次从源代码控制重建还是使用您推送到测试服务器的构建文件来完成此操作（还必须在为测试服务器构建时创建所有 web.configs）。
Recently been trying to setup a build server to help automate my deployment.
My question is are people using build servers like TeamCity to push changes to production (WebDeploy)servers (as well as your test server)? If so are you doing it by rebuild from source control each time or using the build files you pushed to your test server (would have also had to create all web.configs at the time you did build for test server).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
通常，最好使用为测试环境部署和产品部署生成的同一组构建文件，因为这是可以保证构建中的内容保持一致的唯一方法（即在两个构建可能已在构建服务器上安装了某些内容，或者您的 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 权限锁定它们，以便只有受限制的组有权运行这些构建配置（在我们的商店中，这实际上是确保职责分离的要求开发和运营团队之间）。作为额外的预防措施，请为您的 Prod 构建设置一个单独的构建代理，并在需要之前将其禁用（防止您意外运行 prod 构建配置...是的，我曾经经历过叹息）。
It is generally a good idea to use the same set of build files you generated for your test environment deploy as for your prod deploy, as this is the only way you can guarantee that what went into the build will be consistent (i.e. in between the two builds something could have been installed on the build server or your VCS may return a slightly different set of source code files).
This is best achieved in TeamCity with the use of build artifacts, which harvest the output of your builds into a special storage area, allowing them to be drawn down in another build configuration for later use. More info in the TeamCity docs http://confluence.jetbrains.net/display/TCD6/Build+Artifact
As far as your configs go, consider using config transforms. These allow you to have a variant of your Web.config for each target environment, with different connection strings, environment constants etc. More info on MSDN http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
If you actually intend on using TeamCity to deploy to your Production environment, you may want to consider locking these down using TeamCity permissions so that only a restricted group has access to run those build configurations (in our shop this is actually a requirement to ensure seggregation of duties between Dev and Ops teams). As an added precaution, set up a separate build agent just for your Prod builds and keep it disabled until you need it (prevents you from accidentally Running a prod build configuration... yep I've been there sigh).
在之前的项目中，我们首先使用 CruiseControl.net，后来使用 TeamCity 将更改推送到我们的测试服务器，我们使用特殊的 NAnt 目标来触发部署。
在 TeamCity 中，我们有一个构建项目（或者在 TeamCity 中也称为目标？），只需手动启动即可触发安装。
安装是通过安装我们的 MSI 软件包的远程 PowerShell 脚本完成的。
On a previous project we used first CruiseControl.net and later TeamCity to push changes to our test servers, we used a special NAnt target to trigger the deploy.
In TeamCity we had a build project (or it is called target in TeamCity too?) with only a manual start to trigger the install.
The install was done with a remote PowerShell script that installed our MSI packages.
我决定尝试的是一个 MSBuild 脚本，它将所有配置转换到一个位置，然后我尝试创建一个包（以及存档，因为我不想作为 zip 文件，这就是我在片刻）。
所以我会这样：
第一个 TeamCity 配置：
第二个构建配置|
任何帮助实现这一目标将是伟大的
What I've decided to try is an MSBuild script that transforms all the configs to a location then I'm trying to create a package (well archive as I don't want as a zip file and is what i am struggling with at the moment).
So I would have this:
1st TeamCity Config:
2nd Build configuration|
Any help with achieving this would be greatful