I have searched the forums and was unable to find this question being asked anywhere, but please feel free to redirect me to an existing thread if it exists.
We have been using SSC for several months now, but with manual migrations. We are just now hooking into our automation server (Jenkins) to automate push-button SQL migrations along side our already-working push-button web-code migrations.
My question is what to do with the handful of DB scripts I've always been manually running that don't seem to fit inside of SSC. Most of these are some sort of back-fill or migration of content in a non-static table. (Our site is a CMS, and while most content is managed directly on production, some content that is closely tied to new development is entered on the dev environment and migrated along side it's dependent code)
The issue with these sort of scripts is that many of them don't correspond with a specific DB commit per se but still are required for the rest of the application code changes on the ticket to work. A made-up example would be a backfill script to lower the price of all products by $10 in conjunction with new discounting logic in the shopping cart.
Is it possible to introduce a migration script into SSC, without having a prior DB commit to piggy back it on? Our goal is that a member of the QA team can click a button in the automation server that, without any programmer intervention, will wipe out the database with a recent backup of production and deploy ALL changes up to the HEAD revision of the VCS.
One of the other developers has suggested also using DBDeploy or Flyaway in conjunction with SSC to handle a "scripts" folder of other stuff that has to be run during a deployment, but I'd like to keep to a single DB versioning/migration tool.
Thanks in advance for your suggestions.