Built-in migrations feature deprecated in SQL Source Control 7.1.9

LubosMLubosM Posts: 14 Bronze 1
edited January 23, 2020 8:49PM in SQL Source Control
As of version 7.1.9 of SQL Source Control, we have replaced the existing built-in Migrations feature with the superior migrations capability of SQL Change Automation.

Why we’re making this change
The previous built-in migrations feature worked by combining custom migration scripts with SQL Source Control’s native state-based deployments. User feedback has indicated that this approach was confusing to grasp and any issues were tricky to troubleshoot.

The approach taken in SQL Change Automation for SSMS is far simpler as it uses migration scripts exclusively in the deployment process. These migration scripts are auto-generated by SQL Change Automation and can, of course, be customized.

If you have any existing projects that are using the built-in migrations capability, they will not be affected, but there will be no further updates to the feature and we recommend that you use SQL Change Automation to generate migration scripts from SQL Source Control instead.

Comments

  • TheoLTheoL Posts: 7 New member
    Does this mean those on Toolbelt Essentials essentially lose this functionality completely (for new projects)?  
  • TheoL said:
    Does this mean those on Toolbelt Essentials essentially lose this functionality completely (for new projects)?  
    We left a backdoor for those that really want to continue using it - you can set AlwaysEnableMigrationsPage to True in the UI options in %LOCALAPPDATA%\Red Gate\SQL Source Control 7\RedGate_SQLSourceControl_CommonUI_UIOptions.xml
  • @TheoL - I have emailed you separately about this.

    David Atkinson
    Product Manager
    Redgate Software
  • TheoLTheoL Posts: 7 New member
    TheoL said:
    Does this mean those on Toolbelt Essentials essentially lose this functionality completely (for new projects)?  
    We left a backdoor for those that really want to continue using it - you can set AlwaysEnableMigrationsPage to True in the UI options in %LOCALAPPDATA%\Red Gate\SQL Source Control 7\RedGate_SQLSourceControl_CommonUI_UIOptions.xml
    Unless the feature actively maintains inter-operability with future versions of SQL Compare  and SQL Change Automation, then this is only a temporary solution.
  • SebazzzSebazzz Posts: 4 New member
    @TheoL - I have emailed you separately about this.

    Can we keep this discussion public, please?

    This also affects us. We have the toolbelt license, and I'm afraid this means our entire license for SQL Source Control useless for us as well. The backdoor method is only a temporary solution of course.


  • @Sebazzz - SQL Source Control is still very much supported. If you're using SQL Source Control the obvious option is to carry on using this and simply use SQL Change Automation to generate migrations scripts. Have you got any specific questions on this approach? 

    (We would recommend against using the back door except as a temporary measure)

    David Atkinson
    Product Manager
    Redgate Software
  • SebazzzSebazzz Posts: 4 New member
    @Sebazzz - SQL Source Control is still very much supported. If you're using SQL Source Control the obvious option is to carry on using this and simply use SQL Change Automation to generate migrations scripts. Have you got any specific questions on this approach? 

    (We would recommend against using the back door except as a temporary measure)


    I'm unclear what the value of SQL Source Control is when we would have SQL Change Automation. Apparently from SQL Change Automation you primarily work from the project (apparently it is the SSDT equivalent from Redgate), but other than that you can use manual migrations and version the database.

    --
    The problem is that we currently use the manual migration feature. Not only for data migrations, but for every migration. The resulting migration scripts we stitch together and hand over to MSDeploy, which deploys these changes to environments where no direct SQL connection from the build server is possible. These changes are also deployed together with data migrations from an internally developed tool that allows our clients to translate records in our database.
  • @Sebazzz - The workflow in SQL Change Automation is to create a migration script for every change you save into the project. Although this is mitigated the "programmable objects" feature, this can cause a large number of sometimes unnecessary migration scripts that end up running when you eventually deploy. Another difference if you use SQL Change Automation is that changes are shared between developers using these migration scripts. When used with care this is fine, but it's brittle in situations where developers may have made changes to their dev database that have dependencies with the changes being made by the migration script. If a migration script fails to apply to a dev environment, it can be tricky to troubleshoot and to work around. SQL Source Control uses a state-based approach for developer collarboration, which means that the scripts that are applied are custom-generated to work on each development environment, regardless of changes that have been made. Of course if you're a single database developer, or within teams where developers never work on objects that affect each other, this won't be a consideration.

    We plan to publish more help on the differing approaches, outlining the pros and cons of each.
    David Atkinson
    Product Manager
    Redgate Software
  • SebazzzSebazzz Posts: 4 New member
    We plan to publish more help on the differing approaches, outlining the pros and cons of each.

    Do you have an update on this, David? Thank you.
  • @Sebazzz - this is a good starting point: https://www.red-gate.com/hub/product-learning/sql-toolbelt/a-hybrid-approach-to-database-devops
    Is there any specific information you were hoping for that isn't covered in this article? 
    David Atkinson
    Product Manager
    Redgate Software
Sign In or Register to comment.