Comments
Sort by recent activity
Lolz - looks like Rob C and I are on the same page. :-) @JDenham: Assuming you created your package from scripts maintained by SQL Source Control the package contains the desired state/model and the deployment, under the hood, will use SQL Compare to get the DB into the desired state. Hence, the NuGet packages do not contain your updates/migrations. These are worked out for you by the software.
Hence, as long as the database exists with the correct name you should not need any old packages. / comments
Lolz - looks like Rob C and I are on the same page. :-)@JDenham: Assuming you created your package from scripts maintained by SQL Source Control the package contains the desired state/model and the...
I like to stick an IF NOT EXISTS CREATE DATABASE script in source control for each of my databases (for each environment). This way I can source control the way I set up stuff like file groups and possibly security at a per database level. This is useful because some of that stuff is not included by default with the Redgate tools or people tend to filter it out. (Who has the same users on DEV and PROD?)
Note, add this create script in a parent or sister directory to your SQL Source Control directory. I try to avoid adding my own scripts to the directory you give to Redgate because you can confuse Redgate tools which are designed to parse all the sql scripts in that directory.
Then, I add a simple step in Octopus Deploy to run my IF NOT EXISTS CREATE DATABASE script before the "Redgate Deploy from Package" step. Then you know your DB will always exist. There is an Octopus Deploy step template to run a SQL script here: https://library.octopusdeploy.com/step-templates/73f89638-51d1-4fbb-b68f-b71ba9e86720/actiontemplate-sql-execute-script
This step template asks you to type the script into the Octopus GUI but it does also accept variable substitution so you could package up your SQL scripts into a different NuGet and reference them from that variable. / comments
I like to stick an IF NOT EXISTS CREATE DATABASE script in source control for each of my databases (for each environment). This way I can source control the way I set up stuff like file groups and ...
On a similar note, I'd like an option to only produce a changes.html file if there are changes.
Use case:
My customer has about 20 DBs. All tightly coupled so deployed within the same uber Octopus project. 20 changes.html files is annoying if only 2 or 3 DBs have been updated. I want to be able to only upload the relevant changes.html files as artifacts.
I'm guessing the answer is the same, parse the JSON, but a simpler solution would be appreciated. :-) / comments
On a similar note, I'd like an option to only produce a changes.html file if there are changes.
Use case:
My customer has about 20 DBs. All tightly coupled so deployed within the same uber Octopus ...
In this case I refer you to my original reply I'm afraid. The TeamCity plugins uses SQL Compare under the hood.
If you deleted the data, SQL Compare cannot magically get it back. You will need to put in place some other process to backup the data somehow and restore it. / comments
In this case I refer you to my original reply I'm afraid. The TeamCity plugins uses SQL Compare under the hood.
If you deleted the data, SQL Compare cannot magically get it back. You will need to p...
Forgive me for misunderstanding.
How have you configured your build? Are you using the Redgate TeamCity plugins to build the scripts maintained by Redgate SQL Source Control/ReadyRoll? If not, what build steps are you using to build/deploy your database? / comments
Forgive me for misunderstanding.
How have you configured your build? Are you using the Redgate TeamCity plugins to build the scripts maintained by Redgate SQL Source Control/ReadyRoll? If not, what...
(Most of the Redgate tools use SQL Compare under the hood.) / comments
(Most of the Redgate tools use SQL Compare under the hood.)
SQL Compare does not look at the data in your databases, only the schema. If you drop a column the data is gone.
If you would like to be able to restore it you need to make sure you have backed up the data somehow first.
How much data are we talking about?
For small (<1000 rows-ish) lookup/reference/static data, tables where devs manage the data (eg product codes, person type), you can use the static data feature of SQL Source Control to version the data so you can roll it back later but this is not suitable for large tables or transactional data.
If you want to be alerted whenever SQL Compare will drop a table you should be able to set the max warning level to your taste to fail/abort the build. I believe column drops are high level warnings. / comments
SQL Compare does not look at the data in your databases, only the schema. If you drop a column the data is gone.
If you would like to be able to restore it you need to make sure you have backed up ...
If by VSO you mean VSTS, yes it does.
You can link either to a TFS style repo or a Git style repo.
Note that if using Git with VSTS the commit and get latest options will work fine but Push/Pull won't. Some odd permissions issue.
You could avoid this by using the "working folder" option but this does not fix the problem it just hides it and in the process you lose other functionality. Better to just link as normal and use and external git client or the git command line to do your push/pull. / comments
If by VSO you mean VSTS, yes it does.
You can link either to a TFS style repo or a Git style repo.
Note that if using Git with VSTS the commit and get latest options will work fine but Push/Pull w...
That is fair - and it's a question for someone in the dev team. :-) / comments
That is fair - and it's a question for someone in the dev team. :-)
You could try creating a single PowerShell script (with parameters) that you could add to source control once to handle your deployments. Then, instead of using the plugin you can simply call that same PowerShell script for each build.
This way your configuration for your deployments is in just one place and it is under source control. / comments
You could try creating a single PowerShell script (with parameters) that you could add to source control once to handle your deployments. Then, instead of using the plugin you can simply call that ...