Many teams are attracted to uDeploy by its notion of deploying full applications – multiple tiers, services, and components go out together. But what do you do when there is a partial failure? Most groups send alerts and let the team respond to issues on a case by case basis.
Others aggressively want to maintain their Snapshot. If one piece fails to deploy correctly, they roll everything else back. Exactly how to do that might not be obvious. Here’s the trick. Have each component deploy be set to launch rollback processes for the whole stack. Something like this:
When adding the rollback steps, choose the “Replace with last desired” option for the rollback type. This will look up the previous deployment and move to that version as appropriate for full and incremental deployments. In the image above, if the failure was in the DB deploy, the App and DB would be rolled back and the Web would be left alone as it wasn’t modified by the deployment.
If you have parallelism in the rollback or deploy process, ensuring that a rollback of a component isn’t initiated while its deployment is still going can be another gotcha. To manage that, have the first activity of both deployment and rollback component processes aquire a lock named for the component and resource. That will serialize requests to modify the component on a given target. The lock could be named something like: ${p:component.name}-${p:resour
Try these atomic commits out and let us know how it works.