Using the TFS Build Process to Deploy Sharepoint Custom Applications

Automated builds have become a best practice in the software development world. For some shops that modify third-party applications, there is a need to know how to implement these builds into their development practice. You'll go over how to create an automated build script for your custom Sharepoint application using Team Foundation Server and Visual Studio Team System. Along the way, you will learn the benefits of using Team Foundation Server (TFS).

Creating a Build Script for Your Sharepoint Application

The system requirements I will be using are the following:

Visual Studio Team System 2008 (you may be able to use Visual Studio Professional 2008)

Team Foundation Server 2008

Sharepoint 2007 (WSS or MOSS)

SQL Server 2005

When implementing agile methods in your development process, there are many tools to use. Automated builds (specifically, continuous integration) are one such tool. Automated builds help create a consistent application deployment process. Coming from a web development background, automated builds help standardize the steps needed when deploying your web application. If you are following Agile principles so that you have working software after each iteration, this helps when you deploy often. As they say in Chicago, "deploy early and often". I may have paraphrased that a bit.

You will look at automated builds for what I consider the standard enterprise environments for custom web applications. The environments I refer to are the different servers an internal development shop might use.

In most enterprises, you have a development server environment, a QA (testing) server environment, and a production server environment. I assume the development environment is a common server (or server farm) that all developers can access as administrators. No customers have access to the development server, except in rare circumstances (to show a feature that isn't in the QA environment for quick feedback is an example).

The development environment is always in flux, so you can't expect that environment to have the latest stable build. But, this is a great environment to test your staging build scripts against. Once you are confident in the builds deployed to this environment, those scripts can build and deploy to the staging server.

The script you are going to create is for the development server, which I call the daily build. This build script normally compiles, runs automated tests, and deploys the latest source code to that server in a consistent manner (usually daily). Normally, this build runs off-hours (1:00 am or sometime around then), to avoid colliding with check-ins from developers.

The Daily build script you will create does not build a release version of the code; that is covered by a different build I normally call staging. The Daily build can run longer-running unit tests than you might run in your Continuous Integration build. The Daily build is designed to help you build confidence in your other deployments.

Using TFS as Your Build Engine

Team Foundation Server (TFS) from Microsoft utilizes uses the MSBuild language as its scripting language. There are other great build tools—such as nAnt, CruiseControl.NET, and other tools—but TFS has advantages. TFS integrates a robust Source Control engine, Work Item tracking, and other benefits into the software along with a build engine. Depending on your budget, you may find that you need these advantages that TFS offers.

TFS Features:

Easy to create first time builds with wizards (see Figure 1).

Uses MSBuild.

Integrated with checkins to TFS Source Control for Continuous Integration.

One click to add MS Tests Unit tests to your build.

Force developer rules on checkins (such as making sure all unit tests pass before source is checked in), making your builds run cleaner.