How Redgate removed 50% of automated test code, and reduced test times by 30%
Overview
The Redgate Change Control (RCC) team have been leveraging a new database provisioning tool, Spawn. RCC is a version control tool for your databases, allowing you to manage deployments in a migrations-first approach. Here on the Spawn team, we reached out to 2 of the software engineers to identify the problems Spawn has solved for them…
Given the nature of the RCC product, their development and testing is very database heavy, and on top of that they support multiple database engines. The main challenges they faced included managing database state in CI pipelines, and also it was a struggle to test locally on their machines. Their first solution was for each developer to have Docker containers, as opposed to managing instances manually. But they found that, particularly with continuous integration, provisioning containers each and every time was a pain. There was a lot of management code which was “eroding our productivity” and it’s more code to maintain which developers don’t need: “there are more things to go wrong, and when they do go wrong it’s time we could’ve spent elsewhere”.
In comes Spawn…
The team found Spawn through other people at Redgate, and to begin with, just tested the waters. Sam, one of the engineers on the RCC team, told us that they had been using Docker for local testing, and he was ok with that as it “just worked”. But his first thought from playing around with Spawn was “wow that’s actually really cool! Why haven’t I been using this beforehand?”. The team found it easy to make the switch over to Spawn from Docker. They went through their CI build script, removing all the set up needed for Docker and replacing with simple 1 lined spawn commands. The RCC team are also taking advantage of Spawn’s branching feature — whenever changes to their CI pipeline were made, they could test on a branch with unique containers per branch. They became independent of the contingency of the pipeline.
“Spawn takes the pain out of provisioning databases”
David Legge, Tech Lead @ Redgate
Helping out sales engineers
After integrating Spawn into their CI, Sam was tasked with helping internal sales engineers with an advanced demo for a customer. They required many databases to be set up, and globally available as they were dotted around in the US, and the UK. Planning out how he’d achieve this, Sam decided Spawn would be a perfect fit for having databases stick around for a few weeks, to be torn down after use. A VM was considered, but he decided it was too complicated and too much installation was required. As he was already using Spawn locally at this point, he thought “why not use it in this scenario?”
Sam created 7 data-containers from 1 Microsoft SQL Server data-image which took a total of 10 minutes, and could be accessed from anywhere in the world. Compared to their previous methods using Docker, Sam said it could’ve taken from anywhere between a few hours to a whole day. There is also the pain of managing the instances once they’re up, he noted.
The sales engineers were able to easily practice the demo before the day, by using Spawn’s reset command which puts the database back to match the original state of the data-image. Sam said this was a great added bonus to using Spawn for this task, and made it so much easier with the reset ability.
“It has made our integration testing a lot easier”
Sam Comer, Software Engineer @ Redgate
Outcomes
1. The main outcomes Sam has seen from Spawn is having a consistent base
They’d know there’s an MSSQL container there, and they’d know exactly what state it’ll be in so there’s no need to worry about it. They like the easy-to-use command line interface with the single pane of glass view, and have found it easier to not have to worry or care about how they approach installing MSSQL or MySQL instances, and Sam can “save space in my brain for other things”.
2. The team has reported that from using Spawn, their automated test code has been halved and also test times are reduced by 30%
3. Using Spawn has sparked other ideas and interests for the team; they’re looking to include PostgreSQL next year, and already know how they can leverage Spawn to provision these instances
They have also seen how they could’ve improved their demo with the sales engineers. Instead of the approach of bringing up a container by running the command and then running a script manually every time, they can provision a database in a new data-container and populate it all in 1 step from running a script. They would also make use of the save command, allowing them to create a history of their data and schema in their demo, so they can go back to a specific revision at any time.
“I was bogged down in a lot of Docker stuff. But Spawn took the pain out of that, and I got to throw away a lot of scripting”
Sam Comer, Software Engineer @ Redgate“The penny drop moment for me was throwing away reams of code which did docker management, and replacing it with a little bit of code”
David Legge, Tech Lead @ Redgate
Join the beta
If you’ve finished reading this case study and you feel Spawn could help you solve similar problems, you can sign up to the Spawn beta and try it out for yourselves.
