How Redgate removed 50% of automated test code, and reduced test times by 30%

Eleanor Fuller
Nov 20 · 5 min read
Image for post
Image for post

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.

Image for post
Image for post

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.

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.

Image for post
Image for post

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.

Ingeniously Simple

How Redgate build ingeniously simple products, from…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store