Version 2.6 of the Deployment Framework is now available (see the download links - the full download, core, and tools have all been updated.)  Future work in this area will be about augmenting the already-great deployment story in BizTalk 2006! 

The release notes below will (likely) only be interesting for folks that are using the framework extensively.

Interesting Features:

• If you populate the bizTalkHosts property with the name of the Hosts that you are using, the 'servicecontroller' nant task is used for the stop/start of BizTalk services, with a configurable timeout stored in the 'biztalkHostResetTime' nant property. This requires recopying the BizTalk.nant.tasks.dll to your \program files\nant\bin directory. This alleviates the problem some users were having with timeouts in service restarts.
• IISReset now uses configurable reset time from nant property iisResetTime.
• Modified the sample application to demonstrate how you can maintain adapter configuration in binding files (i.e. the TransportTypeData sections) in its "unescaped" form -- rather than having to maintain it as escaped xml-within-xml. This relies on a new tool - ElementTunnel.exe, which is also in the Tools download. This is a huge help with adapters such as MQSeries that have many configuration elements.  More on this in another post.

Administrivia:

• SSOSettingsFileImport.exe opens files with read access only, eliminating some file locking issues.
• Permissions on the physical directories associated with virtual directories are now granted to the account specified as the application pool account (instead of just aspnet account.)
• Now using NAnt .85 RC3
• Now using log4net 1.2.9 (thanks Campbell McNeill for work on this!)
• Now using the July 2005 release of WiX (thanks to Loren Halvorsen for work on compatibility with this.)
• Now using XmlPreProcess 1.0 RC3 (and the associated SettingsFileGenerator.xls.) One new feature here is the ability to use URLs that contain query strings in the spreadsheet. The name/value pair XML files that are generated will wrap as CDATA where appropriate. Thanks Loren!
• Modified the sample application to demonstrate how file receive and drop locations can be made relative to the a) project directory on a developer workstation or b) installation directory on a server. This has actually be in the sample application before - but it relied on the xmlpoke nant task, whereas now it uses the XmlPreProcess mechanism we use for all other binding file modifications.
• Modified the deployment verification unit test in the sample application to rely on a NUnitUtility helper class that you can pull into your own projects. One included method allows you to examine the event log (on multiple machines) looking for errors that BizTalk might have raised during the test - very handy, and a potentially important component of your test.
• Support for a local_settings file used with XmlPreProcess. It can be handy to have an "environment specific" set of macro values that are particular to a local workstation, and the sample application shows how this is done now.
• Added transforms and schemas to the list of what is re-gac'd for the updateOrchestrations target. See here for more detail. In a recent release, I made changes that allowed for the use of a single binding file, so that binding files as emitted by the deployment wizard could be used (rather than splitting them by hand, which was required early on with the Deployment Framework.) This was a good change…but the implementation broke the "messaging only" scenario (where you have no orchestrations.) I don't have a good fix for this yet. The workaround is as follows: In your project's nant file, set includeOrchestrations to "true" (even though you don't have any), and define the orchestration assembly list to be an empty string, as shown here:
  <property name="includeOrchestrations" value="true" />
<property name="orchestrations" value="" />

How do you upgrade?  Extract the "core" zip file on "top" of your existing project, and then fix up the WiX directory manually (since it will be named BizTalkSample.WiXSetup after the unzip.)  All tools and scripts will be updated as a result.  Then test...Leave a comment with any issues you encounter.  Good luck!

Just a few notes on what I'll be up to in the next month or two...

Do you use the Deployment Framework for BizTalk?  Or just have general questions on automating BizTalk deployments?  You can attend my session at TechEd 2005 - Friday June 10^th, 10:45am to 12:00pm in the BPI Cabana, where I'll be doing a talk on those topics...

I'll also be speaking at the Microsoft DevCon event on my "other favorite" topic, Windows Mobile.  The focus will be on what is new for Visual Studio 2005 in the mobile arena...The conference will also be covering the new Team System offerings, ASP.NET 2.0, and quite a few other VS2005 topics.  Check it out...

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

In the latest release of the Deployment Framework for BizTalk “extra tools”, you will find a script that will automate the creation of “external tools” in Visual Studio that are useful for working with BizTalk 2004 and the Deployment Framework.  Modify the script to include all the tools that your team relies on, too.

The idea that this should be automated came from Ben Cops (though I’ve heard the complaint before!)  Manually creating all the useful external tools was somewhat painful for a large team of BizTalk developers.

After you run the script, your Tools menu in Visual Studio should include entries for deploying and un-deploying the current solution, as well as for updating just the orchestrations, .NET components, and SSO configuration data (one menu entry.)  In addition, there will be entries for running NAnt on a highlighted target name (useful if you have your build script open), and for running HAT and the Subscription Viewer.  Enjoy…

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

Just when you thought automated deployments for BizTalk 2004 were safe, another update to the “Deploy with NAnt” template comes along… :) 

This is a very worthwhile "upgrade" to consider taking advantage of.  One of the big items is support for "configuration info within SSO", but a complete list of features/fixes, etc. is below. 

SSO Integration: If you are currently using the SettingsFileGenerator.xls spreadsheet (discussed in previous entries) in conjunction with the XmlPreProcess tool to handle "environment-relative" configuration - that is, to handle variations between your dev/QA/production environments - you will be glad to know you can get more leverage out of that process now…

To review, with this process, you use the names that are defined in the first column of the SettingsFileGenerator spreadsheet (shown below) as "tokens" within your binding file, as in: 

At install time, the value for FileSendLocation that is appropriate to the environment you are deploying to is "plugged in" by XmlPreProcess (but for developers, the file remains legal XML.)  The spreadsheet might look as follows:

(click)

Now, however, you can also put in name-value pairs (whether they vary by environment or not) into the spreadsheet that you need access to at run time (i.e. general configuration information.) 

The name-value pairs will be deployed into a newly created affiliate application within the SSO, and can be read using the SSOSettingsFileReader class (which serves as a cache, too – and is provided in the download.)  The static methods on this class can be used from an orchestration expression shape, or from assemblies that orchestrations call – as in string test = SSOSettingsFileReader.ReadValue("BizTalkSample","SomeAppConfigItem");  (By the way, the “nested names” shown in the spreadsheet above are just meant to suggest a partitioning mechanism you might want to use, rather than one flat “namespace” of config data.)

Of course, the deployment scripts handle all the interaction with the SSO database for deployments/un-deployments.  This whole mechanism (SettingsFileGenerator.xls, XmlPreProcess, and now SSOSettingsFileImport.exe) is worth using even if you don’t use the rest of this script infrastructure.  Note that Jon Flanders had a great article on SSO-based configuration using a strongly-typed approach, where as this approach is loosely-typed, but leverages a mechanism you might already be using (i.e. the spreadsheet concept.)  (Note: Jon’s code for creating/deleting affiliate apps helped me complete the SSOSettingsFileImport.exe utility quickly…) 

Other features/fixes: 

• Support for multiple schema assemblies, including the case where schema assemblies reference each other due to schema imports.  (Undeployments occur in reverse order of deployments.)
• Support for multiple orchestration assemblies, including the case where orchestration assemblies reference each other due to the use of Call/Start Orchestration shapes.  (Undeployments occur in reverse order of deployments.) 
• Support for multiple orchestration and port binding files (just list them as comma separated values in the orchBindings/portBindings properties.) 
• Fixed bug that occurred when undeploying ISAPI extensions in Windows 2003 / IIS 6. 
• Fixed bug in undeploying pipeline components (thanks to John Adams) 
• Added /NOFORCE flag to IISRESET calls in accordance with http://support.microsoft.com/kb/286196 
• New property "includeInstallUtilForComponents" was added, which can be set to 'true' in your project-specific nant file.  This will cause your component assemblies to be called with "installutil.exe" (with the /u flag for undeployment.)  This is useful if you have .NET Installer-derived classes that need to get called for creating event sources, perf counters, etc.  (Yes, you could certainly argue these should be called by the WiX piece of the script infrastructure instead, but this method works and is more in keeping with the spirit of the entire process.)  Note there is no harm if a given component assembly listed in your components property does not have an installer class. 
• Eliminated the need for the includeCustomTarget property, and provided additional ways to supply custom functionality.  Project-specific nant file can now supply any or all of customDeployTarget, customPostDeployTarget, customUndeployTarget, customPostUndeployTarget -- and they will be called if they are present. 
• Integrated the deployment of log4net-specific stuff, if the includelog4net property is set to true.  See the work on BizTalk/log4net integration for more information.  (Log4net sample usage is included in the new sample.)   
• Now using NAnt version .85 - so be sure to grab the latest NAnt/NAntContrib since the nant scripts are using .85-specific syntax to avoid "deprecated" warnings that were occurring otherwise.  Note that even once you have installed NAnt .85, you will still be able to deploy BizTalk projects that are using old versions of the deployment scripts.  Note also that this is a pretty basic port to .85 - there are no doubt more elegant ways of doing lots of things that I haven't investigated yet, now that nant has expression support. 

Other notes 

The scripts like to see BizTalk projects using Debug and Release for target names.  A long while back I had suggested a file-level search/replace within btproj files to change these, but two more elegant options are available: 

• In project properties, change the output location for the “Development” configurations to “bin\debug” and output location of “Deployment” configurations to “bin\release”.
• (Via Puneet Gupta): Change the template for BizTalk projects, found in BTSApp.btproj file in %BizTalkInstallDir%\Developer Tools\BizTalkWizards\BTSApp\Templates\1033, to reflect Debug and Release targets. 

Another note: Lots of folks have noticed that XmlPreProcess can be used for a lot more than port binding files!  Log4net config files, orchestration binding files, you name it.  See the full Word documentation in the download for an example of how to do this within customDeployTarget.

How do I upgrade?

1. With a safe copy of your BizTalk solution, expand the “Core” zip contents right on your project directory, such that the core scripts will overwrite what you have now (but your project-specific scripts will be preserved.)
2. Manually copy the WiX-related updates to your *.WiXSetup directory, since they will get unzipped to BizTalkSample.WiXSetup
3. Do a deployment on a developer workstation and a server to test things out…

Downloading

• You can always use the right-hand links on this blog.
• Full sample here, core scripts here
• GotDotNet workspace here.  Because of issues with GotDotNet, I’m only going to be keeping the EXE utility source code up to date – not the entire sample & core tree.

 Enjoy – comments always welcome and appreciated.

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

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

It has been several months since I initially posted on the topic of using NAnt to coordinate the deployment of BizTalk 2004 solutions, with updates here and here.  Since that time, I've been heads-down in a BizTalk project and have had a chance to refine the practice quite a bit.

So, I took the opportunity to introduce quite a few improvements into the sample I had previously released - hopefully turning it into a "template" that can be used on your projects more easily.  To that end, I've created a GotDotNet workspace where you can download the current version of the build template, and I invite any feedback/suggestions/participation.

The major changes I've introduced can be categorized as follows:

• Split binding files: On a BizTalk project with multiple developers, I believe it is beneficial to split your binding files into content related to orchestrations vs. content relating to "everything else" (send ports, receive ports, etc.)  The new build template sample does just that.
• Improved scripts: Many of the WMI-related scripts I relied on in the past were from BizTalk SDK samples.  These were modified to get better/different error handling behavior.
• More generic handling of send ports, receive ports, receive locations, etc. in the script - though it still requires some maintenance.
• Better NAnt citizen: I'm still not a NAnt expert by any stretch, but thanks to Duncan Millard I realized that I had been remiss in applying quotes to a good deal of the text names I was using (i.e. &quot).  In addition, I started using built-in NAnt tasks for at least a few items where I had overlapped functionality, though not in cases where I needed slightly different behavior.  Finally, the build file naming convention proposed by the build template is "BizTalkSample.sln.deploy.build" (rather than "BizTalkSample.sln.build") to avoid conflicting with a NAnt file that would actually be used to build the project (e.g. with Cruise Control), as opposed to deploying it.
• Use of "Deploy with NAnt" in an MSI scenario: This is the biggest (and I believe most useful) change...Let me explain further.

As you study the build script, you will notice that it now also tackles such tasks as deploying virtual directories and applying permissions to them, patching binding files to match “local conditions”, etc. The initial goal here is to ensure that in a team development scenario, the amount of “out of band” setup required for any given developer to establish their BizTalk 2004 project environment is minimal – and that the current topology for the project is communicated efficiently (i.e. through the build file, as opposed to email or word-of-mouth.)

After a development team has spent weeks or months with this build script, refining it to represent their exact situation and deployment needs, a question might arise: Why not take this well-tested script and use it for production (or just non-development-machine) deployments as well?

To do this, it is helpful to agree that a two-phase deployment of BizTalk-related projects is both acceptable and useful. The first phase is an MSI-based installation that simply installs all of the BizTalk-related assets in a specific directory, but doesn’t deploy them to the BizTalk server. The second phase occurs when the user goes to the Start-Programs-YourProjectName menu, and chooses “Deploy YourProjectName”. The user also has the option to un-deploy (leaving the assets still on the file system until the MSI is uninstalled) or redeploy (to support the case where a single file is “patched”.)  See a picture of the Start menu created by the build template's MSI file.

The reason that two phases are useful is that if the deployment to BizTalk fails, we would like a complete log of the results (which in this sample occurs in the DeployResults directory) for analysis/diagnostics, and we would rather not have the MSI simply roll back. The same holds true of un-deployment.

Dual-purposing the NAnt file you have been maintaining for “real” deployments can be summarized as follows:

• Use the build template's approach (see BizTalkSample.sln.deploy.build in the download) for the “server.deploy” and “server.undeploy” targets, which make the build file able to work with “co-located” binaries in addition to the standard developer tree.
• Create a Visual Studio Setup project that deploys your BizTalk assemblies according to the pattern shown in the BizTalkSample.Setup project. Notice that this setup project includes the NAnt build file, the “DeployTools” directory (with our scripts), as well as a subset of NAnt in a subdirectory of our installation (so that we don’t rely on NAnt being present on the target server.)  It also includes a few convenience batch files referenced by our Start menu entries for invoking NAnt with specific targets.

The BizTalkSample.Setup project in the build file can be built, installed, and deployed to try this out.  (You will want to make sure you haven't already deployed in "developer" mode, because the "Deploy BizTalk Deployment Sample" passes a flag to the NAnt script that will skip the undeploy phase in order to speed up "clean" installations.)  Note that as your deployment grows more sophisticated - multiple hosts, servers, etc. - you will find the NAnt script requires additional properties to govern these variations between server deployments and developer-desktop deployments.

The build template sample also discusses the use of NUnit as a post-deployment verification process.  See the documentation in the sample for a full discussion --  basically all we are doing is making sure our MSI includes a subset of our unit tests, NUnit, and appropriate test files.  This is then wired up to the "Verify Deployment" Start menu option.  This can be an extremely effective means of ensuring your operations team has a means of testing the system interactively (not to replace standard automated heartbeat tests you might have…)

Peter Provost proposed a great generic approach to building BizTalk NAnt files a couple of weeks ago - and I shamelessly stole his approach to reverse the "orchestration ordering" property (very slick!)  If you do not wish to pursue the MSI option just discussed, and you do not wish to integrate the "out of band" setup actions discussed above (i.e. virtual directory creation, etc.), you might prefer his approach or you might want to push the build template sample provided here in that direction (i.e. more property driven.)  However, I believe tackling the kinds of concerns that we do here will generally mean that a real-world project will no longer have a generic-looking NAnt script. 

Again, you can download the build template sample here.  Enjoy, and I hope you find it useful.

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

I realized today that in the "deploy.orchestrations" target of the NAnt build file (discussed here) there is a bug in the ordering of operations.  The original file imported the binding file prior to deploying the orchestration - which doesn't work for a "first time" deployment. 

In addition, Hermo Terblanche made a good point (in comments) regarding piplines which are used by Send/Receive ports - i.e. the ports need to be removed prior to removing/updating the corresponding pipeline assembly. 

Therefore, an additional dependency has been added to the "undeploy.piplines" target - namely, "remove.ports".  This target will remove exactly one Send and one Receive port, the names of which are derived from the binding file.  This section of the build file will have to be customized for your purposes, just like the names and ordering of orchestrations.  Note that in my sample, the orchestration uses “Specify Now” ports, and removing the Send/Receive ports is probably not necessary.  However, for “Specify Later” ports (the more typical case) that use custom pipelines, you will get the error referenced in Hermo's comment if you do not remove the ports prior to updating the pipeline assembly.

The zip file with a new build file is still located here.  Current NAnt output from the sample will look like this.  Enjoy!

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

One of the more complicated aspects for a developer using BizTalk 2004 is the large number of steps required during the edit/run/debug cycle.  Since your BizTalk artifacts can't be run "in place" (that is, where they were compiled) but must instead be deployed to a local (or remote) BizTalk server, life can get quite complicated.

If you have done much BizTalk 2004 development, you know the routine quite well at this point.  If you have orchestrations, schemas, transforms, pipelines, and (say) C# components all partitioned into separate assemblies - and you have a number of orchestrations with "Call/Start Orchestration" shape dependencies that introduce specific start/stop-ordering - you can spend a lot of time doing the whole stop/unenlist/undeploy/redeploy/enlist/start/bounce BizTalk routine. 

Worse, you might not get it right - which can lead to hours spent debugging problems (over the course of your project) that don't really exist.

To alleviate this problem, it can be quite helpful to use a tool like NAnt to coordinate the "update my BizTalk server" process that must occur after each build.  (NAnt is a large topic - suffice to say it is an Xml-driven software build system.)  As long as your NAnt build file (and BizTalk bindings file) are kept up to date, the whole process can be reduced to:

1. Comple your solution (which might have multiple orchestrations, schemas, transforms, pipelines, and external components in separate assemblies)
2. Choose "Deploy to BizTalk" from your Tools menu.
3. Wait 60 seconds or so, enjoying the feeling that you have a consistent & reliable deployment mechanism.

In addition, you can of course use NAnt to kick off full unattended builds for nightly builds or continuous integration systems (like Cruise Control).  Since Visual Studio.NET is the only supported way to build BizTalk projects - despite that tempting XSharpP.exe file sitting in your BizTalk installation directory - this part of your NAnt build file must defer to calling devenv.exe in command-line fashion.  (A short "getting started" for NAnt & directions for using with a VS external tool can be found here.)

So, how about a sample that shows using NAnt to coordinate a reasonably complex deployment of inter-related BizTalk projects?  Available for download is a zip of a BizTalk solution that contains the following projects:

• BizTalkSample.Components (a C# project, with a class called from orchestration)
• BizTalkSample.Orchestrations (that contains two orchestrations, one which calls the other via a Call Orchestration shape)
• BizTalkSample.Pipelines (a send and receive pipeline, which are not needed but included to illustrate the deployment aspects)
• BizTalkSample.Schemas (which includes two schemas)
• BizTalkSample.Transforms (which contains a single transform used by one of the orchestrations)

The item I hope you will find most interesting, however, is a file called BizTalkSample.sln.build.  This is a NAnt build file that has a deployment target which captures the following dependency tree (only partially blown out here, for brevity - but this no doubt seems familiar to you if you've been using Biztalk 2004 for awhile…)

Deploy
   Deploy Schemas
      Undeploy Schemas
         Undeploy Orchestrations
            Unenlist Orchestrations
               Stop Orchestration
         Undeploy Transforms
            Undeploy Orchestrations
   Deploy Components
   Deploy Pipelines
      Undeploy Pipelines
         Undeploy Orchestrations
   Deploy Transforms
      Undeploy Transforms
         Undeploy Orchestrations
   Deploy Orchestrations
   Bounce BizTalk

Perhaps more illustrative is the output of the deployment itself - a sample of which can be seen here.  Note that the NAnt script relies heavily on the EnlistOrch.vbs and StopOrch.vbs script files that ship as samples with BizTalk 2004, as well as the BTSDeploy command line utility.

The BizTalkSample.sln.build script included in the download should represent a BizTalk project organization of sufficient complexity to act as a template for your own projects.  You will want to maintain the list (and correct ordering!) of the names of your orchestrations within the build targets for "deploy.orchestrations" and "unenlist.orchestrations" (this isn't deriveable automatically…)

Note that the build script relies on a set of naming conventions that will be evident once you spend some time with it - namely, that directory names correspond to assembly names.  In addition, the standard "Development" and "Deployment" configurations in BizTalk projects have been replaced with "Debug" and "Release", in order to not create inconsistencies with standard .NET projects (and allow for one "Configuration" property within the build script.)  This replacement was accomplished with a file-level search/replace.

There is probably room for more sophistication in this build file.  It takes a somewhat pessimistic view of what must happen for each edit/run/debug/deploy cycle, but I've found that despite the 60 seconds spent executing the script, your net productivity gain will be quite high given the time you won't waste trying to figure out what aspect of your deployment isn't correct.  Leave comments with suggestions for improvements, if you like.