A common practice on
agile teams is to ensure that developers have their own "sandboxes" to work in.
A sandbox is basically a technical environment whose scope is well defined and respected.
The primary advantage of sandboxes are that they help to reduce the risk
of technical errors adversely affecting a larger group of people than is
absolutely necessary at the time.
Figure 1 depicts five different types of sandboxes:
Sandboxes within your technical environment.
This is the working environment of individual developers, programming
pairs, or individual feature teams. The
purpose of this environment is for the developer/pair/team to work in
seclusion from the rest of their project team, enabling them to make and
validate changes without having to worry about adversely affecting the rest
of their project team. These
environments are likely to have their own databases to enable
testing and more importantly
agile testing strategies.
Team/project integration. Each team should
have its own integration environment, often referred to as a build
environment or simply a build box. Developers
will promote their changed code to this environment, test it, and commit it
to their teams configuration management system.
The goal of this environment is to combine and validate the work of
your entire team so it can be tested before being promoted into your
Demo sandbox. This sandbox is where you
deploy working software which you can use to demo software to your
stakeholders and they can use for
acceptance testing purposes.
Pre-production test/QA. This
sandbox is shared by several project teams and is often controlled by a
separate team, typically your testing/QA group.
This environment is often referred to as a pre-production
sandbox, a system testing area, or simply a staging area.
Its purpose is to provide an environment that simulates your actual
production environment as closely as possible so you can test your
application in conjunction with other applications.
This sandbox is crucial for complex environments where several
applications access your database, although even if your database is only
accessed by a stand-alone application you will still be required to test
within this sandbox before deploying your application into production.
This is the actual environment in which your system will run once it
||Figure 1 depicts the nature of the work performed
within each sandbox, the deployment effort between them, and the flow of bug
reports. You see that the effort
within development sandboxes is highly iterative and that you will frequently
deploy your work into your team/project integration sandbox.
You also see in Figure 1 that deployment into the
Test/QA sandbox is less frequent, typically at the end of an iteration and often
only at the end of some iterations. There
is greater control over whether you deploy into this sandbox because it is
typically a shared resource that other teams are deploying into as well,
therefore someone needs to verify that your system appears to have been
sufficiently tested in isolation and is therefore ready for system integration
testing. Similarly it should be
even harder to deploy into production, an activity that is even less frequent
for your application, because you need to be able to show that your application
has been thoroughly tested and appears to integrate into your organizational
Finally, Figure 1 also shows that bug
reports are always fed back to the development environment, and not to the
previous sandbox, to be fixed.
An interesting technique is to turn the SQL logging on within the databases
on your development sandboxes. This enables you to see which changes you
made as you were working, and then rescue that code to form your official
database change scripts as appropriate.