Question

寻找有关如何处理此场景的建议。

我们有3个环境：Dev，QA和Production。

目前将代码推送到每个环境是一个手动过程，想知道Cruisecontrol或TeamCity之类的东西如何简化这个过程。

我们如何以自动化的方式推动各种环境？

如何设置TFS来实现这一目标？即主分支，特征分支等。

之情况：

开发人员＃1将他们的更改推送到Dev和QA服务器。开发人员＃2将他们的更改推送到Dev和QA服务器。

现在我们只需要将开发人员＃1的更改推向生产。

主分支是否只有应该进入生产的代码？

Answer 1

要控制推送到每个环境的内容，KMoraz的方法将是正确的，使用分支和合并。

现在，对于构建和部署自动化，我一直在使用的最新设置是Team City。

我的设置是：

中继构建：在每次提交时编译，运行所有单元测试，生成代码覆盖率报告，运行FxCop
静态分析构建：每晚针对Trunk运行，执行Duplicate Finder（Team City），ConQAT code clone analysis，StatSVN和Resharper Code Inspections（Team City）
DEV部署（依赖于Trunk构建）：在每次提交时，如果Trunk构建成功，应用程序将自动部署到DEV环境，使用带有配置转换的MS WebDeploy。
QA部署：在转移到QA时，通过Team City的界面（单击按钮）手动触发。使用带有配置转换的MS WebDeploy将应用程序部署到QA服务器。

您还可以根据需要为不同的分支设置构建，尤其是针对为稳定版本的版本创建的分支。

关键部分是拥有不同的visual studio构建配置（就像你有“Release”和“Debug”一样，你应该有“Dev” ，“QA”等），您应该将其与web.config转换一起使用，以便让WebDeploy为您配置环境。这样，您就可以使用不同的 web.Dev.config ， web.QA.config 转换，每个构建配置一个转换，具有特定设置。

特洛伊·亨特（Troy Hunt）发表的一系列精彩文章称“你的部署错误！”它指导您完成自动构建和部署的设置。

http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html

在设置时，这对我非常有用。

Answer 2

现在我们只需要将开发人员＃1的更改推向生产。

-Developer＃1将他的代码签入Dev分支。在QA验证了他的更改后，现在您将更改合并到Main分支，并从Main构建生产版本。

主分支是否只有应该去的代码生产

是的。理想情况下，生产版本应该从Main分支构建。

我们如何以自动化的方式推动各种环境？

- 在TFS中，常见的做法是为每个分支和/或构建类型定义构建定义。除了源和构建类型之外，每个定义也可以有自己的任务，即：运行单元测试，发布到某些文件夹，将构建工件部署到Lab Management等。

ProjectName-Main-Gated 
ProjectName-Dev-CI
ProjectName-Dev-Nightly
ProjectName-Test-CI

TFS或Teamcity，如何自动部署到各种环境？

2 个答案: