Enterprise Integration Solutions

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