Comments
Sort by recent activity
One thing you could do is select the dedicated option even though you are using shared. For various complicated technical reasons it will probably work fine. In order to explain that it might be worth actually scheduling a skype call to talk through it.
However, it's ugly and smelly and you should just move to the dedicated model. / comments
One thing you could do is select the dedicated option even though you are using shared. For various complicated technical reasons it will probably work fine. In order to explain that it might be wo...
2 options:
OPTION 1:
Write your own powershell rather than using the default step template.
For example:
$scriptsFolder = "C:\Work\scripts" #replace with the location of your nuget package, probably using one of the #[Octopus.action[stepname]... system variables
$test = New-DlmDatabaseConnection -ServerInstance "test01\sql2014" -Database "Test" -Username "sa" -Password "P@ssw0rd" # Username and password only necessary if using SQL Auth. ServerInstance and Database should probably be parameterised
$syncResult = Sync-DlmDatabaseSchema -Source $scriptsFolder -Target $test
Out-File $syncResult.UpdateSql -FilePath "C:\Work\update.sql"
(See example 4 in docs for details here: https://documentation.red-gate.com/dlma2/cmdlet-reference/sync-dlmdatabaseschema)
OPTION 2:
Use 2 steps:
1. Redgate - Create Database Release - https://library.octopusdeploy.com/step-templates/c20b70dc-69aa-42a1-85db-6d37341b63e3/actiontemplate-redgate-create-database-release
2. Redgate - Deploy from Database Release - https://library.octopusdeploy.com/step-templates/7d18aeb8-5e69-4c91-aca4-0d71022944e8/actiontemplate-redgate-deploy-from-database-release
The first step will create various resources, including a plain sql script and a nice html diff report in advance of deployment. Both will be uploaded as an artifact. You could optionally add a "Manual intervention" step in between the create and deploy steps to enable a review. Perhaps just scope that to the production/pre-production environment?
WHICH TO CHOOSE?
Option 1 is quicker/simpler but requires writing your own PS
Option 2 does not require custom scripting and enables review, but the script is created in advance and it's a slightly more complex process. Also, your deployments will take longer. / comments
2 options:
OPTION 1:
Write your own powershell rather than using the default step template.
For example:
$scriptsFolder = "C:\Work\scripts" #replace with the location of your nuget package, probabl...
If you don't include the temporary database switch it uses localDB on the agent as the defualt! ;-P
I guess the question is will your references resolve properly from local DB to the dependent databases. (e.g. if you used three part names - db.schema.table) then those dbs will also need to exist on localdb. / comments
If you don't include the temporary database switch it uses localDB on the agent as the defualt! ;-P
I guess the question is will your references resolve properly from local DB to the dependent data...
Point DLMA at a dev or test server that has all the dependent objects. It will build the database on that server, where all the dependencies will exists, and it will delete the database when done. / comments
Point DLMA at a dev or test server that has all the dependent objects. It will build the database on that server, where all the dependencies will exists, and it will delete the database when done.
You need to handle that separately. / comments
You need to handle that separately.
You say "on the second time of deployment".
Have you tried to redeploy the same release against the same DB twice?
You should note that a DlmDatabaseRelease includes a specific upgrade script (in your case, I imagine it inserts some data). If you run the release twice it will try to run that upgrade script twice. This should be caught in the pre-deployment drift check (unless you have disabled it) and the deployment should be aborted.
If you want DLM Automation to generate a script on the fly to just make it match your source you should use the sync cmdlet instead. The idea of a DlmDatabaseRelease is that you can re-use the same deployment script in multiple environments. For example, if you wanted to do a dry-run deployment on a staging or pre-prod DB / comments
You say "on the second time of deployment".
Have you tried to redeploy the same release against the same DB twice?
You should note that a DlmDatabaseRelease includes a specific upgrade script (in y...
Use SQL Compare.
SQL Data Compare deploys the data contained in tables. To deploy the table itself use SQL Compare. / comments
Use SQL Compare.
SQL Data Compare deploys the data contained in tables. To deploy the table itself use SQL Compare.
If the user has a SQL Toolbelt licence - yes. Otherwise no. / comments
If the user has a SQL Toolbelt licence - yes. Otherwise no.
To install tSQLt on a DB, follow these instructions:
If using Redgate SQL Test: https://documentation.red-gate.com/sqt2/adding-a-database-to-sql-test
If not using Redgate SQL Test: http://tsqlt.org/user-guide/quick-start/ / comments
To install tSQLt on a DB, follow these instructions:
If using Redgate SQL Test:https://documentation.red-gate.com/sqt2/adding-a-database-to-sql-test
If not using Redgate SQL Test:http://tsqlt.org/u...