Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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:InetpubwwwrootwssVirtualDirectories36917”. 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.
Creating the Automated Build
Remember, you have a Visual Studio solution that includes four different projects. You want to deploy the DLLs from three of the projects. Because you have created some unit tests testing your business objects against mock objects, you want to run those tests. This article assumes that your builds want to run your mock objects tests, and verify they still pass, before you deploy your application.
I mentioned earlier that the Daily build can include longer running tests. I haven’t included longer running tests in your Unit Tests for this sample; you only run mock object tests. In VSTS, you created a test list called Mock Objects. Oddly enough, the Mock Objects test list only includes tests that run against mock objects! You do not include tests that would run against a real database. For the mock object testing, you are using the open source mock framework moq.
Now, step through creating the build first by utilizing a wizard. You open the build wizard, by going to team explorer, and in the workspace for this project, right-click on builds and select “New Build Definition.” This brings up a screen similar to Figure 3.
Figure 3: What the New Build Definition looks like.
Walk through the build definition. The sample build definition is called Daily Build. A nice feature is the Retention policy that automatically allows you to set how long to keep your different states of builds. For instance, for failed builds, you can keep all of them, or the last two. The same goes for Successful builds, and partially completed builds. In the Trigger tab, make sure to fill out how often you want this build to run. Because it’s a daily build, I would select Monday–Friday at a later time, say 3:00 AM, or another time when most developers won’t be working on the source. After filling the wizard out, you click OK, and an XML build file is created for you.
In the case of your sample application, the build file called TFSBuild.proj is located in the subdirectory that holds the Build Definitions. To deploy the right files to the correct directories on the Sharepoint server, you need to add some XML tags to the build project file, TFSBuild.proj. To do this, open your source control explorer. Navigate to the Team Build Types node of your workspace, and find the “Daily Build” folder. In this folder is the TFSBuild.proj file. I edit this file by doing a get latest, and then check out and double-click on the file in Source Control explorer.
When that file is open, you want to add some tasks to run after TFS completes its build activities, but before the agent exits. To do this, you will use the “AfterEndToEndIteration” target name in the .proj file. This is an event that the TFS build process looks for and that can be overwritten. See Listing 1 for an idea of what this might look like.
Listing 1
<Target Name="AfterEndToEndIteration">
<Copy SourceFiles="$(BuildDirectory)BinariesDebug
Eric.Landes.Sharepoint2007.AdventureWorksSample.
AWWebParts.dll" DestinationFolder="C:Inetpubwwwrootwss
VirtualDirectories36917bin">
</Copy>
<Copy SourceFiles="$(BuildDirectory)BinariesDebug
Eric.Landes.Sharepoint2007.AdventureWorksSample.AW_Dal.dll"
DestinationFolder=" C:Inetpubwwwrootwss
VirtualDirectories36917bin">
</Copy>
<Copy SourceFiles="$(BuildDirectory)BinariesDebug
Eric.Landes.Sharepoint2007.AdventureWorksSample.
AWObjects.dll " DestinationFolder=" C:Inetpubwwwrootwss
VirtualDirectories36917bin ">
</Copy>
<Copy SourceFiles="$(BuildDirectory)BinariesDebug
_PublishedWebSitesAWWebParts.ascx "
DestinationFolder="C:Inetpubwwwrootwss
VirtualDirectories36917usercontrols ">
</Copy>
</Target>
For this example, you have copied the correct DLLs from the build directory (that’s a built-in variable) to the destination directory. For clarity, this sample XML shows the directory you copy the files to. Use best practices in real life by utilizing variable names for the from and to directory names to keep your script flexible.
Now, you can run the build file. To test the build, in Team Explorer, find the Daily Build build definition, by expanding your workspace. You can start a build by right-clicking on that build node and selecting “Queue New Build.” Once the build successfully completes, you should see the Eric.Landes.Sharepoint2007.AdventureWorksSample.AWObjects.dll in the directory InetpubwwwrootwssVirtualDirectories36917bin. And then, you can see the User Control AWWebParts.ascx in the directory C:InetpubwwwrootwssVirtualDirectories36917usercontrols.
Now, to view the web part, add the Smart Control web part to a web page in your Sharepoint site. Configure Smartpart to display the AWWebparts User control. Violà, your web part is now displaying in Sharepoint. Now make some changes to the web part, rerun your daily build, and validate that your changes have been deployed to the page you just made.
Download the Code
Click here for the source code to this article. This is a large (1 Mb) file.
Summary
You have just automatically deployed your Sharepoint application using TFS as your build tool. Sharepoint can have some tricky differences in deployments (location of files, for instance) from a standard ASP.NET web application deployment. Despite those differences, you can automate your Sharepoint applications, just like your ASP.NET applications, and use these standard software engineering practices on your Sharepoint applications.
I went over a few of the advantages TFS gives you in deployment, the ease of setting up scheduled deployments, and the tight integration with VSTS.
About the Author
Eric Landes is a Project Manager/Project Lead for a large corporate IT department, specializing in developing custom Sharepoint applications. He has two years experience using Agile techniques in developing Sharepoint applications. See his linked in profile for more information.
