Concepts

A space is the top-level boundary for organizing related pipelines and releases. It groups pipelines for a service, product, or team so operators can view and manage releases from one place.

Spaces also define the boundary for collaboration and access. Teams can organize related pipelines together while keeping unrelated services separate.

Use separate spaces when pipelines have different owners or access requirements.

A pipeline is the durable definition of a release process. It defines how releases execute and records the history of every release that moves through it.

Pipelines can model anything from a simple service deployment to a multi-stage product rollout. Topology defines the work to perform, while execution mode and scheduling rules determine how releases progress through the pipeline.

Every pipeline records the history and current state of its releases, providing context for how releases progress through the pipeline over time.

Topology makes execution flow explicit. Targets and groups form a graph, and dependencies describe which work must finish before later work can begin. The topology determines when work becomes eligible to execute, allowing both sequential and parallel work to be modeled within the same pipeline.

Changes to groups, targets, and dependencies immediately affect how future work is scheduled. Scheduling is always based on the current topology together with the state already recorded for each release.

A group organizes related targets or nested groups and applies scheduling policy to them as a unit. Groups commonly represent recognizable rollout boundaries such as integration, staging, or production.

Selection determines whether every release moves through the group or newer releases can supersede older waiting ones. Concurrency limits how many releases may be active in the group, enabling patterns such as a validation lock.

A target defines a unit of executable work within a pipeline. Common examples include deploying infrastructure, publishing an application, running verification, or waiting through a bake period.

Dependencies determine when a target becomes eligible to execute within the topology. Each execution is recorded as a target run, including its timing and outcome.

A release is one version or change moving through a pipeline. It ties together the work performed by many targets so operators can understand the rollout as a single coordinated event.

A release advances as target runs complete and scheduling capacity becomes available. Its state reflects the combined progress of its target runs, providing a high-level view of whether the rollout is waiting, progressing, complete, or needs attention.

A release records the artifacts being deployed and may build on a previous release. Earlier releases can be reused, including for rollback scenarios.

A target run records what happened when a particular release reached a particular target. It carries the operational detail behind the broader release state, including when work was scheduled, started, and finished.

Failures and retries are recorded on the target run, preserving the history of each attempt. This makes it possible to diagnose individual steps without losing the context of the overall release.

A share provides a focused view of a pipeline without granting access to the surrounding workspace or operator controls. It is intended for people who need to follow progress, not change it.

Shares expire, limiting access to the period when visibility is needed. They are useful during launches, incident coordination, or other rollouts where a broader group needs live status.