TFS 2010 and "build once, deploy many"

Question

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.

Answer 1

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.