Cowboy in the desert.

DeployFailed.ps1 support

Today's Octopus Deploy release includes support for a DeployFailed.ps1 script, a feature I mentioned in a recent blog post about how Octopus handles rollbacks.


During a deployment, Tentacle normally runs the following steps:

  1. Extracts the package from NuGet
  2. Runs PreDeploy.ps1
  3. Runs XML config transforms
  4. Replaces XML config appSettings and connectionStrings
  5. Runs Deploy.ps1
  6. Configures IIS websites
  7. Runs PostDeploy.ps1

(See our pages on XML configuration, PowerShell script support, and IIS websites for details on these steps)


If steps 2-7 fail, Tentacle will now look for a DeployFailed.ps1 script, and invoke that. It will have access to the same variables that the other PowerShell scripts get. This is a good place to put recovery actions.

Note that if step 1 fails, the DeployFailed.ps1 won't be called. There are a few reasons for this:

  1. DeployFailed.ps1 might not have been extracted anyway
  2. Files it depends on may not have been extracted
  3. Tentacle checks for free disk space prior to installing a package, so this should be pretty rare in the first place
  4. Extracting the package is an isolated task, so there's nothing to recover from in the first place

One feature that would be nice is to pass the path to the last installed package, which your recovery script could use when rolling back. Tentacle doesn't have enough information to do that yet, but it will when Auto-purge Tentacles is implemented, since both require keeping a list of previously installed applications.

Tagged with: RFC