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:
Figure 1. Sandboxes within your technical environment (click to expand).
Development. 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 team, enabling them to make and validate changes without having to
worry about adversely affecting the rest of their team. These environments are likely to have their own
databases to enable
regression testing and more importantly
agile testing strategies.
Team 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 Test/QA
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 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.
Production. This is the actual environment in which your system will run once it is deployed.
Figure 1 depicts the nature of the work performed within each sandbox, the deployment
effort between them, and the flow of feedback. You see that the effort within development sandboxes is highly
iterative and that you will frequently deploy your work into your team integration sandbox, typically after
passing quick running smoke tests. You also see in Figure 1 that deployment into the
Test/QA sandbox is more controlled, typically requiring that a more sophisticated test suite run successfully.
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, because you need to be able to show that your application has been
thoroughly tested and appears to integrate into your organizational infrastructure. Finally, Figure 1 also shows that change requests are always fed back to the development team,
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
database change scripts as appropriate.