Options

specific changeset change automation migration script

Apologies if this has already been asked but I have not been able to find any information on the following topic. I am investigating whether or not SQL Change Automation is a good fit for my project. The issue I have is that I require the ability to only move over specific changesets with a migration script. So instead of comparing dev to prod and moving all changes , I only want to take the change sets related to the feature I want to deploy between environments. That is, if there are three changesets: 123,124,210,211,212 and I only want to deploy 210,211,212 and NOT the other two , how would I accomplish this? Is automation possible in this manner (in terms of CI/CD with SQL server changes)? Any assistance or pointers to links would be most appreciated. 
Tagged:

Answers

  • Options
    Eddie DEddie D Posts: 1,781 Rose Gold 5
    Hi, thank you for your forum post.

    Please take a look at this help document.

    Scroll down to the bottom section 'Controlling execution across different environments'.  As the advice here may provide the advice you are seeking using variables to achieve your goal.

    Many thanks
    Eddie
    Eddie Davis
    Senior Product Support Engineer
    Redgate Software Ltd
    Email: support@red-gate.com
  • Options
    Eddie DEddie D Posts: 1,781 Rose Gold 5
    Hi, 
    It appears that you question has been entered twice on the forum.

    Please follow the advice from my colleague, who provided this information:

     By the wording of your question I am going to assume that you're using state-based deployments (and not migrations).
    Assuming this is the case, the pattern above is indeed possible by using the right branching strategy. You haven't descibed what your VCS is nor your current branch strategy is, so I'll do my best without this information.
    If the database changes (made by your developers) are being pushed to the "Main" branch, and your intent is to release a subset of the changesets, then you create a branch (say, Release1) from Main. By default this will be an exact copy of Main, so you'll need to revert the changesets that you don't want to include in your release.
    Then when you release, you simply use the Release1 branch as the source, rather than Main (which includes all changes).
    You can also create Release1 based on a historic version of Main, and merge in (ie, cherry pick) the changesets that you want. Either way, you end up with the same result, which is a branch that represents the changes that you want to deploy.

    Many Thanks

    Eddie

    Eddie Davis
    Senior Product Support Engineer
    Redgate Software Ltd
    Email: support@red-gate.com
Sign In or Register to comment.