我对此主题进行了大量研究，但找不到任何端到端解决方案来使用 TFS 2010 实施“一次构建并部署多次”。
基本上我在想的是有一个构建定义，它将构建一个包含多个要部署的项目（Web 应用程序 + 数据库项目 + Web 服务 + 报告）的解决方案，将输出放在放置文件夹中，然后从那里基于质量和版本手动决定将所有项目部署到各种环境（qa、ua、staging、生产）。
我知道我可以修改构建过程模板以在构建后立即部署多个项目，例如“构建主程序并部署到 QA”、“构建主程序并部署到 UA”等，可能基于变更集#或标签但这意味着每次都要建造。 我想要的更像是一个仪表板，它允许部署团队部署在 QA、UA 环境中测试过的确切构建，并在获得批准后将其部署到生产环境中。当然，这意味着配置文件应该在部署时相应地更新。
我也在考虑定义一些实际上不会构建任何东西的构建定义，而是将现有构建（基于版本）部署到特定环境，但至少可以说看起来有点奇怪。
【问题讨论】：
标签： deployment build-automation
这已经足够我们使用的了，我们有构建模板来进行实际构建，并部署将输出部署到各种机器的模板（这些可以设置为在预定时间运行，例如每晚投放到 QA 等，或者在需求，例如 UAT/live）。模板对默认模板进行了高度修改，我们只是深入了解构建的细节（或者在某些情况下，您可以采用最新的构建，例如烟雾测试环境），例如放置位置。
您需要在要部署到的机器上安装一个可以处理部署的代理，但您可以安装任意数量的代理。
例如，您可以有一个将您的应用程序构建为 exe 的构建，以及一个获取该 exe 并在您的目标上运行它的模板（使用 InvokeProcess）。如果您需要将相同的东西部署到另一个环境，您只需使用相同的放置位置，viola！
你所拥有的听起来一点也不奇怪，这样处理它是有意义的。
【讨论】：
Daniel 的回答几乎是获得像 TeamBuild 这样的构建系统来处理部署的标准方法。感觉有点奇怪，因为您正在将工具弯曲到另一个目的。它绝对可以工作。
另一种方法是获取与 TFS / TeamBuild 集成的纯部署工具。跨环境部署是很自然的，但您需要管理两个工具。
【讨论】：
我知道这是一个迟来的回应，但自 2012 年以来情况发生了变化。微软现在有一个 Release Management offering，它是从头开始设计的，以实现“一次构建，多次部署”。修改构建过程模板总是很痛苦。
【讨论】：