ReadyRoll started as a small side project in late 2010 while I was working in the financial services industry. For many years I had been working as a Release Engineer, handling the deployment of all of the company’s line of business applications.
Above all else, putting together the database part of release was the most time-consuming aspect of my role. Initially, all of the database parts were done manually, either by a developer or a DBA working from a handwritten list of scripts on a share drive somewhere.
Things got a little easier once database comparison tools came of age, allowing us to physically see what schema changes needed to be pushed from Dev to Test, and also allowed us to generate scripts to synchronize the two.
But things would still go wrong: scripts would often get missed, or they would be executed in the wrong order. Sometimes the scripts themselves would run fine, but then testing would fail due to subtle differences between the schema and data in each environment. It was never in our culture to blame anyone for these mistakes; everyone always did their best under the (often stressful) circumstances.
Nevertheless, we’d always look for ways to improve the way we did things to avoid repeating the same mistakes. But what frustrated me personally is that I couldn’t get the tools to do quite what I wanted. While the model-driven approach (also often referred to as state-based) offers a very elegant approach to source controlling a database, I felt like the “black box” approach to script generation made it difficult to accurately predict the outcome of my deployments. I often found myself editing the script that was generated in order to get it to do what I wanted, which resulted in “gaps” in our source control repository.
At the other end of the spectrum, migration frameworks offered the level of control and flexibility we craved, but we found the continuous integration and branch/merge aspects of these tools wanting. Additionally, the idea of having to produce all the T-SQL ourselves for the hundreds of databases in our environments was quite daunting.
So I started working nights and weekends on a tool that would offer the best of both worlds: a tool that would offer the productivity benefits of the model-driven approach, with the control and flexibility of change script “migrations”.
Eventually I left my full time job so I could focus 100% on the product’s development. In July 2012, ReadyRoll finally made it out of beta and before long it started finding it’s place in the world, thanks in part to a wonderful pairing with Octopus Deploy. In June 2015 ReadyRoll was acquired by Redgate, and I’ve been working with a team of developers and testers since to make improvements to it even quicker. In March 2016 it was released as a fully-fledged Redgate tool.
Undoubtedly the best part of this has been seeing how ReadyRoll has allowed teams to stop losing time in something as unglamorous as database change management, and focus instead on delivering great software. To learn more about ReadyRoll, take a look at the new Redgate page.
Was this article helpful?
Also in Working at Redgate
At a Redgate Summit in May, I gave a 20-minute presentation on the challenges of working from home. I presented on the topic, because, unlike many people, I’ve been working remotely my entire time a...
Also about SQL Change Automation
A great part of working at Redgate is that I get to know folks in our software development teams. They’re smart, fun people, and I love getting a view into how they build our solutions.