I recently had the chance to chat with Scott Colestock. Scott is the Chief Architect at Trace
Ventures, LLC based in the Twin Cities, MN. He’s also a BizTalk Server MVP. Here’s the transcript
from the chat.
Mike Woods says:So Scott I moved to the BizTalk Server team in July of 2002 after working in the developer division
on the .NET Framework 1.0 project. I seem to remember you being part of the BizTalk community
back then. What can you tell me about your experience over the years?
Scott Colestock says:Sure - I had a few experiences with BT2000/2002 in the past, but I've been working with the
current incarnation of BizTalk since the summer of 2003, when BizTalk 2004 was in beta. I've
been fortunate enough to have been an MVP for the last year - It's been a great ride - a great
product to specialize in. I've enjoyed participating in the newsgroups, and maintaining a blog at
http://www.traceofthought.net, writing about my experiences along the way.
In the fall of 2004, I had the chance to submit a deployment framework for BizTalk for the
"connected systems" contest and I've enjoyed growing that initial work since then.
Mike Woods says:That was quite a useful thing to have in the BizTalk Server 2004 days. We've done a bit of work on
improving deployment in the 2006 release. Tell me more about the Deployment Framework. What
does it provide for BizTalk Server 2006 developers?
Scott Colestock says:Several of the goals for the 2006 framework are the same as they were for BizTalk 2004:
1) Streamline the deployment process for developers, ensuring repeatability. 2) Make it easier for a team of BizTalk developers to stay in sync - not just with BizTalk artifacts,
but with all the other infrastructure that surrounds the solution (virtual directories, queues, file
folders, etc.)3) Extremely close parity between server-side deployments and developer deployments - so you
are always testing your server deployments as you go through a typical developer work day.
In addition, using the framework can assist a team with their migration to 2006 from 2004. Teams
that are using the framework for 2004 (and who are now looking at BizTalk 2006) are finding that
using the framework will ease that part of their migration story, since the concepts are identical.
Mike Woods says:This sounds like good stuff but let’s dig a little deeper into the migration issues. What kinds of
issues have you run into within your projects?
Scott Colestock says:The key challenges that BizTalk 2006's "native" deployment story present are basically 4-fold:
1) Binding changes have to be communicated "manually" between developers on a team, since the
import process is done through the Admin MMC or command-line. Just "getting latest" from
version control isn't sufficient. 2) Binding files for your various environments have to be maintained as separate files (manually),
rather than "merging in" environment-specific settings 3) Artifacts such as rules, virtual directories, queues, folders, additional dependent assemblies, etc.
can be represented as "Resources" within the Admin MMC (and in exported MSI’s), but not in a
fashion that easily moves between developers on a team.4) It is difficult to define the contents of a generated MSI in a repeatable fashion, unless you script
the creation of the application definition. If you create the app definition through the MMC, you
can't guarantee you can reproduce it.
That is a concern for shops that must be able to guarantee than an MSI (or other packaging
mechanism) is traceable to a particular marked point in version control.
Mike Woods says:These sound like big issues to me. How does the deployment framework help?
Scott Colestock says:The deployment framework addresses this by making the deployment story for developers identical
to what will happen at deployment time on the server. Essentially, you move the deployment
process to a "Tools"-menu item in Visual Studio. This external tool kicks off a NAnt script that
creates a BizTalk 2006 application definition, and adds each element of your project as a resource
to that definition. In addition, the "framework" portion of the nant script (that you #include in your
project-specific nant script) takes care of things like binding file import, vdir creation, application
pool identity, placing .net components in the gac, etc.
The goal is this: that when the developer in the next office does a "get" from version control they
can 1) build 2) go up to the Tools menu and hit Deploy 3) be running the whole application
successfully with ALL of the infrastructure that surrounds the solution - whether it be custom
identities for application pools, MSMQ queues that are required, specific ACL’s on file directories,
whatever it might be. Moreover, if one of those elements is changed, they are communicated
throughout the team via version controlled scripts - not in an out-of-band fashion.
Mike Woods says:Good detail. Thanks. How many folks do you believe are using the deployment framework today?
Scott Colestock says:It is hard to gauge - At last count, I've had over a thousand downloads of the zip files, but I don't
comb my logs all that often "looking" for those downloads. Folks from the training companies I talk
to indicate that their students mention it quite a bit.
Mike Woods says:It's a download off of your site, right? Can you give us the URL and tell us about your support
model for the deployment framework?
Scott Colestock says:Yes, the URL for all of the releases and articles I've written about the framework is:
There are three downloads - a full sample, a "core" which represents the framework itself, and
source code for the various utilities. They are all available at www.traceofthought.net in the
There is a full set of documentation, and I answer questions via blog comments and occasionally
via email. But a shop that uses the deployment framework is generally savvy with NAnt and the
BizTalk command-line utilities, since a fair amount of self-support is required.
Mike Woods says:Great, I'm going to go download the deployment framework myself.
This discussion sort of begs a question about Visual Studio 2005 Team System. One of the projects
my team has on our plate this year is to do some research on how Team System enhances the
BizTalk development experience. You've obviously thought a lot about BizTalk development. Can
you comment on that?
Scott Colestock says:I hear a lot of questions from clients (and in the community) about how best to integrate unit
testing into their development process - and how BizUnit might (or might not) integrate well into
VSTS testing story. In addition, folks have asked how LoadGen might be integrated into VSTS with
the same level of integration that the web stress testing story has. So I think there is a lot of
potential for synergy - for BizTalk developers to benefit from the infrastructure VSTS can provide.
Mike Woods says:Good input. Later this year when Kris and I start the research it would be great to have you on the
project v-team. What do you think?
Scott Colestock says:I would love to participate - it would be great to have community involvement in that effort.
Mike Woods says:Good, community participation is important to me personally and I’d enjoy working with you on the
On a separate topic I noticed that you were one of the first people to register for the October SOA
& Business Process conference. What are you hoping to see at the show and do you think I can
convince you to speak?
Scott Colestock says:Last year's show was fantastic - great content and a great networking opportunity. I'm looking
forward to hearing more about 2006 R2 (particularly how the RFID story has moved forward since
I heard about it at the conference last year). I'm also looking forward to hearing more about the
Office Server vision.
I'd love to speak - I'm planning on submitting a topic on how a shop can apply what they learn
during stress/perf testing into an operations monitoring strategy. I've learned a ton hearing
Wayne Clark speak at the last couple conferences and I think there are some interesting ways to
apply those topics to proactive monitoring via MOM, etc.
Mike Woods says:All of those topics are in the sweet spot for coverage at the show. Your topic sounds like a session
I'd like to sit in on as well. Please send in your abstract proposal. Scott, I'd like to thank you for taking the time to chat with me today. I certainly appreciate it and I
bet the community does as well.
Scott Colestock says:It's been a pleasure! Thanks for the chance to tell you about the Deployment Framework stuff I've
been up to. I look forward to seeing you in October at the conference.