TFS Automated Builds

I was finally able to dedicate some time to investigating automated builds using TFS.  Over the past several weeks, our development team has been working to more formally embrace Agile, as a software development practice.  A couple key components we’re trying to leverage are available within VS 2008, team suite & Team Foundation Server (TFS), including automated builds, automated deployment and database source-code control, using VS DB pro (more on that soon.)

Today, i plowed thru documentation; we recently upgraded from TFS 2005 to 2008 and understand several things have been improved with regard to build to 2008.  While we began using TFS back in early 2006, we had yet to utilize the automated build capabilities.  After speaking with a few people, I was happy to see the improvements made in 2008, most notably native support for automated/nightly builds, and continous integration (CI) – both are now standard in 2008.  Previously, automated builds had to be setup to use a scheduled job, and batch file.  CI took even more work. 

After understanding the framework, I began to dive in, setting up our build server, and configuring the agent.  From there, the VS gui makes it very easy to configure.  Within an hour or so, I was able to setup a scheduled build, whereas the build server pulls the latest codebase, compiles and labels it, and publishes the binaries to a designated drop site.  pretty cool.

Originally, what we were hoping to accomplish with automated builds, was simplifying the process of moving the latest code base from source-control -> to our dedicated development environment, saving the team valuable ‘publishing’ time and giving QA an updated code base to review each morning.  While this is somewhat possible with automated builds, i discovered, atleast initially, the binaries published to the drop site contain unqiue folder values, identifying each build/version #.  This makes it somewhat difficult to publish to a dedicated environment, whereas IIS/virtual directories use a static location for content.  I am still investigating options, to see if this is possible.

While doing some digging, I recently came across Scott Guthries post on a VS 2008 web deployment project, rtw (released to web.)  From the sounds of it, it provides more granular deployment options, including pre/post compilation as well as managing connection strings between environments, whereas your DEV/Staging/Production environments need to point to different datasources.  If you’re also working to incorporate an automated build/deployment model, you might want to also check out the Web Deployment Tool, by the IIS team.  Needless to say, automated deployemnt is now next on my  “to do” list. 

I’m hopeful within a few days, I’ll be able to incorporate a basic, automated nightly-build process.  A little later down the road, we’ll look to leverage CI and setting more granular build qualities.  Baby steps for now..