What a Jaws Deploy pipeline actually is

A pipeline in Jaws Deploy is a project's deployment process: an ordered list of steps attached to environments and targets. It is not a YAML file in a repo, and it is not a free-form script. It is a structured deployment definition that the platform owns, versions through releases, and executes against the targets it knows about.

The shape matters. CI pipelines describe how to build. Jaws Deploy pipelines describe how to deploy a thing that is already built to a specific environment, with the right configuration, in the right order, with logs and history attached.

How a pipeline executes

Every step has a place in the order, a target scope, and either a built-in template or a custom script. When you deploy a release, Jaws Deploy walks the steps top-to-bottom and runs each one against the targets that match its scope.

If a step targets multiple machines, Jaws Deploy runs the work on each of them in parallel, then waits for the slowest one before moving on. That gives you a predictable per-environment shape: fan out across a tier, gate on the slowest target, continue.

The four kinds of steps you actually write

Package deployments Extract a package onto a target, run pre/post hooks, apply config transforms, and clean up old versions.
PowerShell scripts Run inline or modular PowerShell against targets with full access to scoped variables and script modules.
Windows service & IIS Install, restart, or reconfigure Windows services and IIS sites without writing the plumbing every time.
Custom step templates Encapsulate a pattern once - input fields, defaults, validation - and reuse it across projects and teams.

Built-in templates vs. your own steps

Most teams start by chaining built-in step templates: deploy a package, run a script, swap an IIS binding. That covers the boring 80%. The interesting 20% - your domain-specific deployment dance - usually lives in either a custom step template (so it gets a UI form) or a script module (so it gets shared as a function library).

The rule of thumb evaluators tend to land on:

// When to reach for which

Templates, scripts, modules - pick the right tool

  • Use a built-in template when the platform already knows the shape (package, service, IIS, etc.).
  • Promote repeated PowerShell into a custom step template the moment two projects need the same form.
  • Use a script module for pure functions that several scripts call - it stays out of the deployment-step UI.
  • Drop down to inline PowerShell only for one-off, project-specific glue. If it survives a sprint, refactor it.
// PowerShell step example

A step is just a function with structured inputs

Steps receive scoped variables as parameters and write to the live deployment log. No special framework, no DSL.

param(
    [string]$ConnectionString,   # resolved from Variables for this env+target
    [string]$ReleaseVersion      # provided by Jaws Deploy
)

Write-Host "Migrating database to $ReleaseVersion ..."
& "$PSScriptRoot\tools\migrate.exe" `
    --connection $ConnectionString `
    --target-version $ReleaseVersion

if ($LASTEXITCODE -ne 0) {
    throw "Migration failed with exit code $LASTEXITCODE"
}

Scoping a step to targets and environments

Steps are not just "run this everywhere." Each step has a scope: which environments it applies to, which target roles, which tags. That is how a single pipeline serves multiple environments without forking.

A realistic project might have one pipeline where the migration step is scoped to a role:db tag, the package deploy step is scoped to role:app, and the cache-warmup step only runs in Production. Same pipeline. Different work in different places.

// CI's job

Build and test the artifact

Compile, unit-test, package. CI is good at this. Keep it there. Stop teaching Jenkins how to ssh into production.

// Jaws Deploy's job

Run the deployment plan

Take the artifact, resolve variables, walk steps in order, fan out across targets, and stream logs back. That is the platform's whole job.

Why this shape beats hand-rolled scripts

A pile of CI scripts can deploy a release. We have all written one. The cost is not the first deployment - it is the tenth environment, the third client, the rollback at 2am when someone needs to know which release went to which environment and what exactly it did.

A Jaws Deploy pipeline is structured enough that the platform can answer those questions for you. Every step is a known unit. Every run is a known release. Every change to the deployment process is a change to the project, not a silent edit in a YAML file nobody reviewed.