Hi
We have a client with an Octopus project for producing the typical Dev->test->production deployment packages.
There is a new requirement is also produce a stand-by production environment in case the primary environment fails catastrophically. Let’s call it DisasterRecovery.
What is the most conventional way to produce the deployment packages for this secondary environment? There are many different settings between Production and DisasterRecovery, so dedicated transform files sound logical (i.e. web.Production.config and web.DisasterRecovery.config)
Should we use
a. Another “environment” in the lifecycle i.e. Dev -> Test -> Production -> DisasterRecovery
b. Should we add another ‘role’ for the DisasterRecovery machines (and somehow target this role with the “additional transforms” section)
We are currently on Octopus 3.11.15
Thanks
Andrew
Hi Andrew,
Thanks for getting in touch! Treating your DisasterRecovery environment as a normal environment sounds like a good option based on what you’ve described. You can perform your transforms in that environment as you would any other environment, and deploy your project to it whenever needed. There are a couple of options to configure this environment into your project.
In your existing lifecycle, you could create this environment after your Production environment, as you’ve suggested. You can add it as an optional phase in your existing lifecycle. Refer to my screenshot showing how you can make a phase optional.
Additionally, you could create it as its own separate lifecycle, and configure a new channel to use this lifecycle, and create new releases in this channel. Check out our channels documentation for more info.
Let me know what you think of these options, and if you have any other questions at all!
Best regards,
Kenny
hi Kenny
thanks for confirming my thinking. We went with the extra environment.
regards
Andrew
Hi Andrew,
That’s no problem at all, and that sounds good! Let us know if there’s anything else we can help with going forward.
Kind regards,
Kenny
