1

问题

使用 TFS——特别是 Team Build——我正在尝试提出一种用于构建和部署多个 Web 应用程序的策略。我正在努力定义我想要如何执行这些构建和部署。

在这种情况下，我将构建定义为在编译任何应用程序时创建的内容。我将部署定义为实际发布到某个环境的内容，即使该环境是内部的。

TFS 提供了一种创建构建的方法。生成的构建的质量可以由适当的用户设置。构建可能具有准备测试、通过 QA、通过 UAT、失败、已发布等质量。

可能性

我从事过在 TFS 中设置了与部署相对应的构建定义的项目。因此，例如，PC 将具有 Builds ReleaseQA、ReleaseUAT 和 ReleaseProd。尽管这确实有效并且已集成到 TFS 中，但对我来说感觉像是在作弊；与其创建一个构建并在自己的环境中引导它，不如创建多个构建并将每个构建部署到不同的环境中。

我设想了一个通过生成构建然后在各种环境中推广该构建来工作的过程。

惊人的

右键单击 TFS 中特定的已完成构建，然后选择 Deploy->UAT。

不太棒

位于我的构建机器上的脚本文件夹，其标题包括 deploy-build-qa、deploy-build-uat 和 deploy-build-prod；一个人用内部版本号调用它们，脚本将构建版本部署到适当的环境

你

是否有一种很好的集成方式来执行我提出的令人敬畏的场景之类的事情，或者我是否坚持不那么令人敬畏的事情？如果没有任何“开箱即用”的东西，我愿意接受附加组件或应用程序。

4

1 回答 1

4

是的，这是可能的！我今天一直在为我正在从事的一个新项目的基础设施实施它:)

我开始使用TfsDeployer。

首先，我创建了一个使用MSDeploy的 powershell 脚本（我们正在构建一个包含多个 Web 和 WCF 项目的解决方案），然后将脚本链接到 TfsDeployer。

现在我可以更改构建的质量并启动一个将构建部署到测试、验收或生产服务器的 powershell 脚本。

我也非常喜欢帮助所有配置转换的东西是SlowCheetah。它有助于定义所有 xml 文件的转换以及简单地预览转换的能力。

希望这可以帮助 ：）

于 2011-11-07T22:11:29.240 回答