A step is the unit of work in a deployment process. A step has a type (what kind of action), a configuration (the inputs to that action), and a scope (which environments and which targets it applies to).
Step types
Most deployment processes use a mix of built-in step types and custom script steps.
Common step types
Step scope
Each step has a scope - which environments it runs in, and which targets (or target tags) it targets. The same deployment process can have a step that runs everywhere, a step that only runs on role:db targets, and a step that only runs in Production. The platform resolves the scope at deployment time.
Parallelism and target fan-out
When a step targets multiple machines, the platform runs the work on all of them in parallel and waits for the slowest to finish before moving to the next step. That's the unit of synchronisation - a step gate. If you need stricter ordering across targets (e.g. canary one machine first), split the step into two with different target scopes.
Failure behaviour
A failing script does not fail its step. A non-zero exit code, or a terminating PowerShell error, is reported back by the agent as an error recorded against the step - the step itself is still reported as completed, and the deployment status is unaffected. What moves is the error count.
The error action of the step decides how the failure is counted. Stop logs it as an error, so it counts. Continue logs it as a warning, so it does not. Neither value ends the deployment.
Subsequent steps still run. Only the execute condition of a step can hold it back, and the one that reacts to earlier failures is All previous steps succeeded - it skips the step when the steps before it recorded any errors. A step held back this way is recorded as skipped, not failed.
A step is reported as failed only when the platform could not run it: the agent could not be reached, a package or script module could not be delivered to it, or the step timed out. That is what turns the deployment itself to Failed, along with a cancellation or a run that outlives its maximum duration.
So to judge whether a deployment did what you wanted, check three things: the status is Completed, the error count is zero, and the log shows the step reaching the targets you expected. A step whose filters match no targets is recorded as finished and adds no errors, so a deployment can complete cleanly having done nothing.
Re-deploying is a fresh run of the same release rather than a resume - there is no restart from the failed step. Steps that have already done their work can be left out of the new run.