- Project A:
- has a process with some steps
- there exists a release 1.1.1
- Project B:
- has a process with a “Deploy a Release from Project A” step
- the step has Deployment Condition == IfNewer
- there exists a release 2.2.2 referencing Project A release 1.1.1
- Developer X deploys Project A release 1.1.1, but it fails and requires manual intervention (it is left as such for now for investigation).
- Developer Y deploys Project B release 2.2.2. It completes successfully (all steps are green), but it has the following message in the Deploy a Release step: “The project A will not be deployed because the requested release version (1.1.1) is not higher than the currently deployed or queued version (1.1.1).”. Developer doesn’t notice this, as he only inspects logs on failures.
- Developer X concludes the investigation and chooses Fail as a resolution.
Result: project A is not deployed, but looking at project B suggests that it was deployed. One has to dig into deployment logs to discover that.
It is crucial for a tool like Octopus Deploy to make it 100% clear what the deployment status is, and the scenario above is very misleading and easily leads to incomplete deployments.
Maybe in this scenario the Deploy a Release step should pause until the investigation is finished (so that it can correctly decide if there is still anything to deploy or not)? Or taking this even further, why are queued deployments considered at all at this stage? A queued deployment can be cancelled manually, can fail, can be failed during manual intervention… Shouldn’t Deploy a Release steps be always queued, leaving the decision related to the Deployment Condition to the very last moment, as it is the only time when it can be correctly resolved?