Skip to content
← SQL Change Automation

How can we improve SQL Change Automation?

SQL Change Automation

Categories

JUMP TO ANOTHER FORUM

(thinking…)

As an deployment engineer I'd like to run environment specific scripts during deployment

Say we have scenarios where we have client machine configuration stored against machine names. When we deploy to DEV environment, these machines are different to TEST and we need a way to reseed the configuration data for the specific environment.

Having first class support for PreDeploy / PostDeploy scripts which could then be named using Environments (A.DEV.sql, A.TEST.sql) would be a nice feature - Especially if coupled with SQL Source Control.

We've worked around this at the moment but would love this OOTB

21 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Matt @ Evolve Software shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
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.

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Matt @ Evolve Software commented  ·   ·  Report

    We are actually taking a client away from the scenario you describe (backup + restore), as the issues they face are not having any visibility of changes to datasets for integration / acceptance testing - coupled with the fact this is across a number of different countries where the static data is different too.

    The focus for our client is to get everything under source control - if it's not under source control then it doesn't exist. Having their seed script for an environment + country combination now gives them a greater understanding of how this dataset has changed. Being able to manage this from within SQL Source Control would just be a value add.

    We currently create the db from the package and then have a subsequent step in OD to seed the data using a script from the same package - using the conventions that OD gives us in the form of the Country and Environment we are deploying to.

  • Taliesin Sisson commented  ·   ·  Report

    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.