Pipeline Deployments, Rollouts, and Rollback
Expanso Cloud provides release controls for pipelines running across distributed nodes. Choose how quickly a new version reaches the fleet, monitor its progress, and use pause, resume, or rollback when a release needs attention.
Choose a rollout strategy
The Cloud console exposes two strategies:
| Strategy | Behavior | When to use it |
|---|---|---|
| Rolling | Deploy in waves, with health evaluation during the rollout. | Limit how much of the fleet receives a change at once. |
| Immediate | Deploy to all target nodes at once. | Apply a change broadly when a staged release is unnecessary. |
For Rolling deployments, Wave Size (%) sets the percentage used for parallel updates. The form also exposes Max Failed (%) and Auto-rollback on failure. Choose these settings to match the size of the fleet and the consequences of a failed update.
The current console does not offer a selectable canary strategy. A small, explicitly selected node group can still be useful for a test deployment, but that does not create an automatic traffic-splitting or canary-promotion workflow.
Configure a deployment
- Build and validate the pipeline configuration.
- Set its name, description, and labels.
- Review the node selector.
- Set runtime behavior, including restart policy, priority, and timeouts.
- Choose Rolling or Immediate and review the applicable failure controls.
- For Rolling, configure health evaluation and parallelism.
- Submit the deployment and open its progress view.
Runtime restart choices are on failure, always, or never. Execution, queue, and total timeouts let you bound different stages of a job's lifecycle; the form supports zero to mean no timeout. These are execution controls, not a guarantee that a restarted pipeline resumes from a particular source offset.
Configure rolling health checks
Rolling deployment settings include:
| Setting | What it controls |
|---|---|
| Deadline | Maximum wait for an execution to become healthy. |
| Interval | Duration of each health evaluation window. |
| Maximum error rate | Error-rate threshold used in health evaluation. |
| Success threshold | Consecutive healthy windows needed to establish health. |
| Failure threshold | Consecutive unhealthy windows needed to establish failure. |
Review these together with the rollout's failure budget and automatic-rollback setting. One transient error is not the same as a rollout meeting its configured failure condition. Custom health-check settings in the creation form apply to Rolling deployments; the form does not submit them for Immediate deployment.
Follow release progress
Open a pipeline's deployment history and select a version. The deployment detail shows updated, pending, and failed node counts, rollout percentage, current and total waves, strategy, trigger, and timestamps. Its execution list is filtered to that version, and its timeline shows deployment events.
Use these views to distinguish a pipeline that was accepted by Cloud from one that has reached its target nodes. If progress stalls, check node connectivity, selectors, execution status, and the configured health and failure settings.
Pause and resume
While a deployment is running, use Pause to stop further rollout progress. When the rollout is paused, use Resume to continue. Pausing a rollout is a release-control action; it is not a command to stop every pipeline execution.
Inspect the updated nodes and their telemetry before resuming a release that you paused for investigation.
Compare versions and roll back
Cloud retains pipeline versions and lets you inspect their specifications. The deployment detail's Diff view compares the selected version with its predecessor. This gives reviewers a concrete view of what changed.
When a valid rollback target is available, Rollback presents the target version for confirmation. A rollback creates a new deployment using the previous configuration. It does not erase deployment history or undo records already written to an external destination.
Automatic rollback is separately configurable during deployment. Its outcome depends on the rollout settings and an available rollback target; an initial deployment has no earlier configuration to restore.
Stop or reassess a pipeline
The pipeline list supports Stop and Start or Restart, including bulk operations such as Restart Pipelines. Start and Restart use the API's rerun operation. Stopping controls the job's lifecycle. Rerun asks the scheduler to reassess the job; it should not be treated as a promise to forcibly restart every healthy execution or replay a chosen historical range.
Understand the recovery boundary
Configuration rollback, runtime recovery, and data reconciliation solve different problems. Source offsets, checkpoints, durable buffers, and duplicate handling depend on the selected components and pipeline design. Consult the relevant component references and restart guidance before relying on a release workflow to preserve processing state.
For moving definitions between workspaces or planning a backfill, see CLI and delivery workflows.
