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.
  • Easy to start creating builds with Visual Studio projects without scripting.
  • Highly extendable.
  • Can link work items (bugs, stories, tasks, and more) to source code check-ins.
  • Robust Source Control included.
  • Customizable Retention Policy for builds.
  • Easy to set up Continuous Integration builds, or scheduled builds.

Figure 1: Sample of how the Build Wizard looks when creating a new build.

Because this is not an article just about the merits of TFS, I won’t go into every advantage listed. I will concentrate on the ease of setting up your builds, and extending those builds by using MSBuild coupled with the TFS build engine. Keep in mind that this article is based on using Visual Studio Team System as the IDE in conjunction with TFS. You can use other IDEs with TFS, but that is an entirely different article! This article sticks with the VSTS/TFS development combination.

The Application to Deploy

Sharepoint custom application deployment is not as straightforward as deploying an ASP.NET application. Sharepoint custom web parts get their configuration keys from the web.config in the Sharepoint web root. This makes automated deployment a little clunky when sharing that web.config with other custom web parts/applications.

You are going to concentrate on creating a build for a custom web part. Other areas that are tricky include deploying Sharepoint features. I may tackle that issue in another article.

The sample source code includes a Visual Studio solution with the custom object model project, a Data Access Layer (DAL) project, and the Web Parts project that utilizes those. Also, the solution includes a Unit Testing project.

The Sharepoint server you will deploy your custom application to utilizes Jan Tielens’ Smartpart. The Smartpart allows developers to develop standard ASP.NET user controls, and place them as web parts in your Sharepoint sites. User Controls allow you to design your interface more easily when programming. You can use ASP.NET web parts projects to create web parts, but I have found the Smartpart control easier to develop applications with.

When you deploy a Smartpart application, you will need to at least deploy your ASCX files to a User Controls directory and your DLL to the bin directory in Sharepoint. You may find a need to deploy your DLL to the GAC as well. Assume that your Sharepoint site, http://localhost: 36917, is the Sharepoint site you want to deploy your web part to. The actual directory to deploy to would look something like this: “C:\Inetpub\wwwroot\wss\VirtualDirectories\36917”. See Figure 2 for a better look.

Figure 2: Sample of how your Sharepoint directory might look like if it is on the C drive.

Your application is called AWWebParts. This application utilizes the AdventureWorks database that is available with SQL Server 2005. Therefore, the AW is part of most of these assembly names! The full assembly name is Eric.Landes.Sharepoint2007.AdventureWorksSample.AWWebParts.dll. You will need to deploy that assembly and the AWObjects and AW_DAL assemblies to the bin directory under the Virtual directory for Sharepoint.

That’s the application you are deploying. I also went over how you would manually deploy the different parts of the application after compilation. But, doing this manually does not give you a consistent, repeatable deployment that current software engineering disciplines demand.

More by Author

Must Read