opscode/chef — pull request #816 by danielsdeleo (2013-06-11 20:46:10+00:00)
Title: WIP - deploy resilience w/o auto-rollback

This would need some work before merging, putting this up here for discussion.

This is an approach to making the deploy resource redeploy after a failed deploy. It works by not storing a release in the release order cache until the very end of the deploy. When the user runs chef again, the deploy resource loads the release order cache, see that the current (botched) release is not first in the list, and will essentially do a force deploy on top of the last attempt.

### The Good:
- Failed deployments don't auto-rollback, so the primary behavior of a failed deploy doesn't change.
- Files on disk are left in the same state as when the failure occurred, so users can poke around for debugging purposes (auto-rollback deletes the botched deploy).
- Re-running Chef after fixing the root issue (e.g., bad callback code, transient github error) will get the deployment into the desired state.

### The Bad:
- If the user nukes the release order cache, we fallback to inspecting what's on disk. This will cause the deploy resource to behave as if the application is correctly deployed (or should be rolled-back-to).
- If the user never redeploys the same application version, the deploy resource will never delete the directory with the botched code.