Dan Nolan

16 October 2014

How FlexiGroup uses ReadyRoll

FlexiGroup is a diversified financial services group providing point of sale interest free, no interest ever, leasing, vendor programs, interest free cards and other payment solutions to consumers and businesses.

We talk to Damian Haynes, Senior Application Developer at FlexiGroup, about why his team selected ReadyRoll as their database change management tool.

How did you make database changes before you adopted ReadyRoll?

We used to deploy our databases in one of two different ways: either we’d generate scripts manually for a release and placed them in a common folder for a project, or we’d use PowerShell to extract a dacpac from our development database and subsequently generate a sync script for each target environment.

The first method involved executing the scripts by hand whereas the second method was partially automated. But unfortunately it made ‘run once’ scripts, such as transactional data updates, very hard to organise and maintain. This was a problem for us because we often need to orchestrate data changes, such as adding new products to the system, alongside the schema changes.

SQL Server ships with its own set of database development tools in Visual Studio. What made you choose ReadyRoll?

Mainly the ease of use for everyone in our team, the true run-once migration method, and scripting with variables that can be populated by other complimentary tools during deployment, e.g. with Octopus Deploy.

We’ve also just started using the semantic versioning feature of ReadyRoll which allows us to organise our change scripts by release, making it easier to merge branches of our database code.

Who is responsible for writing change scripts in your team?

Everyone! All developers become T-SQL script authors once you show them how easy it is to import table changes and even look-up data. What gets them hooked though is the ‘Just press Start’ approach [in Visual Studio] to synchronizing the database from source control.

Does each developer have their own sandbox, or is a shared (development) database used?

We each have a sandbox as it is necessary to develop solo, then we promote to a development environment which has additional data. Then, later in the development cycle, we merge code from other teams into a separate environment for integration testing.

Do you have a means of populating your tables with test data?

All lookup data is contained within each of the ReadyRoll database projects.

For sample data, we have a separate database project which uses a SQL DataRun pattern I created, involving a set of control tables and stored procedures to orchestrate the ETL process (the control tables prescribe the data run sequence, and the stored procedures contain the data transformation logic).

To populate their own sandbox environment, the developer presses `Start’ to deploy the schema and then executes a stored procedure to kick off the data run. This performs an extract from a separately maintained test environment, which holds a sample set of transactional data.

How do you deploy to your Test and Production environments?

We primarily use Octopus Deploy to handle deployments between all of our lifecycle environments, which includes the deployment of the databases packages that ReadyRoll produces. With the program of work we’ve got on right now, it would be virtually impossible to deliver software on time if we had to deploy our application components by hand.