1 result found
21 votesKendra 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 commentTaliesin 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.