Comments
Sort by recent activity
Hello, Yes, the build process creates a database for validation purposes. If you skip this step, you would lose assurances that the code you have committed is valid SQL that is suitable for a deployment. You have the option to have the build dynamically create the database for this purpose and drop it after, or if it is more convenient you can hardcode a name for the database and reuse an existing database for each build. (The database will be "cleaned" so validation can succeed.) Can you explain why you would like to skip this step? Is there some barrier preventing you from using a database for this purpose, or some problem that you are hitting? Cheers, Kendra / comments
Hello,Yes, the build process creates a database for validation purposes. If you skip this step, you would lose assurances that the code you have committed is valid SQL that is suitable for a deploy...
Hello, In order for changes to be detected in the data inside the table, you need to add the table as a "Static Data Table". This indicates that you'd like to version control the data. This can be done in either Visual Studio or SSMS. This article shows how it works in SSMS and also links to some helpful resources: Using SQL Change Automation in SSMS to Track Static Data Changes - Redgate Software (red-gate.com) Hope this helps, Kendra / comments
Hello,In order for changes to be detected in the data inside the table, you need to add the table as a "Static Data Table". This indicates that you'd like to version control the data.This can be do...
One follow up on this -- if you're having issues getting this set up, consider opening a ticket with our support team. They're excellent and if you hit some hurdles, opening a ticket with them can help you move forward quickly. More info on contacting them is at Support (red-gate.com) -- scroll down and there's a gray bar with all the contact methods. / comments
One follow up on this -- if you're having issues getting this set up, consider opening a ticket with our support team. They're excellent and if you hit some hurdles, opening a ticket with them can ...
Hello, To deploy a SQL Change Automation project, the process we recommend flows like this:
Run a successful build for the code you want to deploy. This outputs an artifact in the form of a NUGET package.
Deployment is a two step process:
A. Create a release artifact using the NUGET package from the build and setting the target database. This looks at what has been deployed so far to the target database and also can evaluate things like whether drift has occurred since your last deployment.
B. Deploy the release artifact to the target database. If you are sure that all target databases will be the same and are not concerned about drift, it is possible to create a release artifact against one database, and then deploy it to as many target databases as needed.
All of the steps above can be done using PowerShell. (References here have good examples: New-DatabaseReleaseArtifact, Use-DatabaseReleaseArtifact) To dig into your question, the NUGET package from the build does essentially contain a copy of the migration files from the project. So this process is, essentially, moving the migration files for you. But it also adds significant functionality on top of that, like checking which migrations have already been run against the target, running the migrations in the same order as has been tested in the verify and build process, etc. Hope this helps, Kendra / comments
Hello,To deploy a SQL Change Automation project, the process we recommend flows like this:
Run a successful build for the code you want to deploy. This outputs an artifact in the form of a NUGET ...
Hello, Apologies for the delay, just catching up on this thread this morning. I believe we have shifted the discussion of question #4 to this thread now. Cheers, Kendra / comments
Hello,Apologies for the delay, just catching up on this thread this morning. I believe we have shifted the discussion of question #4 to this thread now.Cheers,Kendra
As a Redgater, I'm ineligible to win, but I can't resist adding a tip! In SQL Change Automation in Visual Studio, there's a hidden filter capability When importing changes from a database to generate migrations, simply begin typing to filter out changes by object name. / comments
As a Redgater, I'm ineligible to win, but I can't resist adding a tip!In SQL Change Automation in Visual Studio, there's a hidden filter capabilityWhen importing changes from a database to generate...
Hi, Following up on this, I think for some reason folks were not seeing the version which Sergio mentioned (and higher). This issue was fixed in 7.2.5.11449, which released on Oct 22nd to the Frequent Updates channel. The version 7.2.4.11418 was the prior release from October 6th. (Release notes sequence is here.) To get the higher version, you need to click on "Help" at the top right of SQL Source Control and select "Configure Frequent Updates", then check off "Show frequent update releases" in the pop up. Following this, when you click "Help" again and "Check for Updates", it will show the latest "fast ring" release. As of today we are up to 7.2.14.11864. Hope this helps, Kendra / comments
Hi, Following up on this, I think for some reason folks were not seeing the version which Sergio mentioned (and higher). This issue was fixed in 7.2.5.11449, which released on Oct 22nd to the Frequ...
Hello! I've posted a blog thinking through lots of different options for this here: https://www.red-gate.com/simple-talk/blogs/reordering-deployments-in-database-devops/ It got long enough that a post makes sense. Hope this helps, and happy to dig into things in greater detail and address other scenarios if that would be helpful! Kendra / comments
Hello!I've posted a blog thinking through lots of different options for this here: https://www.red-gate.com/simple-talk/blogs/reordering-deployments-in-database-devops/It got long enough that a pos...
Hi Peter, This is a really great question, and I think we can develop some good content around this concept, and maybe even go a little farther. I think there are a couple of clarifying questions that might help me get my head around the best way to think through this. 1) How many total environments are in the mix outside of production? In other words, after the integration environment, is there a QA or Staging environment that things get deployed to before production? The reason I ask is that if we don't have another environment in the pipeline before production, then it may become more important to "reset" the integration environment and then only deploy feature 2 to it. (Even if the two things are feature isolated, the application might have some sort of dependency we wouldn't find without doing this.) 2) My second question was if we had the option to use something like Clone or a snapshotting tool to reset the environments in the scenario. It sounds like we do in this case, so I will pull that into consideration. 3) Are you working primarily with SCA in Visual Studio or SSMS? If it's SSMS, then I'm curious if you've updated the plugin since Sept 23rd -- there was an update in that release which helps with removing migration scripts in terms of the schema model. (Visual Studio already had the ability to handle deletions of migration scripts.) Thanks very much for the thoughtful question and looking forward to working through this scenario more on Monday. Have a great weekend. Kendra / comments
Hi Peter,This is a really great question, and I think we can develop some good content around this concept, and maybe even go a little farther.I think there are a couple of clarifying questions tha...