# Executing Deployments

Source: https://www.jawsdeploy.net/guides/executing-deployments

Deployment is the act of running a release against an environment. Same release, different scope.

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.

> **// Outcome - A finished deployment is not the same as a successful one.**
> 
> Status answers one question: did the engine complete the run? A failing script does not fail its step and does not fail the deployment - the failure is recorded as an error and the run carries on. Failed and Cancelled are reserved for the engine itself being unable to finish. Judge a deployment on three things together: status Completed, an error count of zero, and a log showing it reached the targets you expected.

## Reading the outcome

Two things describe a finished deployment, and they answer different questions.

- **Status** - did the engine complete the run? `Completed` means it reached the end of the step list. `Failed` and `Cancelled` mean 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 fails is recorded as an error against its step: a PowerShell command that throws, or a PowerShell 5.1 or Python script that exits with a non-zero code. PowerShell 7 does not fail on exit codes - a script that ends with a non-zero `exit` only logs a warning. 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.