(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!

    (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…)