Deploying biztalk on developer/build machines

Question

For eaach BizTalk application we have a setup.bat, which creates the BizTalk application, creates file drops, build code, gacs, registers resources, creates ports -using vcscripts- and applies bindings. We also have a cleanup.bat which performs the opposite of setup.bat

These scripts are then run via nant, and finally used by cruisecontrol.net. These scripts allow us to setup a BizTalk app on a machine with BizTalk and the latest source and tools downloaded.

What do others do to "bootstrap" BizTalk applications in a repeatable and automated manner ?

I've seen BizTalk nant tasks, are they faster than vbscript ?

The setup. bat runs slower on our BizTalk build machine by a factor of about 3 ! Disk, CPU, Memory, paging are all comfortable. A full build/deploy is taking 2 hours before any tests have run - have about 20 BizTalk apps and assorted C# services, custom components. Aside from a new machine, or rebuild - our build machine has 4 gig ram, dual hyper threaded cores and about 5 years old server- Any ideas ? What are you build machines like.

Answer 1

Michael Stephenson has written some great blogs on automated BizTalk builds, take a look at link text

We have used a utility which Mike posted to codeplex which will create an MS build script for a BizTalk application - this has worked very well for us. You can find this at link text

Answer 2

We use NAnt as well for our BizTalk deployment. Specifically, we use a combination of calling the BizTalk related NAntContrib tasks (which all begin with bts) and using the <exec> task to call the command line btstask.exe directly.

At some level, they are all using the same underlying technology to talk to the BizTalk server, so it's hard to say whether NAnt is faster than something like VB.

I will say that in my experience BizTalk appears to be a resource hog. Since it's hard to change that, the only thing we do have control over is the amount of resources we give it. Therefore, if builds are taking too long, and one has the time/money to do so, throw bigger and badder hardware at it. This is generally the cheapest way as the amount of time us developers put into making sub-marginal improvements to build times can end up costing way more than hardware. For example, we've noticed that moving to 8GB of memory can make all the difference, literally transforming the entire experience.

Answer 3

I just create an MSI through the BizTalk Administrator. I keep my binding information separate from the MSI, so developers need to bind ports by importing the binding files, but that is easy.

In cases where assemblies need to be deployed into the gac, I use a batch file that runs gacutil, then install the MSI and finally bind the ports.

This approach is easy to maintain and, more importantly, easy for others to understand and troubleshoot.

In regards to BizTalk being a resource hog, first look at SQL Server and make sure that you limit it to some reasonable amount of memory (it takes whatever it can by default - which is usually most available memory). That one change alone makes a significant difference.

You should also consider using only minimal software during development - that means disabling the anti-virus or excluding directories from getting uselessly scanned when developers compile and deploy. Avoid using MS Word, Messenger, etc on systems that have little RAM (2Gb or less) while developing a BizTalk solution.

On developers' workstations, enable the BizTalk messagebox archive and purge job as explained here:

http://msdn.microsoft.com/en-us/library/aa560754.aspx

Keeping the database small saves valuable disk space which can help to improve overall performance.

Answer 4

There are quite a few solutions out there - Rob Bowman mentioned Michael Stephenson's msbuild generator Also on codeplex you can find another framework by Scott Colestock,Thomas Abraham and Tim Rayburn

There's also a minor addition by me palying with Oslo, but that's not half as mature as these two, but it does use the SDC tasks, which is a great starting point if you wish to create your own msbuild based solution.