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. Occasionally the only changes in a specific build is the addition to the PostScript post-deployment script. Since there are no schema changes, the PostScript change is not executed.

    Faking a schema change by adding a comment or something is a poor workaround in an automated CI process.

    A simple flag -AlwaysRunUpgrade to always run the PreScript and PostScript as part of the deployment would be ideal.

    17 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

    For clarification for readers, this request is specific to SQL Source Control projects which are deployed by SQL Change Automation. Comments in the item give more detail.

  2. 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)
  3. 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)
  4. 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.

  5. 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)
  6. 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)
  7. 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)
  8. 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)
  9. 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)
  10. 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)
  11. When deploying database changes (we are using the plugin for Octopus Deploy), it would be useful if there were not so many superfluous statements included in the deployment script. This is particularly prevalent when deploying static data, it appears that the deployment script will drop constraints on a table where it is updating table whether the constraints are material to the update or not. The code seems to be going down the path of least resistance which makes for bloated and hard to read code whereas I would like it if the code were as lean as possible to allow…

    0 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)
  12. 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)
  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. During the build portion of our pipeline, builds occasionally fail due to timeout while inserting static data. There is a work around where you open up the powershell scripts underneath DLM to specify the timeout, but it would be much more useful to have this as a field in the Team City plugin.

    I'm sure other plugins could use this as well.

    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)
  15. 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)
  16. The latest version of SQL Compare introduced improvements to the SQL View as well as a new Summary View, as detailed here: https://www.red-gate.com/hub/product-learning/sql-compare/sql-compare-summary-view

    It would be good if the Changes.html file generated by DLM Automation could also display the results in the same format so that it is easier and clearer to see the changes that are being deployed.

    It would also be better if changes to static data were broken down so that for each static data table modified it explicitly states which records have been added/removed/modified/remain identical.

    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)
  17. Please make it possible to specify a custom schema name when publishing a build to DLM Dashboard. The current implementation only supports using the nuget package version which has restrictive formatting rules, so for example it does not work for apps which use a four-part version number.

    9 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)
  18. Currently if you use the VSTS extension you can't ask it to run Tests against a database connection. If you allowed this then it would provide more flexibility.

    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)
  19. It would be good if you could skip delete operations when deploying database changes automatically. This means if we update our application code and database changes then old versions of the application code can continue to use the old database functionality.

    2 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)
  20. 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)
  • Don't see your idea?