Build automation and more specifically deployments are one of my favorite things to do with Team Build in Team Foundation Server 2008.  Deployments are not an “out of the box” feature but there are several ways to accomplish this.  I am going to cover some of these different approaches and strategies for doing deployments with TFS.  Before I get into doing the actual deployments, I want to give a some background and guidance behind why creating automated deployments are part of a good software configuration management (SCM) process. Then I will go into creating a MSI that supports automated deployments.   The subsequent posts will cover a variety of topics including deploying the MSIs with Team Deploy and deploying Click Once applications.  Lastly I will explore what automated deployments will look like in TFS 2010.  As always, if you have any questions or if there is something you want me to see, send me an email, tweet, or comment.

This deployment process has been an evolution of the past 3 years.  I began getting engaged in this process when I used to be part of a process where the development team created a MSI for test and a couple weeks before production our PC configuration team would create a new MSI with their tools.  We would do some testing of this MSI over those couple weeks before going to production.  Unfortunately this process led to a few mistakes, mostly due to the fact we were changing too much too late in the game.  We began to think of an improved process with better configuration management in mind.  We created a few rules to that we wanted our new process to follow. 

Rules for MSIs

• Create the MSI early in the development process – As early as a development team has most of the projects for the deployment created, compile the assemblies and create the MSI.  For Agile teams this can be as early as Iteration 1.
• Create a MSI that is easily updated – MSBuild and Team Build by default do not support building setup projects.   There are some workarounds to being able to build a MSI, but I prefer creating the MSI and choose “As  loose, uncompressed files” for the build in the setup project properties.   This will leave the files out of the MSI and basically add pointers to the files in the MSI.  This makes updating the MSI as easy as using the copy task.  If a new project is added to the solution, add the new dependency, rebuild the MSI, and add the new assembly to the copy process (more on this later)
• Config files – This could probably be a post by itself.  Basically there are a couple rules I have about config files. 
  • The config files for all of the environments must be checked in to source control.  Usually I will create a library project in the solution and add all of the config files to it.
  • Along with all of the files being in source control, there can be no editing or copying of config files once the application is deployed.  For too long I would always copy the config file from the installed location.  Then I would do the uninstall, reinstall, and then copy/modify the config file based on the one I copied to another file.   I did this because I didn’t know if there were changes or particular production settings that were not in the MSI.  
  • Lastly the MSI should contain all of the config files for all of the environments.  These can be removed after the installation process is done but the key is that the config files are not copied from another location.  This will become more clear when I start to walk through the process.
• Because the MSI contains the config files for multiple environments, the user must be able to select the appropriate environment to install.  The MSI should allow the the user to specify the environment in the wizard or through a command line argument when installing it in quiet mode.
• If the MSI is a windows service, the user must also be able to specify the username and password through the wizard or command line.

By following these rules, it provides the following enhancements

• Tested and Proven MSI – Just like we shouldn’t deploy code that we haven’t tested, the same is true for the deployment process.  By using the same MSI in the Test environment, throughout the development cycle, and in production, this will help ensure that that are no surprises when deploying to production.
• Ready for Automated Deployments – The MSI will include key features that are required for use in automated deployments.   These include the config files for multiple environments, easily updateable from Team Build, and supports passing environment and username/password by command line.

In the next part, I will go over the steps and processes for creating a MSI to support these rules and help enforce your configuration management process.  I will demonstrate how to do all of this within Visual Studio without using any 3rd party tools.

Mike