ReadyRoll vs DLM Automation
I am new to RedGate. My manager has purchased us licenses, but I am a bit confused:
1. What is the difference between ReadyRoll and DLM Autoamtion? Their purposes seem to overlap considerably.
2. When would I use ReadyRoll?
3. When would I use DLM Automation?
Current Tools we Use: TFS, Visual Studio 2015, Red Gate, Telerik
1. What is the difference between ReadyRoll and DLM Autoamtion? Their purposes seem to overlap considerably.
2. When would I use ReadyRoll?
3. When would I use DLM Automation?
Current Tools we Use: TFS, Visual Studio 2015, Red Gate, Telerik
Tagged:
Comments
The difference is in their approach: ReadyRoll uses (mostly) a traditional migrations-based approach, where you code up the changes as if you're working directly on a database (ALTER, ADD/DROP COLUMN, INSERT, etc.). It then runs the pre-written scripts in a pre-determined order. It gives developers complete control over the SQL that is written, but also gives them complete responsibility.
DLM Automation uses a few other tools, namely SQL Source Control and SQL Compare. SQL Source Control uses the state-based approach, in that you make your changes on the database and these are always checked into SVN as CREATE statements (generated by the tool). When you build/deploy, SQL Compare will look at your source (SVN, a database, or scripts folder) and your target (usually a database) and generate a migration script to get from A to B. This means you don't need to spend time writing a lot of SQL for simple changes, which is great, but it does mean that you are trusting the tool to get it right every time.
This is a quick summary - both tools provide some 'hybrid' features - ReadyRoll has Programmable Objects and SQL Source Control has Migration Scripts.
Your team will probably have a preference or standard for using one approach vs the other. Learn the process first, then the tools - both have great features and unique advantages and disadvantages.
ReadyRoll appears as stated: a migrations based DLM approach. This is done by creating a ReadyRoll Visual Studio Project and making the necessary project configurations thereafter. Readyroll is a dedicated Visual Studio Project Type, but where is the Visual Studio Project type equivalent for State based approaches?
There may be a way to implement a state based approach using VS and Redgate, but it's not nearly as elegant as the Migrations approach with ReadyRoll.
I find the same issue with Microsoft and the converse: Microsoft has a clean and elegant State based Solution with it's own VS Project Template: Data Project Template (using SSDT to drive the work).
How would I setup a Visual Studio Database project for State based approach using Red Gate tools?
It appears as if the built in Data Project offered by Microsoft is not supported or compatible with Red Gate Source control either, so I am still confused as to how to use RG for a State based approach.
What I am tasked to do in my workplace is to use RedGate tools, Visual Studio 2015 Enterprise, and TFS 2012 to come up wtih a Demo for both approaches.
I do understand the principles behind both approaches. My problem is the State side implementation from Red Gate remains a mystery. ReadyRoll seems to fit quite well into the Migrations part. I can Demo Ready Roll no problem. It's the State based approach I am at a loss as to how to setup with Red Gate tools. I can configure RG Source Control to point to TFS, but this does not associate the source control files to an actual Visual Studio Project. This seems to a serious incompleteness relative to ReadyRoll with Migrations.
Product Manager
Redgate Software
I will show this to management and try to explain the structure is different for State. This does help a lot Grant thank you. I was beating myself up thinking there was something I am missing, but apparently how I understood this working is actually how it works. lol
I recently suggested to management we look at some tooling and showed him a 7 min video of what Red Gate source control does and he was impressed.
I have been tasked to choose a few tools and demo them. The way I understand db change management though there are two fundamental approaches: migrations or model/state approach.
I am trying to put a demo together for both approaches for three tools to demo for management soon.
Microsoft apparently does not have a Migrations approach tool unless I have missed it?
Red Gate covers both approaches well. I was just a wee bit confused about the difference in implementation (subtle difference, but important to note).
I don't decide what approach to use, I will let our esteemed managers decide that. I am just here for technical implementations.
I think the choice between approaches really depends on the nature of the product and the team that supports it. I think both approaches have their place.
Apologies for the "difference in implementation". We're actively working on this, and you will see improvements in this area over time.
Although ReadyRoll is a Visual Studio add-in, most ReadyRoll users have SSMS open and use this to apply changes to their dev instance. It doesn't matter which tool you use to make your changes. Back in Visual Studio, ReadyRoll's DBSync window will enumerate these changes and will offer to save them to the project.
Do let us know if you need any further help understanding the tools for the purposes of your demo!
Product Manager
Redgate Software
Once Grant confirmed RedGate implements the two approaches in a different way things all made sense to me. In my head I was expecting a VS Project Template for State/Model as well.
It would be great if there was, just all it ReadyModel or something, I dunno...
I have to demo for management soon. I expect them to prefer model approach to Migration, but I've been wrong before...
It' just harder to sell the Model approach for Red Gate to management right now. Management here wants to see everything in Visual Studio. I do prefer Red Gate overall. I will do my best to improvise.
Thanks guys. This clears up a lot of confusion.
Happy I could help at all.
In case it's of any use, we have been using the state-based approach in recent months but are considering switching over to ReadyRoll, which we're evaluating at the moment. The reasons for this are numerous, but here are a few:
Obviously these observations are all situation-dependent and may be less or more important to others - they're just a few thoughts we've had over the last few weeks.
Over time we intend to bring the ReadyRoll experience into SSMS, so although you need to switch back to VS today, it will improve as we push out new releases.
Product Manager
Redgate Software