Creating a build project in TFS2008 is very easy.  This because you can create a standard Build using the build wizard.

Mostly you will create at least 2 builds

• Continuous Integration Build (CI): This wasn't possible in TFS2005, without doing some hard work in the build script.  Mostly you will check every x minutes if there are new check-ins done by the developers.  If so, we will start a build.  This gives us the possibility for having a rapid feedback on any breaking changes and more after each check-in.
• Nightly Build: This build will only run during the night and will perform several more tasks than the CI Build, like deploying your binaries to your test server,...

We will show you how to create a standard build.  You can add more features to your build script like

• Unit testing
• Code analyzes
• Code Metrics
• Deployment
• ...

Later we will show you how to implement those items.

OK, here we go.

You will see that creating a build under TFS2008 it’s much different than using TFS2005.  One of the big changes is that it will be easier to trigger events.  It’s all in the build wizard now.  So no more command lines, batch files and adding them to the windows scheduler.

One remark: Always keep in mind that your total length of the path (including filename) can be maximum 259 characters.  If the path is longer your build will fail.

1. Go to Team Explorer
2. Right click on builds and choose “New Build Definition”
   
   
   
3. Choose a build name.  Be aware for the path, as this will be a part of the path. And give it a description
4. Normally the workspace can be the default one
5. Next you have to add a new build project file.  You can use an existing one or create a new one.  Be sure to have defined the build name before this step.  You will see that the path to the build types is already filled in.
   
   
   
6. Take the option Create.  This will lead you to a new popup.
   
   
   
   Choose your solution.  You can change the configuration if necessary.  In the options tab you can if you want add unit testing and/or code analysis during the build cycle.  Press finish if everything is done.  Best practice on this is just doing a build before adding the extra tools.  When your build succeeded you can start adding the extra tools.
7. The next tab is the retention Policy.  Here you can say which builds you want to keep when a build was failed, stopped, partially succeeded or succeeded.  By default all builds will be kept.
8. The previous last step is the build defaults.  Here you define your Build agent and the staged location for your builds.  This is the most important part as you must define here the paths.  You can define one build agent for each Buildserver with the same port.  When defining the agent, you need to give the working dir.  By default this is $(Temp)\$(BuildDefinitionPath).  Mostly this will give you a path that is too long.  We create on the server a directory Buildserver, which will be also our share.  So for our working dir we got following path : x:\Buildserver\)\$(BuildDefinitionPath).  For the staged path we give in \\<servername>\Buildserver\<Team Project name>.  If you define it this way you will have following directory structure :
   
   
   
9. The last step before your build is ready is setting up the trigger.  This step was in TFS2005 very difficult especially when you want a CI build.  In TFS2008, this was made very easy.
   
   
   
   As you can see you can choose between different triggers. 
   For our nightly build we choose the last option with the default options.  So every weekday at 3 o’clock our nightly build will run, only when there are changes since the last build. 
   If you want a CI build, you can choose between the second and third option.  We have chosen for the third option and it will run every 15 minutes. Best practice is to start with the first option and when your build succeeded you can switch the trigger to the build type you want to use.
10. Now press OK and you can start with your builds.
    Now that you have your build script, you can double click on it to open the Build Explorer window.  On this window you can view complete builds and their logs.  You can follow which builds are in the queue and you can even start a build before it’s actual trigger by queuing the build.
    
    
    

If you want to change your build, you can do this again through this wizard.  Just keep in mind that some options aren't available in edit mode like adding your unit testing to the build.  So for those options that aren't available anymore you still need to change it directly in your build script.

Hopes this quick guide helps you to setup your first build project.