We are trying to accomplish a seamless Octopus deploy(no manual intervention) from AG primary servers always on, if the deploy switches to secondary server it will fail and have to do a manual failover, since there is no straight forward process to select the primary server during the octopus deploy, we created a powershell script to output the primary server, next we used Octopus output variables to capture the primary server and use it in other steps, however Octopus doesnt allow us to use the output variable as a hostname to other steps(usually hostnames are configured through target role/worker pool), we are currently using Octopus 2019.4.5, please advice if there is a workaround or the newer versions have solution for this issue.
Thanks for getting in touch! Great question, and while you’re correct that it’s not possible to bind the target role to a variable, I can think of a couple options that might help achieve what you’re after. I’d be interested to hear if either of these help in your specific scenario.
Deploy a Release step: if you specify a subset of machines when creating the deployment of the “parent” project, that specified subset will be passed to the “child” project and run on the same targets.
Octo CLI deploy-release command: using the
--specificMachines=VALUEargument you can pass in the single machine as evaluated via the previously set output variable.
Let me know what you think!
Thanks for providing a solution, however we fixed our issue with a different approach. We required the output variable to be consumed in a SQL step instead of a Release step. We were glad that we could get this done without manual intervention, Here are the steps which worked for us:
- Check Primary server with PS script and use output variable to get the primary server.
- Next, to consume the output variable, we broke down the deploy steps into two, as we have two target roles, and used the run condition to verify if primary server matches the output variable, run the step.
So the script executes only when there is match on primary server and skips rest of the steps with other target roles. The deploy will then proceed with other steps configured in the deployment.
Hi Sai M,
Anytime, and great to hear you have a good solution! I appreciate the update, and if you have any questions or concerns in the future, please don’t hesitate to reach out.