Common Build Scenarios | Professional Team Foundation Server

We spoke earlier in this chapter on the different ways projects can be built. Some organizations use nightly builds, some weekly, and some even implement a process called continuous integration, where the application is built multiple times during the day and night.

In this section, we are going to look at these scenarios, and examine some ways we can use Team Foundation Server, as well as other tools, to implement them.

Typical Builds

When we refer to a typical build, we are talking about kicking off a build type from within Team Explorer. We discussed how to do this earlier in the chapter. Just right-click the Team Builds folder in Team Explorer, and select Build <Team Project>. You always have the option of starting a build whenever the mood strikes you, by using either Team Explorer or the command-line tools.

For a more structured approach to building your apps, you will need to use the command-line tools, as well as the Windows Scheduler, as the next section shows.

It's worth pointing out here why you might be interested in different builds. You may want to run a build every hour that does compilations only, but no testing. This would help ensure that only code that compiles is being entered into the repository. You may then want a nightly build that, besides running the compile, does some basic testing. Finally, you may want to have a weekly build that does all of the above, but with more extensive testing.

Nightly Builds

A nightly build can be a good indicator of the health of your application and of the daily progress the developers have made with the application. By viewing the results of the nightly build, you can gain a better understanding of where problems are occurring in the development process and take the appropriate action.

This first version of Team Foundation Server does not automate the process of a nightly build for you. To implement nightly builds, you will need to make use of the Team Foundation Build command-line tools and the Windows Scheduler.

Before you begin, make sure your drop directory folder (the folder where the build will be placed once it has been created) and all server permissions have been configured. Also, make sure you have created the build type to be used.

Once that has been done, you need to create a batch (.bat) file on your build server. This batch file will contain all the build commands you wish to run. For example, you could create a batch file called nightly.bat, and put this following line of code in it:

 TFSBuild start MSTFS TeamProject1 BuildType1 /machine:TFSBuild /d:C:\Drop1

When this batch file is executed, it tells the command-line tools to start executing a build, using the Team Foundation Server named MSTFS, the team project named TeamProject1, and the build type BuildType1. In addition, it specifies using the build machine TFSBuild, and using C:\Drop1 as the location for performing the build. This would override these same values located in the build type.

At this point, any time we wanted to run a build using these parameters, we can just run this batch file. So how do we get this to run on a nightly basis? That's where Windows Scheduler comes in.

Open Windows Scheduler by going to Control Panel and double-clicking Scheduled Tasks. Click the Add Scheduled Task option to start the Scheduled Task Wizard. Click Next to move off the first page of the wizard.
Click Browse, and select the batch file you just created. Go ahead and name the task. Set the frequency to run daily, and specify the time you would like it to run at.
Finally, select an account with the appropriate rights to run a build on the build server. The account should have the Team Foundation Server Start a build rights. Otherwise, you will be unable to run any build commands from the command line. Click Next to finish and close the wizard.

At this point, your nightly build is ready to go. If you wanted to change the build so that it runs over a different period, such as weekly, all you have to do is modify the scheduled task appropriately.

Weekly Builds

A weekly build is pretty much the same thing as a nightly build, executed once a week instead of every night. Some organizations find it more effective to view their code over this extended period.

To implement a weekly build, you follow the same steps as outlined in the previous section on nightly builds. However, when configuring Windows Scheduler, set the schedule to run weekly instead of daily.

Continuous Integration (CI)

Kent Beck, in his book XP Explained, defines continuous integration (CI) as the process of integrating and building the system every time a task is completed. CI is used extensively by Agile methodologies (www.agilealliance.com), which use the status of the build as a key indication of project performance and progress. You can learn more about Agile methodologies in Chapter 6.

Let's discuss a little of the theory behind CI, and some things to think about if you are considering implementing it. For CI to be effective, two things must be true. First, any code that is checked into the version control system must compile. If a developer checks in a piece of code that he knows is broken, then he knows the build is going to fail. Second, all your unit tests should be in the version control system, and should run successfully against the code in the system. This allows you to keep a history of your tests, and to ensure your app is meeting the functional requirements.

For the above conditions to work effectively, your developers need to be checking their code in frequently. If a developer keeps code out for an extended period, his portion may work when he checks his code back in; it may, however, break the code of others, because their updated code does not play nice with his. Besides checking in his code frequently, a developer should also grab the latest code of the other developers from the system and run it against his code changes before checking his code back in. This helps to ensure that his code runs effectively with the latest changes in the version control system; it also helps to ensure an effective build of the entire application.

One recommendation when implementing CI is to kick off a build any time new code changes are checked into the repository. While this may be an ideal case, in practice it can lead to problems, especially if you have a long build cycle, which could lead to overlapping builds. If you are interested in using Team Foundation in this way, you will have to do some custom coding. Chapter 9 provides an overview of the Team Foundation Object Model and Team Foundation Core Services, and is a great place to learn more about that.

Important

For a good example of how to implement continuous integration in this manner, check out the Vertigo Software Team System blog at http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/14/3075.aspx.

It might be more effective to use standard build times when implementing CI - for example, every hour or every four hours. You can easily modify the process outlined earlier in the nightly builds section to run on any CI schedule you would like.

You can read about Microsoft continuous integration and download a sample at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/ConIntTmFndBld.asp.