Have you ever thought about what makes a sandbox enjoyable? As a child, we probably took them for granted, but inside a sandbox, we could build castles, dig giant holes, create mud pies, or build whatever we imagined. At the end of our fun, our creations could be cleaned and refreshed with no consequences or progress besides the internal feeling of joy and accomplishment.

At Zerion, these sandbox environments still exist in the workplace (just without all the sand), and we use them on a daily basis. Zerion’s Sandbox environment is a feature that gives customers and employees alike the ability to replicate real data, but in a whole separate environment not connected to the production servers. The sandbox environment consists of a new database and a new front-end, so that it exactly replicates the original. Not only that, but this feature also gives the ability to replicate data from a different day. The sandbox allows for the debugging, testing, and restoration of data, but without all the dreadful consequences. All in all, it gives us an environment to safely learn, create, and sometimes even destroy.

Now you’re probably wondering how we actually use this feature. As a DevOps engineer at Zerion, I use our sandbox feature quite a bit. When writing scripts and automating tasks, our biggest concern is how all of it affects our customers. With the Sandbox environment, we can do tests with great confidence that what we’re working on will work on the production servers and databases without damaging our customers’ data.

When it comes to large mysql data restorations, the Sandbox environment gives us a consequence-free environment to run queries without affecting our production servers. Since mistakes are inevitable in life, and needless to say, accidents happen at work all the time, this matters. When our customers delete important records or forms by accident, we are able to use the Sandbox environment to replicate a backup from a past date, and restore all the missing data that was deleted.

Also, when working on data, I too am prone to mistakes, so preparing all the queries in a sandbox environment lets me run through the steps exactly how I would run through our production server. This means if I make a mistake, I can wipe it clean and start again.

On the customer-facing side, our Sandbox environment allows our customers to debug any issues as well as explore new ways of modifying their forms. By doing this in the sandbox environment, they avoid disrupting others that are using the form out in the field. When our customers run into issues, our support team uses the Sandbox feature to load their live data in order troubleshoot their issues as well as help debug the problem. If the issue found is a software problem, it can be easily replicated. This gives certainty to our developers where the problem occurs, which results in efficient bug fixes.

The Sandbox environment takes the great parts of playing in a sandbox as a child, and turns it into something functional for our team and our customers, allowing for great advances that would otherwise be risky or impossible. What would you be able to do in a testing environment like this?

The Sandbox environment takes the great parts of playing in a sandbox as a child, and turns it into something functional for our team and our customers, allowing for great advances that would otherwise be risky or impossible. What would you be able to do in a testing environment like this?

Zerion: Our Sandbox Environment (Sand Not Included) was originally published in Zerion Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Check out the original post at: https://medium.com/p/68e80be29be3