Creating Releases

A release is an immutable snapshot of packages, variables, and deployment process for a specific version.

A release is the unit of promotion in Jaws Deploy. It carries three frozen pieces under a single version number: the packages, the variable definitions, and the deployment process. Once created, none of these change.

What a release captures

Packages Exact package versions at release time - zip, tar, NuGet, whatever the steps consume.
Variable schema Variable definitions at release time. Values still resolve per environment - the set is what's frozen.
Deployment process The ordered steps the project had when the release was created.

When to create one

The usual moment is after a successful CI build. CI calls the Jaws Deploy API or SDK and passes: the project, the version, and any package mappings. The platform snapshots the rest from the project's current state.

// PowerShell SDK

How CI typically creates a release

Same shape works for TeamCity, GitHub Actions, GitLab, Jenkins, and Azure Pipelines.

Connect-JawsDeploy `
    -Url    "https://app.jawsdeploy.net" `
    -ApiKey $env:JAWS_API_KEY

New-JawsDeployRelease `
    -Workspace "default" `
    -Project   "checkout-service" `
    -Version   "2026.5.17.${env:BUILD_NUMBER}" `
    -Packages  @{ "Checkout.Web" = "2026.5.17" } `
    -ReleaseNotes (Get-Content .\CHANGELOG.md -Raw)

What you don't snapshot

A release does not capture environment state, target state, or live external systems. Those drift independently of releases. If the database schema in Staging is different from Production, re-deploying the same release to both will hit different state - that's a Staging/Prod parity problem, not a release problem.