Chapter 11 Deploying and Testing Integration Solutions 267
running test cases and regressing bugs. This environment can be used for long-
duration “soak” testing, performance testing, and functional testing. Depending
on the size of the project, size of the test team, and breadth of tests being run,
multiple test environments might be required. Having two or more test environ-
ments is valuable on larger projects because it allows the test team to continue
testing on one test environment while installing a new build on another.
The Staging Environment
The staging environment should be identical to the production environment
(discussed next) because it serves as the home for your software just before
being released into production. Many organizations interpret this to mean that
only the software should be identical in both environments, which is not suffi-
cient in many cases. Ideally all hardware in the staging environment should
match that of the production environment.
The Production Environment
The production environment is where the solution ultimately will be deployed and
is the live environment that the solution will be run in. All the equipment, monitor-
ing tools, and security procedures should be applied in this environment. Access to
this environment should be severely restricted. You might want to limit the type of
access to this environment as well—for example, by allowing only FTP access.
Deploying the Build
The build will be included within a larger process, which takes the output of
the build and deploys it to various environments.
268 Part IV The Infrastructure of Integration
The build process.Platform Builds
Having an automated, repeatable process for building the solution is a neces-
sary part of creating a large solution. Having an automated, repeatable process
for building the platforms used by the team is just as important. You should
have an automated build for the development machines as well as an auto-
mated build for each of the environment configurations. When you have an
automated process for building the machines, any configuration changes that
occur in the environment will be captured in a repeatable fashion.
Having machine builds also captures the knowledge of any changes made
in the system operation so that when the solution is deployed in the production
environment, the exact configuration is known and repeatable. Creating an
automated build for the development and test teams also might require you to
add a new team member to the project. In addition, this automated build pro-
vides a quick way to recover a machine from a hardware failure or to upgrade
between product versions (betas and the like).
Solution
compiled with
no errors?
Installation
worked
correctly?
Installation
worked
correctly?
Build machine
starts the build
process
Build complete
Build version
increased and
labeled in the
source control
Fix checked into
source control
Build team finds
appropriate
developer to
fix problem
Test team
verifies BVT
tests are valid
Build team finds
appropriate
tester to fix
the BVT
Latest code
copied to the
build machine
from source
control server
Build machine
compiles the
code in the
solution
Solution copied
from the build
machine to
release server
Build installed
on minimal
environment
Build verification
test ran on
minimal
environment
BVTs passed?
Are
tests valid?
BVTs passed?
Solution installed
on development
environment
Build verification
test ran on
development
environment
Build handed to
infrastructure
team
Yes
YesYes
Yes
Yes
Yes
No
No
No
No
No
No

Get Enterprise Integration Solutions now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.