Settings and activity
14 results found
-
1 vote
Doug Tucker
shared this idea
·
-
12 votes
While we haven’t implemented this exact feature, I want to share some information with similar patterns which may help some readers, or inspire comments or feedback in others.
One common approach is to manage multi-database deployments via an orchestrator, such as Azure DevOps, Octopus Deploy, or similar. This may be managed concurrently or in a simple loop depending on the needs. One example of this with Azure DevOps is demonstrated here: https://www.youtube.com/watch?v=-rZxLCRrgmI
When using a single release artifact to deploy to many databases, it’s important that you control for database drift on a regular basis outside of the deployment process. One way to do that is to set up monitoring that alerts you to schema changes that occur. An example of monitoring for this in SQL Monitor is in this custom metric: https://sqlmonitormetrics.red-gate.com/unauthorized-object-changes/
An error occurred while saving the comment An error occurred while saving the comment Doug Tucker
commented
I need to execute Use-DlmDatabaseRelease against hundreds of databases per server (times a dozen or more servers). None of the Powershell multithreading approaches I've found matches the speed of SQL Multiscript. It would be a huge performance boost to be able to feed a Use-... statement or a generic script block to a Multiscript cmdlet for swift parallel handling.
An error occurred while saving the comment Doug Tucker
commented
I'd like to be able to release the same schema change to thousands of databases (hundreds per server across a dozen or more servers). Concurrency would be a must!
Doug Tucker
supported this idea
·
-
480 votes
Thank you everyone for your comments and votes on this over the years. While I don’t have a 100% full resolution for this suggestion, I can sum up our current recommendations here. Continued feedback is very welcome.
Our current recommendation is to use the post-deployment script feature of SQL Source Control (released in V6.3) to manage SQL Server Agent jobs.
An example script for this is here: https://documentation.red-gate.com/soc/common-tasks/working-with-pre-post-deployment-scripts/create-sql-server-agent-job
As some commenters in this thread have alluded to, it is possible (and sometimes very common) for SQL Agent jobs to have steps that touch multiple databases on a single SQL Server Instance. For this reason, some customers prefer to create a separate database for instance-level management and objects (sometimes named DBA or similar) and choose to manage things like linked servers and SQL Agent jobs with the post-script associated with that database.
This separate-database architecture also makes sense if the jobs…
Doug Tucker
supported this idea
·
-
6 votesDoug Tucker
supported this idea
·
-
12 votesDoug Tucker
supported this idea
·
-
14 votesDoug Tucker
supported this idea
·
-
29 votesDoug Tucker
supported this idea
·
-
15 votesDoug Tucker
supported this idea
·
-
20 votes
Our current guidance for rollback support on SQL Change Automation is here: https://documentation.red-gate.com/sca/developing-databases/concepts/advanced-concepts/rollbacks
Our roadmap for 2021 does include further researching and evolving rollback procedures: https://www.red-gate.com/products/redgate-deploy/roadmap
Doug Tucker
supported this idea
·
An error occurred while saving the comment Doug Tucker
commented
Backup/restore isn't a viable alternative when the deployment targets hundreds of databases on a single server (much less thousands of databases across dozens of servers).
The "failure" may not be schema at all, but rather the discovery that the application driving the schema change has just deployed a fatal error and needs to roll back to the previous release of code/schema. For this reason, any Update.sql we create comes with a corresponding Antidote.sql to undo that update, so far as is possible (e.g. columns dropped can't be undropped).
-
6 votesDoug Tucker
supported this idea
·
-
46 votes
An error occurred while saving the comment Doug Tucker
commented
Ditto for Git
-
10 votesDoug Tucker
supported this idea
·
An error occurred while saving the comment Doug Tucker
commented
Not just security items, all the server-level objects not tied to a specific database, such as linked servers and server triggers, need to be captured in source control.
-
13 votes
-
16 votesDoug Tucker
supported this idea
·
We already use SQL Multi Script for concurrent deployment - how about incorporating its functionality into DLM Automation? See suggestion "Expose SQL Multiscript functionality via DLM Automation cmdlet"