Clean up Migration Scripts history
AMP_Dev
Posts: 9 New member
Hi,
is there a way to clean up all existing Migration Scripts leaving the objects history intact? We want to build Scripts for uncommitted schema changes with RedGate, commit them to TFS and eventually include them in our setup exe. As this is not the intended use case for Migration Scripts, as I learned in reply to this post, we need to adapt our workflow. So, the idea came to mind to clean up the existing Migration Scripts via a scheduled job, but the scripts themselves should be left untouched as well as the history in the SSMS object explorer, so we can keep tracing who did what and when. Is this at all possible?
Any help is greatly appreciated.
Thanks.
Matthias
PS: Switching to ReadyRoll, as mentioned in the linked post, seems not to be an option, as it would be way oversized to license the SQL Toolbelt for all our developers just to use the ReadyRoll VS Plugin.
is there a way to clean up all existing Migration Scripts leaving the objects history intact? We want to build Scripts for uncommitted schema changes with RedGate, commit them to TFS and eventually include them in our setup exe. As this is not the intended use case for Migration Scripts, as I learned in reply to this post, we need to adapt our workflow. So, the idea came to mind to clean up the existing Migration Scripts via a scheduled job, but the scripts themselves should be left untouched as well as the history in the SSMS object explorer, so we can keep tracing who did what and when. Is this at all possible?
Any help is greatly appreciated.
Thanks.
Matthias
PS: Switching to ReadyRoll, as mentioned in the linked post, seems not to be an option, as it would be way oversized to license the SQL Toolbelt for all our developers just to use the ReadyRoll VS Plugin.
Tagged:
Comments
If you don't want the migration scripts to actually be part of an automated deployment process and used during Get Latest, and are unwilling to use ReadyRoll, then I'd suggest separating out your process - so you just commit all your database changes in SQL Source Control without using migration scripts. Whenever you want to generate a change script to be used in your setup.exe, use SQL Compare to generate the appropriate update script from source control versions, and just save those change scripts in a separate folder in TFS.
Redgate Software
thanks for your reply. Ok, that seems to be the best option. We'll investigate the possibility of deleting the migration scripts after we included them in our setup as well, but I think removing them from our workflow and use SQL Compare for the scripts is the way to go here.