Although it is fun and dandy to do all development, deployments, and testing locally on our development boxes or, even better, within a VM on our dev boxes, all of us know that eventually when our proof of concept becomes a real-life project where we collaborate with other team members, show off the betas to clients, and prepare for production launch, we need to venture off into source control land, dev servers and stage builds.

Those of us who have used CruiseControl.NET know how lovely it is to just check-in your code and see it appear on the dev or stage server in minutes. We also know how embarrassing it is to break the build. This process is known as Continuous Integration. The famous Martin Fowler has written a bit about Continuous Integration. I recommend those who are interested to read that article.

Recently I’ve decided to try a Continuous Integration approach using Team Foundation Server 2008. Since our source control environment is entirely TFS, it would make sense that the integration process could come directly out of the source control system we use.

Assuming you have a TFS server setup to handle builds, the process is pretty easy. For details on setting up the build server itself, please refer to Managing Builds with Team Foundation Build. Another assumption is that your TFS service has access to the servers and paths you are trying to deploy to.

9 Simple steps to TFS continuous integration

    1. Go to TeamExplorer. Go to your TFS project. Right click on Builds and click “New Build Definition”
    2. Under the General tab, you’ll name your Build Definition (e.g. FooBuilder).
    3. Under Workspace, you will define the source code that you want to build.
    4. Under Project File, you select a spot within TFS to store your build script. This is important as we would like to modify this build script later on to make deployments automated. We’ll name it TFSBuild.proj for now.
    5. Under Retention Policy, you can configure how long you would like your builds to be stored based on their success level.
    6. Under Build Defaults, you need to set up your build agent. Typically this would be done for you by your TFS admin. If not, you’ll need to create a new build agent, set the computer name of the build server. You’ll also need to set the working directory. Something like C:\Builds\$(BuildDefinitionPath)would due. You also want to set the Agent Status to “Enabled”.
    7. Under the Trigger tab, you can set how you will like your builds to work. If you want a build to occur every time code is checked in, select “Build each check-in”.  You want to be careful how this is setup, especially if there is a large team where people may check-in un-tested code.
    8. At this point the automatic build part should be in place. To integrate deployments into your automation, you need to checkout and open up that TFSBuild.proj file we spoke about in step 4.
    9. At the bottom of the script, add this MSBuild command and check in the file:

<Target Name=”AfterDropBuild”> <Exec Command=”xcopy /y /e “$(BinariesRoot)\Release\_PublishedWebsites\[INSERT_PROJECT_FOLDER_NAME]” “\\[INSERT_UNC_TO_DEPLOYMENT_FOLDER]“”/> </Target>

XCopy basically copies all the output files made by your build script to the appropriate folder.  The great thing here is only the files necessary to run the application will be deployed. Your .cs, .csproj, etc. files wont go to your deployment environment.

After you check-in the TFSBuild.proj file, you should have automated builds and deployments ready to go when you check-in your code, or if you queue up builds yourself. Good luck. :)