Skip to content

SQL Change Automation

SQL Change Automation works with your CI server and release management system, so you test, build, and release your database alongside your application code. To find out more please visit our website.

We need your help to shape SQL Change Automation into a great product that helps database professionals. We’d love to hear about your feature ideas and suggestions, so please enter them below.

If you have any questions or need help with SQL Change Automation, please visit our support forums.

SQL Change Automation

Categories

JUMP TO ANOTHER FORUM

49 results found

  1. Could you please add svn integration to Change Automation SSMS plugin.

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. Allow project/assembly references to be nugets.

    This would allow better project/build separation and/or less staging work.

    2 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. When deploying to HA environments with servers in multiple subnets, you get an error if the sqlcmd runs on the wrong one. Per support the functionality was added to the powershell but was not exposed to the plugin.

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. Since there is no add-in for SQL Source Control for Visual Studio, there is no mechanism for effectively versioning changes inside Visual Studio.

    The SQL Change Automation Core (only currently available as part of VS 2017 Enterprise) provided a mechanism for maintain changes scripts that are fully integrated into VS Project (and therefore can be placed under source control as a part of the project).

    This combination is Developer focused (rather than dev-ops focus of full SQL Change Automation)

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. In TeamCity plugin step "Redgate SQL Change Automation Build" build.version is being normalized to SemVer (for example 2.1 -> 2.1.0 or 2.1.0.0 -> 2.1.0).
    Because we use these nuget packages internally only we don't need to follow SemVer. It seems that Nuget team doesn't want to remove that normalization (https://github.com/NuGet/Home/issues/3050) so solution would be to create and use custom Nuget build. Thats how Octopu Deploy solved this issue: https://github.com/OctopusDeploy/Issues/issues/2898

    6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. Allow a change script to run on Azure SQL Data Warehouse

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Kendra responded

    Thanks for this suggestion.

    In the year since your request, Redgate has acquired Flyway. Flyway is an automated deployment tool, and while it doesn’t offer help in authoring scripts or a full continuous integration process, it can help you automate deployments to Azure SQL Data Warehouse (now known as Azure Synapse).

    More information on flyway is here: https://flywaydb.org/documentation/database/azuresynapse

    Since this doesn’t offer the same level of full CI/CD support as in SQL Change Automation, I am keeping this request open for further comments and feedback.

  7. I would like the option of creating my documentation outside of a database artifact. I would rather it not be embedded in a nuget or zip file with the deployment files. Currently the object created by New-DatabaseDocumentation can only be passed to New-DatabaseBuildArtifact. It would be great to just pass it to a new export cmdlet so it can be saved to disk.

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. SQL Change Automation idea: Please re-add the condition feature in the migration script in the packaged script since this was working before in ReadyRoll.

    More details in https://productsupport.red-gate.com/hc/en-us/requests/133672?page=1

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. We use TeamCity and there seems to be no way (or no simple way) to disable CodeGuard checking. It's not really useful there for us (and we use SonarCloud which has nice integration/quality gates for GitHub).

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. Since we are already required to provide a PackageVersion parameter to Export-DatabaseBuildArtifact, I would like to see the PackageVersion SQLCMD variableset to that input value in the PackageScript.sql with in the build artifact.

    I would also like to see a new parameter for Invoke-DatabaseBuild, SQlCmdVariables, that wouldd allow us to pass in ReleaseVersion, PackageVersionm, and other SQLCMD vars that would be set in the PAckahgeScript.sql (and the PackageScript property of the returned BuildArtifact object.

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. We would like to add SQLCMD variables to our SQL Change Automation projects to denote whether a deployment is applying to a Local environment or to our production pipeline (isLocalDeployment). Our thought for how to do this with the least amount of changes required was to default the variable to be isLocalDeployment = FALSE. This would mean that if we are doing a deployment to a local developer database we would run additional scripts to configure that environment, but once the project is deployed into our normal production deployment pipeline those scripts would no longer run and we wouldn't have…

    6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. When performing a database build for Continuous Integration Plugins can we have a setting to ignore static data?

    13 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. For the build package task it would be helpful to offer an environment variable as the version number. Same options as the nuget package task that's already available for standard nuget package builds.

    Many people generate version numbers during build, so we cannot know the build number before hand.

    Another option that would be nice is a substring of the build number, which is where many people append their version numbers.

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. NuGet 3.5 will support semantic versioning and it would be nice if DLM Automation could implement it too.

    14 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. 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)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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.

  17. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    under review  ·  Kendra responded

    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

  18. Like the test in SQL Prompt.

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. I would like to be able to rollback deployments done with SQL Release.

    20 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  20. 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
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    under review  ·  Kendra responded

    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/

  • Don't see your idea?