3

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

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

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

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

应该如何设置 TFS 来实现这一点？即主分支，功能分支等。

场景：

Developer#1 将他们的更改推送到 Dev 和 QA 服务器。Developer#2 将他们的更改推送到 Dev 和 QA 服务器。

现在我们只需要将 Developer#1 的更改推送到生产环境。

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

4

2 回答 2

5

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

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

我的设置是：

  • 主干构建：每次提交时编译，运行所有单元测试，生成代码覆盖率报告，运行 FxCop

  • 静态分析构建：每晚针对 Trunk 运行，执行 Duplicate Finder（Team City）、ConQAT 代码克隆分析、StatSVN和 Resharper 代码检查（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

设置它时对我非常有用。

于 2012-06-09T02:08:29.647 回答
1

现在我们只需要将 Developer#1 的更改推送到生产环境。

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

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

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

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

- 在 TFS 中，一种常见的做法是为每个分支和/或构建类型定义构建定义。除了源代码和构建类型之外，每个定义还可以有自己的任务，即：运行单元测试、发布到特定文件夹、将构建工件部署到实验室管理等。

ProjectName-Main-Gated 
ProjectName-Dev-CI
ProjectName-Dev-Nightly
ProjectName-Test-CI
于 2012-06-08T22:10:21.990 回答