Hi @nagaharshithm,
Thank you for the update. I have taken a look at some possible ideas for you which may be of some interest or things you may want to consider:
Idea 1: Using Variables for Run Conditions.
Setting each step with the variable run condition:
#{unless Octopus.Deployment.Error}true#{/unless}
This will have the effect of:
If a step fails, guided failure intervenes.
- If you choose FAIL on the step, all subsequent steps don’t run
- If you choose RETRY on the step, a retry will occur, and any further failure will be handled by guided-failure.
- If you choose IGNORE on the step, a failure (as far as the variable
Octopus.Deployment.Error will not have occurred, as you’ve chosen to ignore it), and therefore the next set of steps will continue to run.
My deployment task looks like this when I go through using guided failure:
If you wanted more control e.g. you didn’t want step 3 to run if step 2 failed, then you could update the last steps (prior to the manual intervention) to a run condition like so:
#{unless Octopus.Deployment.Error}#{if Octopus.Action[Step Name].Output.Octopus.Action.Script.ExitCode =="0"}true#{/if}#{/unless}
You wound need to replace Step Name here with the step name of the first step after each manual intervention step
This would skip the step if the previous one failed. The other steps e.g step 3 could just keep the condition like #{unless Octopus.Deployment.Error} .
Idea 2: Separating modules into individual projects and using the “Deploy A Release Step”
I also wanted to float the idea about potentially splitting out your deployment process and coordinating this using a project to deploy your modules independently (while keeping the order).
From the image below I have 4 projects, 3 are the individual modules and a project to Orchestrate these “Module Orchestration Project”.
Within my orchestration project I am using the “Deploy A Release Step” within my process to deploy these (with guided failure enabled):
From my testing, when I set the step to fail it will only fail the module that is not deploying correctly and will move onto the next deployment.
Doing it this way as they projects have been separated out they are actually independent of one another and will act as 3 separate deployments within Octopus itself.
As you can see from my deployment task log, module 2 failed but I could still successfully deploy module 1 and 3:
Idea 3: Using Child steps
Another idea I tried was to use child steps within my deployment process (with guided failure enabled). This was to try and keep this all within the same project and process:
In my test, I configured both module 1 and 2 to fail here. If I abort the Manual intervention step, guided failure will trigger and I can then also fail the step(s), but my deployment process will continue through the steps (ignoring the child steps from the failed step).
From my deployment log here I have a failed deployment for steps 1 and 2 but can see that Octopus still continues to deploy step 3 here:
Just as a heads up, when you are modifying your deployment process please ensure you are doing this in a controlled way. So you could either consider using our Configuration as Code feature to branch of changes to your deployment process.
An important note her is that once you make a project version controlled you can no longer switch this back as it is a one way option, so please make sure you understand this before making these decisions.
Or another option is to Clone your project and test against this in a safe way before modifying your main deployment process.
I hope this has helped to give you some ideas or things to try here. Personally I feel the best approach would be looking at using variables within the run condition to help build out your logic for your deployment process.
I appreciate there is quite a bit of information here, so, If you have any follow up questions for some of the ideas, please feel free to reach back out to us. If not, then good luck.
All the best,
Doug
