49 results found
When importing static data on a sync operation, I'd like the option to disable (and re-enable afterwards) check constraints.
At the moment the only option I have is to ignore them which means my CI database is not built correctly3 votes
Given that no GUI is required with Release and dotnet core is out, has this option been considered? Most deployment tools are Linux based and Octopus is limited in usefulness, or at least our application has outgrown it.31 votes
As an build engineer I'd like to be able to override the package version number in the TeamCity plugin
We are currently using GitFlow for a small POC and have hit an issue as we are unable to use a NuGet safe version number for our package name without going through some hoops.
Adding support for an optional version number field in the SQL CI TeamCity plugin would be a nice addition and allow us to drive this from another variable.5 votes
Like the test in SQL Prompt.7 votes
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 OOTB21 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.
Currently I have option to include or exclude data compare using -IgnoreStaticData switch (New-DatabaseRelease cmdlet).
But since part of my static data tables columns are environment based (in each environment dev/qa/prod I got different url)
I have to exclude columns.
Via Data Compare commad line I am using /Project switch which contains the exclude columns definitions.
(Another method that exists is IncludeColumns and /ExcludeColumns switches)
I need this options in order to start using SQL Release, otherwise static data deployment will make undesired changes.27 votes
We have a couple of options for this which may help some folks who have voted or commented.
For SQL Change Automation projects, the SSMS plugin now allows users to select only specific columns to add to the project for static data tables.
For both SQL Change Automation projects and for SQL Source Control projects, you also have the option to use a post-deployment script to dynamically control how static data is deployed to a given environment.
An example post-deployment script for this is here: https://documentation.red-gate.com/soc7/common-tasks/working-with-pre-post-deployment-scripts/static-data
I would like to be able to rollback deployments done with SQL Release.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
I want to be able to release database changes across several databases. Once confident that the targets are all ready to go, and that the deployment script is correct, I want the deployment to be concurrent (so that it takes less time).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/
I want to know which object failed to deploy when a SQL Server error is thrown during validation.6 votes
- Don't see your idea?