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.
Also in Working at Redgate
When talking to friends, family, or even sometimes colleagues, I often get a questioning look when I say I work in Product Marketing. Sure, most people roughly know what Marketing is, but then what’...
Also about SQL Change Automation
Deploying schema changes to SQL Server databases can be tricky when you’d like to automate parts of your workflow. For instance, how do you go about version controlling your schema changes? In appli...