Strategies

A strategy is how a release replaces what is running. Set it per deployment (--strategy, or with.strategy on slipway/deploy@v1), or as the environment’s default.

From a pipeline, every strategy_config key below goes on the deploy step as strategy.<key>, nested YAML included:

- uses: slipway/deploy@v1
  with:
    strategy: canary
    strategy.steps: [{ weight: 5, pause: 5m }, { weight: 25 }]
    strategy.verify:
      provider: prometheus
      metrics:
        - { name: error-rate, kind: absolute, query: 'rate(http_errors{track="{track}"}[1m])', max: 0.05 }

Strategy	Mechanism	Downtime	Rollback	Plan
recreate	Stop old, start new	Yes	Redeploy previous	Free
rolling	Replace instances in batches	No	Redeploy previous	Free
bluegreen	Stand up the new version alongside, switch traffic	No	Switch back	Team
canary	Shift a percentage of traffic in steps, verify at each	No	Automatic on failed verification	Team
progressive	Canary region by region	No	Per-region	Business

How each is realised depends on the infrastructure kind. Kubernetes uses Deployment rollouts, Service selectors or a service mesh / ingress for traffic splits; ECS uses its deployment controller; Cloud Run and Container Apps use revision traffic weights; App Service uses slots; VM fleets use runner agents.

Recreate

All old instances stop, then new ones start. Use it for singletons and stateful workloads that cannot run two versions at once, such as a migration that is not backward compatible.

Rolling

strategy: rolling
strategy_config:
  max_surge: 25%          # "25%" or "1"
  max_unavailable: "0"
  batch_size: 2           # for batched targets such as vm_pool (or batch_percent)
  batch_pause: 30s
  ready_timeout: 10m

Instances are replaced a batch at a time. The deployment waits for each batch to report healthy (using the service health check) before continuing. If a batch fails, the deployment fails and, because auto_rollback defaults to true, rolls back.

Blue/green

strategy: bluegreen
strategy_config:
  manual_switch: true       # wait for an approval before the traffic switch
  verify_preview: true      # run verification against the green stack before switching
  bake: 10m                 # observe after the switch before cleaning up
  scale_down_delay: 30m     # keep the old (blue) stack this long for instant rollback
  verify: { ... }           # see Canary verification

The new (green) version is staged beside the live (blue) one and receives no user traffic. It can be verified, then traffic switches. With manual_switch the deployment pauses for a human, which is a natural place for an approval. If anything fails after the switch, traffic goes back to blue, which is why blue is kept for scale_down_delay.

Canary

strategy: canary
strategy_config:
  steps:
    - weight: 5             # percent of traffic on the new version, 1..100
      pause: 5m             # soak before the next step
    - weight: 25
      pause: 10m
    - weight: 50
      manual: true          # wait for a human to continue
    - weight: 100
  verify:                   # default verification, see Canary verification
    provider: prometheus
    metrics: [...]
  auto_rollback: true       # default

Traffic shifts to the new version in steps (for example 5%, 25%, 100%). After each step the deployment soaks, runs verification against your metrics and either advances or rolls back. A step can override the default with verify: false to skip verification. A canary needs a way to split traffic: a service mesh, an ingress controller that supports weights, a cloud load balancer, or a revision-weighted platform like Cloud Run.

Progressive multi-region

Business and above. A progressive rollout is a list of waves. Each wave targets one or more infrastructures (regions or rings), runs its own strategy (default rolling), soaks, and is verified before the next wave starts. Release trains group several services’ releases so they roll out together.

strategy: progressive
strategy_config:
  waves:
    - name: canary-region
      infrastructure_ids: [infra_eu_west_canary]
      strategy: canary
      bake: 30m
    - name: eu
      infrastructure_ids: [infra_eu_west, infra_eu_central]
      manual_approval: true
    - name: us
      infrastructure_ids: [infra_us_east, infra_us_west]
      skip_verification: false

Common options

Key	Meaning
verify	Default verification config for the strategy
ready_timeout	How long to wait for a workload to report healthy (default 10m)
retries	Extra attempts for deploy and stage steps
auto_rollback	Roll back on failure (default true)
notes	Free text recorded on the deployment

Internally each strategy compiles to an ordered plan of persisted steps (plan, deploy, stage, set_traffic, wait_ready, verify, wait, approval, promote, cleanup, rollback). The plan is data, so a deployment survives a restart and every step is observable in the UI.

Preview before you run

DeployService.PreviewDeployment (and Preview in the UI) shows the steps a deployment will take, the resolved variables, the approvals required and the gates that apply, without changing anything.

Failure and rollback behaviour

Event	Result
Health check fails during rolling	Deployment failed; rolled back when auto_rollback is on (the default)
Verification verdict is fail	Deployment rolled_back automatically
Runner lost mid-deployment	Lease expires; the deployment resumes or fails according to the step’s retry policy
You press Pause	Status paused at the next step boundary; Resume continues
You press Cancel	Deployment cancelled; environment may be in a mixed state. Run a rollback