views:

863

answers:

2

I'm working in a team environment where each developer works from their local desktop and deploys to a virtual machine that they own on the network. What I'm trying to do is set up the Visual Studio solution so that when they build the solution each projects deployment is handled in the post-build event to that developers virtual machine.

What I'd really like to do is give ownership of those scripts to the individual developer as well so that they own their post build steps and they don't have to be the same for everyone.

A couple of questions:

  • Is a post build event the place to execute this type of deployment operation? If not what is the best place to do it?
  • What software, tools, or tutorials/blog posts are available to assist in developing an automatic deployment system that supports these scenarios?

Edit: MSBuild seems to be the way to go in this situation. Anyone use alternative technologies with any success?

Edit: If you are reading this question and wondering how to execute a different set of MSBuild tasks for each developer please see this question; Executing different set of MSBuild tasks for each user?

+1  A: 

i'd look into MSBuild or ANT

Bob Dizzle
+1  A: 

If you are using Visual Studio 2005 or later, project files are MSBUild files. Inside the MsBuild file, there is an "AfterBuild" target. I would recommend using this to do your deployment tasks, instead of the Post Build Event.

By using MSBuild tasks, you are more prepared to move into a Continuous Integration system like CruiseControl.NET, or Team City.

I'm not sure why all of your developers have their own virtual machines, it would seem at some point you'd want a central location where all developers work is built to ensure the code from all developers will integrate and build (this is a reason for using Continuous Integration systems). I'm sure you can find a way that CruiseControl.Net or Team City or one of several other choices can help you in this scenario. But as far as getting the initial setup, use MSBuild.

NerdFury
We will have a common environment for staging and test but I don't want devs to deploy over each other with each build. I do however want to give them a real server to work with without asking them to install Win 2k8, SQL, MOSS, etc... on their machine. MSBuild is probably the right answer for us.
spoon16
I would still recommend using a CI tool so that at least one environment has the sum of all the parts running at all times. And then you could work towards automated testing as well.
NerdFury
I'm not sure why you are concerned with developers deploying over each other? If you're using source control, shouldn't they all be building from the same code? And they shouldn't be deploying code that isn't checked in.
lordscarlet