Why a “Sandbox Database” is Important to Software Developers

It’s amazing how the skills we learned as a kid continue to help us today. 

Here’s an example: Software developers couldn’t do the most critical parts of their job without a nod to a fun activity from their youth — the sandbox.

Much like the dirt-filled play place of our childhood, today’s development sandbox holds within it a world of possibilities, at your fingertips. For the uninitiated, the development “sandbox” is the environment where a developer can work out the details of building a smooth database project without jeopardizing the production, or live, data, should something go awry.

Every developer needs to have this sandbox environment in order to successfully create. The sandbox database should represent a mirror image of the current production environment PLUS any changes currently in the deployment cycle. This ensures the developer tests their changes against a realistic setting.  

In addition to database structures and logic stored in the database, a reasonable set of test data should be included. While it would be great to have a complete copy of production data, most especially for performance testing, that is probably not feasible due to both data size and the need to remove sensitive data (such as personally identifiable information, or PII).

The sandbox is necessary because developers need their own place where they have unfettered access  This is where they prototype, learn, try new things and, at least occasionally, break things.   This last point most especially is why each developer needs their own sandbox so they avoid conflicting changes that negatively impact other developers.  Note that this is all activity that occurs BEFORE changes are deployed to the integrated development environment.

Because of the activities noted above, developers also need a way to reset or recreate their sandbox. This process is broken into three parts:

Part 1:  Create  a “clean” database instance, perhaps using container technology to make it VERY easy to create a new environment. If container technology is not the choice for you, then the process should be scripted and automated to the greatest extent possible so that executing it requires a minimum of user interaction.

Part 2:  Next, create the database base structures, ideally by the same method that the changes are deployed to the integrated development, testing, production, and any other environments. If you have incorporated your database builds into your CI/CD pipeline this should be straightforward to reference the clean instance and execute the build process.  If you have not incorporated the database into your CI/CD pipeline, then the build process should still be automated with scripting as best possible.

Part 3: Loading representative data is the final step — but one that should not be overlooked. Providing the developers with realistic datasets allows better unit testing at an earlier stage leading to better releases. Predefined data sets can be stored in many ways to facilitate quick loading. These data sets may even be part of your integration testing to maintain consistency between the non-production environments. Once again, an automated process should be used to load this data.

As noted previously, all three steps should be automated to the greatest degree possible.  Blue Sentry has extensive experience configuring these types of tasks.  If you need assistance, our team would be happy to help — contact us for more information.

In conclusion, every developer needs their own space. It takes additional effort and time to set this up initially, but that time will pay compounding dividends over the life of the project.