Project Steps Explained

Steps are not arbitrary scripts. They are typed actions with target scoping, retry, and structured outputs.

Search guides... Ctrl K

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

Deploy a package Extract a package onto a target, apply config transforms, run pre/post hooks.
Run a script Inline PowerShell or Bash with access to scoped variables and script modules.
Manage a Windows service Install, restart, stop, or reconfigure a Windows service.
Configure IIS Create or update an IIS site, app pool, or binding.
Deploy to Azure Web App Push a package to an Azure App Service through the management API.
Custom step template A reusable step type defined at the workspace level with structured inputs.

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 step that fails on any target fails the deployment. Subsequent steps don't run. The deployment is recorded as failed, with the failing step and target visible in the log. Re-running the deployment from the failed step is supported - useful when the failure was transient.