Agile Data Logo

Development Sandboxes: An Agile Core Practice

Follow @scottwambler on Twitter!

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:

  1. 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 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 regression testing and more importantly agile testing strategies.
  2. 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 Test/QA sandbox.
  3. 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.
  4. 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.
  5. Production. This is the actual environment in which your system will run once it is deployed.

Figure 1. Sandboxes within your technical environment.

Refactoring Databases 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 infrastructure. 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.