// Deployment

One deployment process for every environment.

A project's deployment process is an ordered list of steps. Each step uses a built-in template, your own template or a script, and is scoped to the environments and targets it runs on. Releases freeze the process, so Staging and Production run the same steps.

How a deployment runs

Your CI server builds and tests the artifact. When you deploy a release, Jaws Deploy resolves the variables for the target environment and runs the steps from top to bottom.

Each step runs on the machines and cloud targets that match its scope, in parallel or one machine at a time. If a step fails, the deployment stops, unless that step is set to continue on error. A step can also run always, only when every previous step succeeded, or only when a variable check passes.

Kinds of steps

Built-in templates Deploy package, Deploy IIS website, Install Windows service, Azure Web App, Azure script and Azure Key Vault steps cover the common work.

Scripts Run PowerShell 7, Windows PowerShell 5.1 or Python 3, with the step's scoped variables available.

Your own step templates Turn a script that several projects use into a template with input fields, and maintain it in one place.

Script modules Share PowerShell functions across steps and projects without adding a step to the process.

A script step

Scoped variables are available through $Jaws.Parameters. Everything the script writes goes to the live deployment log.

$conn = $Jaws.Parameters["ConnectionString"].Value

Write-Host "Running database migrations"
dotnet ef database update --connection $conn
if ($LASTEXITCODE -ne 0) {
    throw "Migration failed with exit code $LASTEXITCODE"
}

Scoping steps

Each step can be limited to certain environments, and to machines or cloud targets with certain tags. One process then serves every environment. A migration step tagged db runs only on database servers, and a cache warm-up step runs only in Production. Variables are scoped the same way, so the steps stay the same and only the values change.

Step order

The order of steps decides what state your system is in when a deployment fails halfway. Run database migrations before the package that needs them, and put health checks and smoke tests after the service restarts. Review a change to step order as carefully as a change to a deployment script.

Changes are versioned with releases

Editing the process changes the project, not existing releases. Each release keeps the steps it was created with, so redeploying an older release runs the process as it was then. Create a new release to pick up your changes. See releases and promotions.