TFS 2010 和“构建一次，部署多次”
我对这个主题做了很多研究，但找不到任何端到端解决方案来使用 TFS 2010 实现“构建一次并部署多次”。
基本上我想到的是有一个构建定义，它将构建一个解决方案要部署的多个项目（Web 应用程序 + 数据库项目 + Web 服务 + 报告），将输出放在放置文件夹中，然后根据质量和版本手动决定将所有项目部署到各种环境（qa、ua、staging、生产）。
我知道我可以修改构建过程模板以在构建后立即部署多个项目，例如“构建主要并部署到 QA”、“构建主要并部署到 UA”等，可能基于变更集#或标签，但这意味着每次建设。 我想要的更像是一个仪表板，它允许部署团队在 UA 环境中部署在 QA 中测试过的确切构建，并在获得批准后将其部署到生产中。当然，这意味着配置文件应该在部署时进行相应更新。
我还在考虑定义一些构建定义，这些定义实际上不会构建任何东西，而是会将现有构建（基于版本）部署到特定环境，但至少可以说它看起来有点奇怪。
I did a lot of research on this subject but couldn't find any end to end solution to implement the "build once and deploy many" using TFS 2010.
Basically what I am thinking of is having a build definition that will build a solution with multiple projects to be deployed (web application + database project + web service + reports), place the output in the drop folder and from there based on quality and version manually decide to deploy all the projects onto various environments (qa, ua, staging, production).
I know that I can modify the build process template to deploy multiple projects right after the build, something like "Build Main And Deploy to QA", "Build Main and Deploy to UA" etc, based probably on changeset# or labels but this means building every time.
What I would like is more like a dashboard that will allow the deployment team to deploy the exact build that was tested in QA, on UA environment and after getting the green light to deploy it on production. Of course that means the configurations files should be updated accordingly at the deployment time.
I am also considering defining some build definitions that won't actually build anything, instead it will deploy an existing build (based on version) to a specific environment, but it looks a bit strange to say the least.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这已经足够我们使用的了，我们有构建模板来进行实际构建，并部署将输出部署到各种机器的模板（这些可以设置为在预定时间运行，例如每晚运行到 QA 等，或者按需运行，例如UAT/实时）。这些模板对默认模板进行了高度修改，我们只是深入了解构建的详细信息（或者在某些情况下，您可以采用最新的构建，例如冒烟测试环境），例如放置位置。
您需要在要部署到的计算机上安装一个可以处理部署的代理，但您可以根据需要安装任意数量的代理。
例如，您可以有一个将应用程序构建为 exe 的构建，以及一个接受 exe 并在目标上运行它的模板（使用 InvokeProcess）。如果您需要将相同的东西部署到另一个环境，您只需使用相同的放置位置即可，viola！
你所得到的听起来一点也不奇怪，以这种方式处理它是有意义的。
That's near enough what we use, we have build templates to do actual builds, and deploy templates that deploy the output to various machines (these can be either set to run at scheduled times, like nightly drops to QA etc, or on demand such as UAT/live). The templates are highly modified from the default ones, we just plumb in the details from the builds (or in some cases you could take the latest builds such as a smoke test environment) such as drop locations.
You'll need an agent on the machine you're deploying to that can handle the deployment, but you can install as many agents as you like.
As an example you could have a build that builds your application into an exe, and a template that takes the exe and runs it on your target (using InvokeProcess). If you need to deploy the same thing to another environment, you just use the same drop location, viola!
What you've got doesn't sound strange at all, makes sense to handle it that way.
我知道这是一个迟到的回复，但自 2012 年以来情况已经发生了变化。 Microsoft 有一个 发布管理产品现在从头开始设计，以实现“构建一次，部署多次”。修改构建过程模板总是很痛苦。
I know this is a late response, but things have changed since 2012. Microsoft has a Release Management offering now that is designed from the ground up to enable "build once, deploy many". Modifying build process templates is always a pain.
Daniel 的答案几乎是让 TeamBuild 这样的构建系统处理部署的标准方法。这感觉有点奇怪，因为你正在将一个工具用于另一个目的。但它绝对可以工作。
另一种方法是获得与 TFS / TeamBuild 集成的纯部署工具。跨环境部署是很自然的，但是您需要管理两个工具。
Daniel's answer is pretty much the standard way of getting a build system like TeamBuild to handle deployments. It feels a little weird because you are bending a tool to another purpose. It can definitely work though.
The other approach is to get a pure deployment tool that integrates with TFS / TeamBuild. The deployment across environments would be natural, but then you have two tools to manage.