When I took over the job of marketing Red Gate’s SQL Source Control, I had a look at some of the ‘Tweets’ that had been made by users of the tool. One tweet by Phil Gale led me, out of curiosity, to contact him to ask for more detail of his experiences with the product.
The Manager’s Perspective
Phil is director and software development lead at Red Jungle. This is a New Zealand web development house that has been designing, developing and maintaining web sites and web applications for over a decade now. They specialise in Microsoft based web technologies such as ASP.NET, IIS, and Microsoft SQL Server to build web-based ‘Software As A Service’ applications. Phil told me his story.
“We run teams of between 2 – 5 developers on different projects. They are generally distributed, many working from home offices.
Before SQL Source Control
Because development involved remote working , each staff member has their own machine with a copy of Visual Studio 2010 and SQL Server 2008 installed locally to work with. We were able to easily sync up the code base via source control (SVN or more recently we’ve moved to TFS2010). But keeping the database in sync had always been a painful struggle. Depending on the project and team size we tended to use, before SQL Source Control, one of the following methods:
- Manual backup and restores. Whereby a database .bak was generated periodically and e-mail around the team to do a restore and make sure everyone was up to date. Problematic as only one developer can make changes to the DB before it needs to be re-distributed.
- SQL create scripts via the ‘Create Scripts’ option in SQL Management Studio (formally the SQL Database publishing wizard). Similar to manual backup’s we would generate all the SQL scripts to drop and rebuild the database including data, which would then be distributed.
- One of our developers rolled his own DB sync tool which could do a DB schema compare and then alter the database accordingly to match. This was time consuming developing our own solution, and really only worked in a situation where both the source and target DB could be accessed at the same time (unlikely).
- More recently we started to use Database projects within Visual Studio, which would also allow a schema compare and update – but this too was clunky and tended to be quite fragile when substantial changes had to be made.
What prompted us to look for source control for SQL Server development was the simple need to find an easier way to keep our database structure in sync across the team – we iterate quite rapidly using an agile development methodology, so our data model alters frequently.
We’d heard about SQL Source Control when one of my development team brought it to my attention – and being familiar with the quality of Red Gate products I immediately looked at it.
With SQL Source Control
The reaction of the SQL Developers was overwhelmingly positive, as it solves a major pain point for us all, and It’s now much less hassle to keep our database schemas in sync, so that is a huge time saving. With the tool, we were able to eliminate many painful manual schema update procedures and move everything into our TFS source control.
I highly recommend SQL Source Control to anyone who is doing software development around SQL Server. It takes the pain away from an otherwise tedious process of syncing database schemas across a team, and lets us focus on what we do best – developing great software. It integrates seamlessly into the SQL Management Studio interface, and works hassle free with existing source control systems.”
The Developer’s Perspective
I then contacted another member of the team via Phil. This was Matthew Hintzen, a Systems Architect and Senior Business Logic Programmer, to get a developer-oriented view of the impact the tool had made on the teams.
“Before we got SQL Source Control, we used a home Grown DB Upgrade Tool and development convention / methodology. It was able to accomplish all of the functionality of SQL Source Control, but it took a lot of time that I could ill afford. The trouble was the time it took to teach new Developers how to use the DB Upgrade tool and instructing, or enforcing, development Conventions. We first heard about SQL Source Control by reading a Blog Entry from another developer.
The reaction of the developers to SQL Source Control was ‘WHOO HOO!!’. We all saved a lot of time that had previously been spent in making modifications to database schema and getting changes pushed out to other developers.
I’m surprised to find myself saying I would recommend a Version 1.0 of any product. While I am sure there are great improvements to come in future versions, the current version / build immediately brings database schema coordination between developers, saving time, and frustration.”
It is good to hear this sort of story, verification that SQL Source Control is a good fit with such a typical requirement, particularly with the added complication of home workers. It is so important to them to know that the design squarely meets those needs, and it gives good clues as to how to improve and enhance the product. Thanks to Phil and Matthew for their feedback.
If you’d like to learn more about database source control, Red Gate has put together a free whitepaper “5 Common Barriers to Database Source Control, and How You Can Get Around Them”.
Load comments