With BizTalk Server 2009, setting up integration with Team Foundation Server (TFS) has become much simpler.  While setting up continuous integration, automated unit tests, and msi packaging was possible before BizTalk 2009 it was a huge pain. 

Below I will walk through the steps to set this up with BizTalk 2009.  I was able to get this up and running in about 30 hours including the time to create the Virtual Machine (that was 15 hours).  It took 47 build attempts in TFS before all the bugs were worked out in the process.  While I cut some corners for the demo it would not take much more time to develop a true production ready solution.

We can start by taking a look at the Virtual Machine setup:

  • Windows 2008 SP1
  • TFS 2008 SP1 with Build Server installed
  • SQL 2008 with all optional components installed
  • Visual Studios 2008 SP1
  • BizTalk Server 2009 with MSBuild tools installed

As you read though the steps below keep in mind I have about 10 hours of experience with MS Build and TFS 2008.  This was my very first time setting up automated unit tests and continuous integration with BizTalk.    This is just one approach for demo purposes.  In real life, for example, all these systems would not be on the same server.  This would surely make the process harder.

At a high level, this is what is happening:

Update to a file is checked in -> Build is kicked off -> Build completed with no errors -> Unit Tests are ran -> (Verification – Not Shown) -> MSI is created

Keys Pain Points:

  • Setting up TFS 2008 with SQL 2008 is many times more complex that you would think.  Make sure you Google this before starting.
  • Remember user permissions.  This will affect your share permissions, other folders, and the ability to run scripts.  For example, to run the Create MSI Process below the user running the Build Agent will need to be a BizTalk Admin.
  • Relative and absolute file paths are a killer.  I spent a lot of time finding temp locations and getting relative paths to work.  Looking at the Build Log and MSBuild Targets was a huge help.
  • Keep in mind TFS will use the version of code checked into TFS.  If you update a file or the build project make sure you check it in or the new settings will be ran.

Download the Solution Code

Setting Up Continuous Integration, Unit Tests, and MSI Creation in BizTalk 2009 Sample Code

Setting Up Unit Tests for use in Continuous Integration

Step 1:  Setup a Unit Test project following the help guide instructions at http://msdn.microsoft.com/en-us/library/dd224279.aspx

Step 2:  Create a Test List in the .vsmdi that was added to the solution when the Unit Test project was created.  Right click on the Lists of Tests.  Creating the new list named RunAllUnitTests is shows below.

 

Step 3:  Add the test methods from Step 1 to the new test list.  Drag and drop the test into the test list.  This is shown below.

Pointers:  The hardest part of setting up the unit tests is getting the file paths correct for Schema and Map testing.  I finally got tired of trying to figure it out and hard coded the paths to known local files.  This is not the right way to do it.

 

Setting Up Continuous Integration

Step 1: Add Solution to Source Control in its own folder tree.  In this case it is called CIDemo as shown below.

Step 2: Create a new Build Definition inside Team Explorer.

 

Step 3: Give the Build Definition a name. In this case it is called CIDemoBuildDefinition.

Step 4: Set the Workspace to the CIDemo solution folder created in Step 1.  This is shown below.

Step 5: Go to the Project File section of the wizard.  Select Create on the Project File screen to make a new Build Project.  A new wizard will open.

Step 6: Select the CIDemo solution.  This will be the solution that the build project will build.

Step 7: Select the build type.  In this case it is Release.

Step 8: Since we already created the Unit Tests and a Test List select the RunAllUnitTests test list to have the unit tests ran when a build is performed.  This is shown below.  This can always be updated in the build project later on if the Unit Tests are not ready.  Click Finish to end this wizard.

Step 9:  Back on the main wizard, leave the Retention Policy items unchanged.

Step 10: Under Build Defaults, select New to create a new Build Agent.  Name the build agent and set the computer name.  In this case the name is CIDemoBuildAgent and the computer name is Win2008Ent-Base as seem below.

Step 11: Set the Share location for the builds to be copied to, also known as the Drop Location.  A local share was created called Builds.  To ensure no permission problems Everyone was added to this share.  This is not what should be done in real life.  Most likely this would be on another server.

Step 12: Under Trigger, select the Build each chick-in radio button.  This will create a new build with each check in.  Click OK to create the Build Definition.

Step 13:  Test the process.  Check in a file.

 

Creating A BizTalk MSI

The process used here to build an MSI package first installs the BizTalk Assemblies and Binding file to a local BizTalk Server.  Then it exports out the MSI Package.  While other approaches can be used that do not require a local BizTalk instance, this approach would allow for additional BizUnit style Unit Test (or Build Verification tests) to be ran against deployed code. 

Step 1:  Modify the CreateFullandPartialMSI.bat sample file in the CreateApp folder under Application Deployment in the BizTalk 2009 SDK.  This file is called BuildMSI.bat in the Helper folder in the solution.  Changes made to the file include changing paths, dll names, and application names.   Make sure the order of the dlls is in the correct deploy order.  i.e. Schemas before Maps.

Step 2: Modify the Build Project created in Step 5 above.  This file is a MSBuild file that controls the build and tests ran against the build.  At the end of the file right before the closing </Project> tag add the following:

<!– This Target created a directory for the binding files and Copies them and the build bat file to the temp directory. –>
<Target Name="AfterTest">
  <MakeDir Directories="$(BinariesRoot)/Release/Bindings" ></MakeDir>
  <Copy SourceFiles="$(SolutionRoot)/Bindings/CIDemo_Bindings_Dev.xml" DestinationFiles="$(BinariesRoot)/Release/Bindings/CIDemo_Bindings_Dev.xml"></Copy>
  <Copy SourceFiles="$(SolutionRoot)/Helper/BuildMSI.bat" DestinationFiles="$(BinariesRoot)/BuildMSI.bat"></Copy>
</Target>

<!– This Target runs the build bat file, copied the completed MSI, and deletes the bat file from the file share. –>
<Target Name="AfterEndToEndIteration">
  <Exec Command="$(BinariesRoot)/BuildMSI.bat" WorkingDirectory="$(BinariesRoot)" ></Exec>
  <Copy SourceFiles="$(BinariesRoot)/CIDemo.msi" DestinationFiles="$(DropLocation)/$(BuildNumber)/CIDemo.msi"></Copy>
  <Delete Files="$(DropLocation)/$(BuildNumber)/BuildMSI.bat"></Delete>
</Target>

This code will copy the binding files, the bat file used to build the MSI, and do some clean up.  This can be customized as needed and the possibilities are almost endless.  Make sure the updated file is checked into TFS.

Step 3:  Ensure the user account running the build agent is a member of the BizTalk Admin Group.  This use can be found inside TFS by starting a build and viewing the properties as seen below.  This account is set up when you install TFS.

Step 4: Watch for output in the folder share when a file is checked in or a build manually started.

 

This outlines at a high level the process to create automated unit tests, set up continuous integration, and create a BizTalk MSI package.  I hope to put this together into a video shortly.  Until then, best of luck.