I am testing the best strategy for organizing Web site deployment folders, and I thought the default strategy used by Octopus (publishing new releases in new folders named after release number) is an easy way to keep deployment history but also a way to switch back to the previous installation on failure. But I noticed a couple issues that I wish would work differently.
Upon a failed installation the agent doesn’t reconfigure IIS to use the previous release. So failed release basically leaves the site unavailable. I understand this should be up to the project maintainer how they would like to handle the failure, so that’s OK.
Failed installation leaves a machine in a critical state: attempt to deploy a next (good) release fails as long as IIS points to a folder containing failed release. This means we need to manually delete the Web site or point it to a working release.
Needless to say that this is not how we would like recover from failed releases. Shouldn’t Octopus be able to recover the site by applying “good” release avoiding manual intervention?