I’ve seen multiple posts about manual intervention and the Abort option not stopping the project. What exactly does choosing Abort actually do if it does not stop all remaining deployment steps from executing?
Your only two options are to Proceed or Abort, but depending on your Run Conditions, Abort actually allows the project to proceed a well?
Now we have more options as to how we can proceed, and these options seem to do exactly what they state they do, unlike Abort which is very misleading.
How are we supposed to have a multi-package deployment project with infrastructure orchestration if we cannot actually orchestrate?
(Scenario 1) Consider the situation where all steps are left as default.
Now we have one step fail and all remaining steps will be skipped including important infrastructure orchestration which leaves our deployment half-baked and potentially offline.
(Scenario 2) If we switch our steps to Always Run
Now we’ve lost all control over the actual approval process and cannot Abort a deployment short of hitting the Cancel button on the entire project.
Another thing to consider is what happens when the deployment steps are all Deploy a Release and you come across 1 child project that has to be canceled. That particular Deploy A Release step is now marked as failed which kicks off scenario 1 if you are using the default run condition settings. Ask me how I know this…
I’m trying to figure out how to deal with a potential failure during a massive train deployment without risking my entire stack going offline, while still allowing the change implementer the ability to call off a deployment if things don’t look ready. I’m not seeing much in the middle-ground here.