Deployment is the verb form of release. The release is the fixed plan; deployment is one execution of that plan against a specific environment. The same release can be deployed many times - useful for re-runs, rollbacks via re-deploy of the previous release, or re-applying to a fresh target.
What happens when you click deploy
The platform runs through a fixed sequence:
What the platform does, in order
- Resolve targets - which targets in the environment match each step's scope?
- Resolve variables - pre-compute the values each step will see.
- Run each step in order - fanning out across matching targets, gating on the slowest.
- Stream logs - per step, per target, live to the UI.
- Record the outcome - the run status, the error and warning counts, and timing per step.
Reading the outcome
Two things describe a finished deployment, and they answer different questions.
- Status - did the engine complete the run?
Completedmeans it reached the end of the step list.FailedandCancelledmean it could not get there: an agent it could not reach, a package or script module it could not deliver, a step that timed out, a deployment that outlived its maximum duration, or a cancellation. - Error count - did the work report problems? A script that exits with a non-zero code, or a PowerShell command that throws, is recorded as an error against its step. The step is still reported as completed, and the deployment still runs to the end.
So Completed on its own is not success. A deployment did what you asked when its status is Completed, its error count is 0, and it reached the targets you expected.
Error action, and what it actually controls
Each step has an error action of Stop or Continue. It chooses the level a script failure is logged at, and nothing more.
- Stop logs the failure as an error, so it counts towards the deployment error count.
- Continue logs it as a warning, so it does not.
Neither setting ends the deployment. On a project that leans on Continue, an error count of zero stops being proof of a clean run, and the warnings need reading too.
Later steps still run
A step that recorded errors does not stand down the steps after it. Every remaining step is still offered, and only the execute condition of that step can hold it back.
- Always ignores what came before.
- All previous steps succeeded is the one condition that reacts to earlier failures. It skips the step when the steps before it recorded any errors between them - which is why only earlier steps set to Stop can trigger it.
- Variable check looks at a boolean variable instead.
A step held back this way is recorded as skipped, not failed, and adds nothing to the error count.
A step with no targets is not a failure
If the machine or tag filters of a step match no agent - or the only agents they match are disabled - the step has nothing to run on. That is not treated as an error. The step is recorded as finished, contributes no errors, and the deployment can reach Completed having done nothing at all.
The log is what tells the two cases apart: a step that ran shows one child node per target, and a step that matched nothing shows none. When a deployment has to prove it landed somewhere, check the targets in the log rather than the status alone.
Re-deploying
The same release can be deployed to the same environment more than once. Common reasons: the previous run failed and you've fixed the cause, you want to re-apply a configuration drift, or you're refreshing a freshly-rebuilt target. Each deployment gets its own record - history shows N runs, not one.