How to commit a Redgate Migration V2 migration script

Question

What is the workflow when committing a Migration V2 script in SQL Source Control?

• Do I need to run the migration script to apply the changes to the development database before committing?
• If so, do I commit both the table and MigrationHistory?

Answer 1

Will answer these in reverse order.

You do need to check in both the table and the migration history TVF. This is so the compare engine has a record of the new state of the table in source control, and so it knows that the old table should not be there.

NB - This is a beta version of migrations v2 and the UI is not in it's final state. We want to make this less confusing so that it is obvious that the migration script replaces the drop and create of a table.

Whether you run the migration script locally or not depends a little on when you are adding your migration script in the process.

If you're following the scenario to rename a table without data in the worked example in the documentation it is assuming that you have not yet renamed the table on your local dev machine. In this case the process is:

• Write the script (which contains an sp_rename command)
• Run the script locally to rename your local table
• Check in the script (and tables) so that other developers and environments pick up the change

That's the general case for most migration scenarios, where you are pre-empting a data loss scenario and scripting around it. However specifically for a table rename scenario there is another way to do things retroactively:

• Rename the table locally (using smart rename or a standard rename)
• Go to the commit tab and click the 'Add Migration Script' helper in the data loss warning screen (see first image below)
• This automatically generates the sp_rename and a suitable guard clause (see second image). You don't need to run it in this case, as you have already made the change
• Proceed to commit as as normal.