(Update: See the latest on the Deployment Framework here.)

It has been about three months since my initial submission to the BizTalk 2004 developer competition that I discussed here.  The contents of that contest entry took a prize (woohoo!) but still left a lot to be desired…

Since then, I’ve had a chance to make what I believe are major improvements to the deployment story I’ve been discussing since last May.  In addition, I’ve had a chance to see the practice being used across several large BizTalk projects, and have done a lot of learning as a result.  (No guarantees or warranty implied, but derivatives of the scripts/tools I discuss here have been in use for some time by a very large BizTalk customer I work with.)

The most important changes you will see in this release are as follows:

  • The “core” NAnt functionality has now been separated from the piece that an individual BizTalk project must “own” and maintain.  This is a huge simplification, and allows for more rapid adoption -- as well as the ability to deploy bug fixes & feature enhancements in a way that just wasn’t possible when stuff was intermingled.  (Peter Provost was right about that aspect of my first attempts.)  The NAnt script that a particular project must own can now be reduced to the following for a simple case (notice the ‘include’ reference for the core):

    <project name="BizTalkSample" default="debugDeploy">
       <sysinfo/>
       <include buildfile="BizTalkDeploymentInclude.nant"/>  
       <-- Set following properties to true or false to 
    include various pieces of a BizTalk deployment. -->
       <property name="includeSchemas"  value="true" />
       <property name="includeOrchestrations" value="true" />
       <property name="includeTransforms" value="true" />
       <property name="includePipelines" value="true" />
       <property name="includeComponents" value="true" />
       <property name="includePipelineComponents" value="false" />
       <property name="includeCustomFunctoids" value="false" />
       <property name="includeVocabAndRules" value="false" />
       <property name="includeVirtualDirectories" value="true" />
       <property name="includeMessagingBindings" value="true" />
       <property name="includeDeploymentTest" value="true" />
       <property name="includeCustomTarget" value="true" />
    <project/>

  • You now have the ability to supply a simple xml-driven Wizard-based UI when you are deploying after an MSI install.  You can use this UI to gather Windows identity information for virtual directories (for SOAP/HTTP receive ports), to indicate whether the scripts should deploy to the BizTalk management database (for working in BizTalk groups), and for many other purposes.  I call this “Install-Time Configuration” in the documentation below.  Here are some example Wizard screens:

    >

  • You now have the ability to have an Operations-managed “spreadsheet-driven” mechanism for environment-relative configuration.  What do I mean?  I mean those aspects of your deployment that are particular to your development, QA, or production BizTalk environments.  Aspects that wind up appearing in your BizTalk binding files!  Queue names, database names, file shares, FTP locations, etc.  This is information that you don’t want to manage with the Wizard UI above (there is too much of it) and you want to maintain “as a set” for each environment.  The spreadsheet (pictured below) can start life with your developers, and ownership can gradually migrate to Operations.  This spreadsheet generates environment-specific “settings” files, and at the point you deploy, the values for the environment you are deploying to are automatically substituted into your binding file…Slick!

    Image0051
    (click)

  • You now can use a highly templated (reusable) WiX based setup, rather than a Visual Studio Setup Project, to generate your MSI.  WiX, in a nutshell, is a set of tools and an Xml grammar that allow you to specify the contents of an MSI.  One of the clear pieces of feedback I got on the last rev I released is that reproducing a Visual Studio Setup Project was far too manual.

There are a large number of other changes that I’ll just enumerate quickly here:

  • You no longer need to have your NAnt file enumerate your orchestration names or their deployment order – a new custom NAnt task eliminates the need for this.
  • You no longer need to have your NAnt file enumerate how many receive ports/send ports/etc. you have – a new custom NAnt task eliminates the need for this.
  • Support for BizTalk groups, where machines 2-n do not require deploying to the BizTalk management database.
  • Support for not following the naming recommendations I made in previous releases – you can have custom project names, assembly names, directory names – its just a little more work.
  • Support for multiple assemblies of the various types (i.e. multiple orchestration assemblies, schema assemblies, etc.)
  • Inclusion of a utility I call SetEnvUI.exe for creating the xml-based wizards described above.
  • Inclusion of a utility I call DeployBTRules.exe for deploying BizTalk Rule Engine policies and vocabularies.
  • Inclusion of Loren Halvorsen’s XmlPreProcess tool for managing the environment-relative configuration discussed above.
  • Support for creating IIS6 application pools (with specified Windows identity) for HTTP and SOAP-based receive locations, and for adding virtual directories to application pools.
  • Support for registering the btshttpreceive.dll ISAPI extension with IIS6.
  • Support for selectively restarting multiple BizTalk host instances, for deploying custom functoids, and for dealing with send port groups, and more…

There are now two downloads.  The first contains all of the core scripts and utilities plus a sample BizTalk solution that uses them.  The second download contains just the core scripts and utilities, and is designed to allow a BizTalk solution to accept updates/bug-fixes/etc. over time (i.e. the zip can be expanded into your directory structure on a developer workstation so you can test it out.) 

It should be noted, though, that some manual work will be required to “upgrade” from the previous version I released in September – this release is quite different, but I think you will find it is well worth the time.

Full download is here.

Core scripts and utilities only are here. 

GotDotNet Workspace is here.

The full documentation for this release (which includes more detail than this blog entry…) is included in the zip files, but it can be viewed directly here (with a diagram here.)

Enjoy!  And remember: if you didn’t make into a given environment (QA, production, etc.) with a scripted deployment of some kind, you didn’t get there at all.

(Not necessarily this stuff, but something automated, at any rate…)