ReadyRoll vs DLM Automation

dallen@nmdp.org

Can you give me some guidelines as to when to choose ReadyRoll vs DLM Automation?
Here are our requirements:
1. We develop .Net solutions against Microsoft SQL Server databases
2. We have at least 5 environments, and we promote changes in an orderly, sequential fashion.
3. We use RedGate SQL source control today, although we are open to other ways of ensuring changes are saved in source control
4. We do CI, automatically deploying code and database changes in synch in all environments. We are using Visual Studio Team Services (VSTS), and MS Release Management to deploy to each environment.
5. Some of our systems allow for working in a private db model where each developer has their own local copy.
7. Other systems must rely on a shared development database as the source of truth for changes. You may want to know why. Those systems are ones in which the behavior is driven by data in the database. It is somewhat akin to a custom Content Management System (CMS). When we change the application, we add new rows to the development database to represent new fields on the screen or some such thing. If we had personal databases, and two people added new fields, they might add rows with duplicate IDs, causing a collision upon merging the data. It is an unfortunate design choice that was made. But there it is. Had the designers used GUIDs for IDs on these metadata tables, there would be no issue.
8. All of our databases include reference data (e.g. States, Countries, Drop-down choices) and we expect this data to be deployed along with schema changes

We currently use a very old version of Redgate's SQL CI, integrated with TFS builds.
We are migrating to VSTS and MS Release Management. As part of that, we are looking to upgrade our database automation. Thus, we are open to exploring new tools. We really have liked the old SQL CI we have been using. We would consider either of Redgates' products: the newer DLM Automation that replaces SQL CI, or Readyroll. But We need help deciding which is a better fit for us.

dnlnln

Hi David,

Thanks for your question about Redgate's DLM offerings!

I realize that there's a lot to take in with regard to the choice between ReadyRoll and SQL Source Control/DLM Automation. If you haven't already done so, a good place to start is to check out a PDF that provides a run-down of the differences between the two deployment approaches offered by our tools:
http://www.red-gate.com/library/redgate ... comparison

As I am the founder of ReadyRoll, my answers will be more tailored towards the migrations-first approach of that tool. However I would be glad to put you in touch with someone more qualified to speak to our other DLM tools if you find that the state-first approach is better aligned to your objectives.

With regard to your requirements:

1. We develop .Net solutions against Microsoft SQL Server databases
2. We have at least 5 environments, and we promote changes in an orderly, sequential fashion.
3. We use RedGate SQL source control today, although we are open to other ways of ensuring changes are saved in source control
4. We do CI, automatically deploying code and database changes in synch in all environments. We are using Visual Studio Team Services (VSTS), and MS Release Management to deploy to each environment.

Given that your team works with .NET solutions, would it be fair to say that the developers spend a lot of time in Visual Studio? If so, then having your database deployed as part of your solution could be an advantage to adopting ReadyRoll, as ReadyRoll is an MSBuild-based project system within Visual Studio.

This also means that it can slot in alongside your existing CI builds; you only need to add a ReadyRoll project to your existing .NET solutions to have them automatically built within VSTS. We actually launched an extension on the VSTS marketplace recently that adds functionality to the Release Management capability:
https://marketplace.visualstudio.com/items?itemName=redgatesoftware.redgate-readyroll

5. Some of our systems allow for working in a private db model where each developer has their own local copy.

ReadyRoll works best when each developer works with their own copy of the database, although shared db development is supported with a few caveats. To find out more, please see Which environment strategy works best with ReadyRoll? within the ReadyRoll FAQ: http://www.red-gate.com/library/readyroll-frequently-asked-questions-faq

7. Other systems must rely on a shared development database as the source of truth for changes. You may want to know why.

Coming from an enterprise IT background myself, this story is very familiar to me. We ended up taking some fairly novel measures within our DML scripts to improve our team's ability to make concurrent changes to table data. The trick was to make our ID's deterministic, while preserving the primary key structure of the table. If you're at all interested in hearing about this let me know as I'm happy to provide details on the approach we took.

8. All of our databases include reference data (e.g. States, Countries, Drop-down choices) and we expect this data to be deployed along with schema changes

ReadyRoll is able to synchronize your reference data changes alongside your schema changes, within a single atomic transaction. You can read more about the different approaches to static data synchronization in our documentation.
https://documentation.red-gate.com/display/RR1/Static+Data

I hope this helps. Any questions or clarifications, please don't hesitate to ask.

dallen@nmdp.org

Wow! thanks for the excellent information. The references you gave and the replies are very helpful as we choose between the options.

dnlnln

My pleasure, David. Please let us know if there's anything else we can help with.