Accelerating development with instant, production-like, containerised databases
A while ago, we posted a blog discussing “How we develop apps that rely on databases in a Kubernetes workflow”.
In that post, we discussed the different pains we’ve experienced when it comes to developing with databases. Unsurprisingly, the key issue was around state.
When I switch branches, my code flips immediately to the version I want to be working against. Unfortunately, the database I’m developing against might still include schema or data changes from the original branch which might conflict with the code on my new branch.
Furthermore, I want to get confidence that the changes I’m making in development won’t cause issues in production. To do that, a production-like dataset in development is ideal. Unfortunately, that might be very large and it might not be possible to hold all the data on my machine, or it takes too long to get a copy of that myself. Often, the workaround is to use shared database instances, at which point I may start to trip over unrelated changes my colleagues are making to the database!
As we discussed in the previous article, database containers can help avoid the tedium of installing or acquiring database server instances. Unfortunately, they don’t help me solve the problem of acquiring large datasets, nor do they allow me to jump between known states of the database with ease.
At the end of our original post, we mentioned we were working on solving these problems with a project we called “Spawn”.
So what happened?
We’ve been quietly working behind the scenes, getting to grips with the problems we’re trying to solve, building Spawn, and enabling internal usage of Spawn to accelerate Redgate’s own development teams.
We’re in a position where we’re ready to start testing this out with some external users, which is what this blog post is all about.
Spawn Closed Beta
We’re excited to announce that we’re launching a closed beta program for Spawn.
We’re looking for development teams that are struggling with using databases in their development and CI workflows. Particularly those teams who have multiple different databases supporting their projects.
If you’re trying to achieve any of the following things, you might be a great fit for the Spawn Closed Beta:
- Instantly creating production-like database environments for dev/test regardless of size on disk
- Independent, isolated copies of those environments for each developer on your team
- Independent, isolated copies of database environments for each branch of development you’re working on
- Snapshotting states of databases and making those available as independent, isolated copies for your team members
- Defining deterministic database states for use in test environments
- Snapshotting states of the database during test runs
- Resetting the database back to known states for deterministic behaviour regardless of test ordering
- Doing all of the above without any infrastructure configuration (Spawn is a hosted service!)
Alternatively, take a look at the Spawn website, read through the Spawn Docs, and sign up to our beta program if there’s anything you think Spawn might be able to help you with that isn’t already on the list above!
There are a limited set of spaces available on this closed beta program, and we’ll be looking to work closely with you on a regular cadence to make sure Spawn is able to solve your problems. If this sounds like something you’d enjoy being a part of, then sign up and we’ll be in contact if we’d both benefit from your involvement on the program.
