Once you have a team
established, the next step is to create an environment where you can
create, test, and deploy code. Some variables will affect how this is
going to be accomplished:
How are the development servers going to be configured?
How will source control be configured?
How are the Visual Studio projects going to be laid out?
The answer to each of these questions can often
separate a well-organized and efficient environment from one that can
kill a team's productivity. Potential solutions to each of these
questions are given in the next sections.
Isolated Development Configuration
BizTalk development is an isolated development
model. This model requires each developer to have a stand-alone
development environment and not a shared environment such as in web
development.
In the isolated model, a developer performs each
task independently from other developers on the team. They can code,
debug, edit, and restart services without worrying about affecting
others on the team. Each developer has a self-contained development
workstation with a local BizTalk Server Group. Access to the master
source files is controlled via a Visual SourceSafe (VSS) database
located on a network file share. Figure 1 illustrates an isolated development model.
The isolated model of BizTalk Server development provides the following benefits:
No chance that BizTalk Server shared
configuration information will interfere with another developer's work
(for example, XML target namespace clashes occurring from multiple
installed versions of shared schema)
No
opportunity for any one individual's BizTalk Server deployment and test
processes interrupting other users (for example, the starting and
stopping of BizTalk Server host instances, receive locations, or
dependent services like IIS, SQL, and SSO)
Ability to clear resources like event logs and tracking databases without disrupting other users
Ability for developers to use different versions of shared resources, for example, helper classes and error-handling processes
Ability for developers to attach and debug the BTNTSvc.exe process without halting other developers' processes
Using Virtual Machines
Many organizations use virtual desktops
for development. In these cases, organizations should look at products
such as Virtual PC or VMware to allow developers to have multiple
virtual machines running within the same physical hardware. Virtual
desktops provide two things well. The most important thing is that they
allow your developer to get a fresh install in a matter of minutes
rather than hours. How many times have developers needed to rebuild
their PCs due to bad code they had written, too much unsupported stuff
getting installed, or a bad configuration they might have done?
Typically this will happen at least two to three times over the run of a
year. Having a fresh virtual image that they can load onto a clean host
operating system greatly reduces the time for this to occur. All
developers need to do is copy over any files they want to save from the
virtual machine onto the host operating system before it is removed.
The second thing that virtual desktops allow for
is the ability to host multiple configurations inside one physical box.
Often developers need to have separate versions of either the operating
system or a development environment. This is often the case when a
developer is coding both BizTalk and classic .NET objects. When the
BizTalk development tools are installed and the environment is
configured, there are significant changes made to the underlying
operating system. Developers will often have a "BizTalk" image and a
".NET" image just to keep things separated.
The configuration just described is also often
required when creating a web application that targets different browser
platforms and versions. Anyone who needs to support IE 5.0, 5.5, and
6.0+ will need to have something similar to this configuration, since
these browsers cannot live on the same host OS.
Organizing Visual SourceSafe Source Control
Not implementing a structured source control
process is a sure-fire way to derail a project before it gets started.
It is important to model the source control directory structure to one
that closely simulates the namespaces and assemblies that are actually
stored in the project. For example, assuming that your company name is
ABC Inc., the easiest place to start would be to create a root directory
called ABC in SourceSafe. Each project that is being implemented at ABC
would then get its own folder, for example, FulFillment. The structure
would look something like that in Figure 2.
Notice that the subfolder names are matching up
to the proper namespaces for the projects within that SourceSafe
project. Once the high-level folder structure is implemented, it easily
allows new projects to be added, and organizational namespaces should be
selfenforcing. Consider the example of the FulFillment application; in
this scenario you can use subprojects that map to the subsystems you
need to create. Each subsystem would then have its own namespace, and
the SourceSafe project will be named accordingly. Figure 3 illustrates the FulFillment application, its subsystems, and even some sub-subsystems.
Before beginning with
VSS, ensure that the binary file types for *.btm, *.btp, *.xsd, and
*.odx have been added to VSS. This is required so that SourceSafe does
not attempt to version these file types as text.
