New db deployment targets added. DBs were moved to another instance. Deployment refers to old DB target although configured for the new one

tonyag98 · 5 March 2019 20:12

New db deployment targets added. DBs were moved to another instance. Deployment refers to old DB target although configured for the new one. How can we force deploy to the new DB instance?

tonyag98 · 5 March 2019 21:43

FYI,

DBs were moved to another instance. Deployment refers to old DB target although configured for the new one. How can we force option without having to rebuild a new plan.

Here’s the scenario.

We have two new instances, #1 & #2.
Deployments were done successfully from those targets initially.
There were 6 DBs that were transferred from instance #2 to #1.
a. Connection strings, dbs and roles were reconfigured of pointing to instance #1.
Attempted DB deployment for one of DBs that were transferred from instance #2 to #1.
a. Red-gate cmdlet SQL Compare runs detects old server read-only.
Deployment fails as though if it were pointing to the old DB instance #2.

Regards.

TG

Kenneth_Bates · 6 March 2019 00:01

Hi TG,

Thanks for getting in touch! I’ve responded to your question via email, but I’ll post it here as well to be thorough.

I suspect you’d just want to simply update the release snapshot. This will update the existing release to apply any changes made to your variables since that release was initially created, and when redeploying it will take those new updated variables. Updating the variable snapshot for a release can be done via the web portal under the given release page’s Variable Snapshot section, as shown in the screenshot below.

Alternatively, you can update the variables via the API, and you can refer to our sample script repository to just that.

github.com

OctopusDeploy/OctopusDeploy-Api/blob/master/REST/PowerShell/Releases/Release_UpdateVariables.ps1

##CONFIG
$OctopusURL = "" #Octopus URL
$OctopusAPIKey = "" #Octopus API Key
$releaseId = "" #Release Id

##PROCESS##
$header = @{ "X-Octopus-ApiKey" = $octopusAPIKey }


Invoke-WebRequest $OctopusURL/api/releases/$releaseId/snapshot-variables -Method Post -Headers $header

Let me know if this helps, and don’t hesitate to reach out if you have any further questions moving forward.

Best regards,

tonyag98 · 6 March 2019 20:54

So Ken. Are you saying that I can update the variables here in the snapshot without having to rebuild in bamboo, but redeploy using this?

Kenneth_Bates · 6 March 2019 22:41

Hi Tonya,

Thanks for following up! At first read, I assumed (and perhaps incorrectly, let me know if so) that the changes to connection strings, dbs and roles were done via variables only. If that’s the case, updating the release’s variable snapshot will be all that’s required.

If you made changes to your deployment process, like scoping your step to a new role, then updating the variable snapshot won’t update that piece. You could create a new release in Octopus using the same package version and deploy that. This will create a new snapshot of the projects deployment process and variables at that point in time.

If you make any changes to the package itself, there isn’t a way to update the package contents in Octopus. This would require you to rebuild in Bamboo to get the new package to deploy.

I hope this helps! Please let me know if I’ve misunderstood anything about your scenario, or if you have any other questions moving forward.

Best regards,

Kenny

system · 5 April 2019 22:45

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.