Redeploy when the version changes
A redeployment publishes an updated version of the existing project. Use it after source changes or after changing environment variables. Confirm the intended source revision and keep the project identity stable so its address and history remain useful.
When the build fails, inspect the build log before trying again. If the old deployment is still serving, distinguish that live state from the failed attempt so the team knows what visitors are actually seeing.
Restart when the current app needs restarting
A restart runs the current app again. It is not a substitute for publishing changed source or correcting configuration. Tell the agent whether you intend to restart the current release, deploy a new version, or restore an earlier one.
After a restart, verify the live address and the workflow that prompted the operation. A process that has started is not automatically proof that the application’s dependencies are available.
Recover the app and then correct the source
Rollback can restore an available earlier deployment when a release regresses. Check what will be restored and whether the app depends on external changes made since that version. Database changes and external state need their own recovery plan.
After recovery, fix the issue in the canonical source repository or local project. Keeping only the live deployment repaired leaves the next release at risk of reintroducing the same problem.