Skip to content

Settings and activity

1 result found

  1. 21 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Kendra responded

    Thanks for this feedback.

    We have quite strong support for this request in SQL Change Automation projects, which support multiple pre- and post- deployment scripts and which also have an option to “seed data” for larger tables which you would like to populate: https://documentation.red-gate.com/sca/developing-databases/concepts/data-population/strategies-for-data-population

    For SQL Source Control, we now support pre- and post- deployment scripts, however you are limited to only one of each type. Additionally, the seed data methodology is not available in SQL Source Control.

    An error occurred while saving the comment
    Taliesin Sisson commented  · 

    Is it not better to pull the configuration out of the database? Then you can make use of standard functionality like Octopus PreDeploy & PostDeploy.

    Databases often span multiple machines, so its probably better to configuration out of the database.

    I also believe that only static data should be in source control (i.e. lookup table stuff). Data should be controlled via backup and restore with a possible data cleansing process in between. Post database restore, this would be place to modify database data for the specific environment.

    You would probably only need to run the restore when switching between branches that mess with table data.