Failure to recover from unsuccessful release


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.

  1. 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.

  2. 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?

Hi Vagif,

Thanks for sharing your experiences. As luck would have it, version ( includes a small change to our IIS deployments, to reorder configuration so that the path is changed before other settings are applied.

The full IIS configuration support in 2.0 is actually a completely new component for us, so we’re still keeping an eye out for ways to fine tune it like this.


Thanks Nicholas, we will check it out.