We have a release deployed to production from about month ago. During the time of the release our DR environment was not added in the deployment process. The DR environment is in the same “Production” environment in the project life cycle. Is there any way for me to get this release number into the DR environment without having to create a new release and running the code through all of the deployment steps? This code is fully tested and has already gone through the steps, I just need to get it into DR.
Thanks for getting in touch! When you say your DR environment is the same as production, is it in the same phase of your Lifecycle? You should be able to add that environment to that phase of the Lifecycle and run the deployment directly to your DR environment as Lifecycles can be updated and have old releases work as you would expect. If you find it is gating the deployment still, you can add that environment temporarily to your first phase and deploy then.
Ah Vanessa, thank you! That was the one piece I was missing, I never added the environment to the life cycle. So many areas of setup I missed this one. Thank you much, the environment is available for deployment by this release.
Actually I was wrong, it will not deploy to this environment as the environment was not on the process step when the release was created. Even though the environment shows to deploy too, there are no steps that will run when deploying to that environment. So is there anyway around this or do I have to create a new release and run it through all of the environments?
Ahh, unfortunately you are correct. My solution did not take into account step scoping. Generally it is best never to scope steps to environments for cases like this unless it is something that is only ever run in one environment.
The Lifecycle change would only have worked for any steps scoped to all environments.
I would suggest my workaround of temporarily adding it to the first phase of your pipeline, create a release, deploy it, then change the Lifecycle to be more correct of the environment in the final phase. That way you won’t have to go through the entire list.
You can even give the release itself a name like 1.2.3-drdeploy to make it clear its purpose and version.
Okay, I’ll move the environment to the first life cycle step. It is an automated step, so probably best to disable that while doing this as well.
Looking through our process steps most of them now deploy to all environments, so based on this headache I have gone through and removed the specific environments, or set not an environment if there was only one not allowed.
Thank you for your assistance, it has been quite helpful.
Sounds like a good plan and the best way to keep your process maintenance down. We always suggest the use of variables and their scope to make your steps work on any environment is the best practice.