50 results found
-
Svn integration for SSMS SQL Change automation
Could you please add svn integration to Change Automation SSMS plugin.
4 votes -
Flag to Force a deployment
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 votesFor 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.
-
Add SQL Change Automation Core option as an add-on for SQL Toolbelt Essentials
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 -
Support Nuget references in Sql Projects
Allow project/assembly references to be nugets.
This would allow better project/build separation and/or less staging work.
2 votes -
Support Deployments to Azure SQL Data Warehouse
Allow a change script to run on Azure SQL Data Warehouse
3 votes
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.
-
Add Multisubnet failover support to Azure Devops pipeline plugin
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 -
Disable nuget package version normalization in TeamCity plugin
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/28986 votes -
Please re-add the condition feature in the migration script in the packaged script
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 -
Set CodeGuard Checking Default to Off
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 -
PackageVersion SQLCMD var should be set in PackageScript.sql when calling Export-DatabaseBuildArtifact
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 -
New powershell cmdlet: Export-DatabaseDocumentation
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 -
Reduce Unnecessary Statements In Deployment Scripts
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 -
Add SqlCmdVariable parameter to Build procedure
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 -
Offer environment variable as a Build Package Version Number source
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 -
Team City Plugin - Timeout Field
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 -
Build Plugins - Ignore Static Data
When performing a database build for Continuous Integration Plugins can we have a setting to ignore static data?
13 votes -
Incorporate new/improved SQL Compare differences views into DLM Automation Changes.html
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 -
Support publishing custom schema names to DLM Dashboard
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 -
Add database connection for database testing in VSTS extension
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 -
Add the option to skip delete operations
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
- Don't see your idea?