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:
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 sandbox.
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. Sandboxes within your technical environment (click to expand).
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 official database change scripts as appropriate.
