Zero-downtime deployments / upgrades with BTDF

Topics: General Questions, Server Deployment
Apr 8, 2011 at 4:10 AM

Hello All,

We have been using BTDF on our project so far and it has been working really nicely for us!

We're just starting to run through our core upgrade scenarios and were wondering if it is possible to do zero-downtime deployments with BTDF?

We've got a mix of most of the usual BTS bits - schemas, maps, orchestrations, pipelines, pipeline components (no BAM at the moment). The environment has multiple servers in a group (configured for high availability).

Cheers,

Keith

Apr 8, 2011 at 6:17 AM
Edited Apr 8, 2011 at 6:17 AM

Doing a bit more prototyping it looks like the SxS feature could be useful here.

A test of a messaging-only solution using the following config: EnableSideBySide = true, DisableAutomaticPortNumberVersioning = true, SkipRestartHostInstances = true, IncludeMessagingBindings = false. We've been able to deploy a new version, move the send/receive ports from the old version to the new version then decommision the old version without noticing any downtime or suspended messages.

Any thoughts on using this kind of upgrade process?

Coordinator
Apr 11, 2011 at 7:23 PM

Hi Keith,

I'll admit that servicing without application redeployment is not a strong point of the Deployment Framework.  However, many or most of the tools to do it are already present, as you started to discover.  MSBuild is very flexible, so it's easy to override existing functionality or extend it in various places.  You can pass in any of the property values on the command line, so if you wanted to create a PowerShell or other script to drive a servicing deployment, you could certainly do that.  It could pass in the appropriate property values and turn on or off certain deployment steps.

Depending on how you wish to handle assembly and app versioning and the degree of code changes, many people just rebuild some of the DLL's and redeploy them onto the server with Gacutil.exe.  It's OK to do that if you're just changing some code internally and are OK leaving the assembly version numbers the same (or dealing with dependency issues manually).  However, that approach won't work if you're changing schemas, changing ports on orchestrations, etc.

I don't see anything wrong with the solution you described if it's enough to cover the type of changes that you need to deploy.

Thanks,
Tom

Apr 13, 2011 at 8:37 AM

Hi Tom,

Thanks for the reply. I like the idea of the powershell script to drive the deployment. I'm thinking that this, coupled with the side by side deployment features should do the trick. We've run through some more test scenarios - orchestration, messaging, custom pipelines, transformations and with a bit of manual fidding around (which we can hopefully automate with PowerShell) the SxS deployment seems to do the trick! We've been able to do some simple updates on our applications during a load test with no downtime or lost / suspended messages which is a good start.

Cheers,

Keith

Coordinator
Apr 13, 2011 at 4:09 PM

Great, thanks Keith!  I'm sure there are plenty of other users (myself included) who would be very interested to hear more about your strategies and methods once you finalize everything, and if you are able and willing to share.  This is always a tricky area when dealing with BizTalk.

As for PowerShell scripts, take a look at the Sprinkler project by Giulio Vian.  It's built with PowerShell with the goal of eliminating all user interation with a deployment across an entire BizTalk server farm.  The project is in beta form and probably light on documentation, but hopefully it will give you a jumpstart.

Thanks,
Tom