Introduction
Understanding organizationsUnderstanding componentsManage organizationsManage componentsManage component Jira integrations
Set up your first organizationUnderstanding users and teamsUnderstanding role-based access controlManage usersManage teamsConfigure role-based access controlRBAC permissions reference
Understanding authentication in CloudBees UnifySet up multifactor authenticationConfigure SAML single sign-onConfigure OIDC authenticationConfigure network security policiesNetwork security reference
Understanding platform configurationUnderstanding environmentsManage properties and secretsManage environmentsTrack environment inventoryConfigure containersSet up preconfigured actionsConfigure notifications
Accessibility policy referenceShared responsibility model referenceSubscription and services agreementSupport policiesSupported browsers and external tools
Introduction
Understanding feature managementUnderstanding Configuration as CodeGet started with feature managementCreate and manage feature flagsConfigure feature flag targetingOrganize feature flagsImplement feature flag governanceConfiguration as Code reference
Understanding flag impressions and activity statusUnderstanding flag healthUnderstanding code referencesReview and clean up feature flagsSet up code references
Understanding Jira integration for feature flagsSet up the Jira integrationLink Jira tickets to feature flags
Understanding multiple SDK keysBuild your first mobile app with feature flagsBuild your first feature-flagged web applicationBuild your first feature-flagged backend serviceInstall client-side SDKsInstall server-side SDKsConfigure multiple SDK keysMobile SDK referenceWeb SDK referenceBackend SDK referenceClient SDK referenceFlag implementation reference
Introduction
Understanding CI workflowsCreate a build workflowCreate and manage workflowsCreate reusable workflowsTest and validate containers in workflowsCheck out source codeTrigger workflows remotelyWorkflow syntax referenceJobs syntax referenceSteps syntax referenceServices syntax reference
Monitor workflow runsView test results in runsView evidence in runsView deployments in runsManage workflow artifactsPublish test resultsPublish evidence itemsGenerate a software bill of materialsManage ServiceNow change requests
Configure workflow credentialsConfigure AWS credentialsConfigure container registry credentialsConfigure Git credentialsIntegrate external secret providers
Understanding GitHub Actions integrationSet up GitHub Actions integrationDisplay GitHub Actions workflows and runsRegister GHA build artifactsPublish GHA deployed artifactsPublish GHA test resultsPublish GHA evidence itemsTrigger CloudBees workflows from GitHub ActionsScan with GitHub Actions
Understanding CloudBees CI and Jenkins® integrationConnect CI and Jenkins controllersMonitor CI and Jenkins buildsRegister CI build artifactsRegister CI deployed artifactsPublish CI test resultsConfigure CI security scanningCI and Jenkins integration reference
Build and publish container imagesUnderstanding external CI/CD integrationsRun external CI/CD jobsExternal CI/CD action reference
Introduction
Understanding release orchestrationManage applicationsCreate deployer workflowsCreate staged workflowsCreate and manage releasesOrchestrate multi-workflow releasesRelease management reference
Understanding artifact managementRegister and track artifactsStore and retrieve artifactsPromote artifactsGenerate a software bill of materialsArtifact management reference
Deploy with HelmDeploy to KubernetesContainer deployment reference
Deploy to AWSAWS deployment reference
Deploy with enterprise platformsExecute remote deployment commandsEnterprise deployment reference
Verify deployments with New RelicDeployment verification reference

Understanding release orchestration

4 minute read

Release orchestration addresses the challenge of coordinating the delivery of multi-component software through multiple environments in a controlled, traceable, and repeatable way. This page explains the core concepts of the CloudBees Unify release model, how they relate to each other, and when orchestrated releases are the right approach.

The release model

CloudBees Unify organizes release activity around a hierarchy of connected concepts: components, applications, releases, and workflows. Each layer adds a different kind of structure to the delivery process.

A component is the foundational unit, representing a single deployable service or application module with its own source repository and workflows. Components are defined and managed in platform administration.

An application groups related components into a single software product. Applications own the release lifecycle: they hold the workflows that deploy components to environments, track which artifact versions are deployed where, and serve as the entry point for creating and managing releases. Where a component represents a single piece of software, an application represents the whole.

A release is a versioned, time-bounded collection of artifact versions that are deployed together through a defined workflow. Each release captures not just what ships (the artifact versions) but how it ships (the release workflow) and where it has been (the audit trail). Releases give teams a stable, reviewable unit of coordination across environments and time.

Staged workflows and deployer workflows define the mechanics of how a release moves through environments. A staged workflow organizes the release journey into ordered stages, each targeting a specific environment, such as staging, pre-production, and production. A deployer workflow is the reusable deployment logic that a staged workflow calls at each stage: it accepts a manifest of component artifact versions and an environment name, then orchestrates deployment of every component to that environment.

The relationship between these concepts is:

Component (source + artifact)
    ↓
Application (groups components)
    ↓
Release (versions + manifest)
    ↓
Staged workflow (environments + gates)
    ↓
Deployer workflow (per-environment deployment logic)

The release lifecycle

A release moves through a defined set of states from initial creation to completion.

Draft is the initial state when a release is created but not yet ready to run. Use this state to assemble the manifest, review artifact versions, and prepare the release workflow before committing to execution.

Ready to run indicates the release has been finalized and is waiting to be triggered. The manifest is locked at this point.

Pending start is a transient state entered when execution is requested but has not yet begun, typically while the workflow scheduler allocates resources.

Started means the release workflow is actively executing. Stages complete in order; if a stage fails, the release pauses at that point.

Closed is the terminal state. A release moves to closed when it completes successfully or when a user closes it manually. Closed releases are preserved for audit purposes and cannot be restarted, though their audit reports remain accessible.

The manifest

The manifest is the contract at the heart of every release. It is a JSON structure that specifies exactly which artifact versions should be deployed for each component, along with optional flags that control conditional deployment logic.

A deployer workflow reads the manifest and iterates over each component entry, calling that component’s own deploy.yaml with the specified artifact version and target environment. This design means the deployer workflow itself does not need to be updated when artifact versions change: only the manifest changes with each release.

A component entry in the manifest can include a deploy flag, which allows conditional logic inside the deployer. When a component’s artifact has not changed since the last release, the flag can suppress redeployment of that component, making incremental releases efficient without requiring separate release definitions.

Why separate staged from deployer workflows

The separation of staged workflows from deployer workflows reflects two different scopes of responsibility.

A staged workflow answers the question: "What is the sequence of environments and gates for this release?" It defines the organizational structure of a delivery pipeline: how many stages there are, what each stage is called, what approvals or checks must pass before moving forward, and which deployer to invoke.

A deployer workflow answers the question: "How do I deploy all the components to a given environment?" It contains the actual deployment logic: which components to deploy, in what order, and with what configuration.

This separation means a single deployer workflow can be reused across multiple staged workflows and multiple releases. It also means the deployment logic can evolve independently of the release structure. Changing how components are deployed does not require modifying every staged workflow that uses the deployer.

When to use orchestrated releases

Orchestrated releases add coordination overhead. Not every deployment needs them.

Use orchestrated releases when:

  • Multiple components must be deployed together in a specific sequence or as a coordinated set.

  • You need versioned traceability of exactly what was deployed to each environment and when.

  • Your delivery process includes approval gates, sign-offs, or compliance checkpoints between environments.

  • You need to track release progress across a team and maintain an auditable delivery record.

A standard workflow is sufficient when:

  • You are deploying a single component without dependencies on other component versions.

  • The deployment is exploratory or ad-hoc and does not require coordination or traceability.

  • You are deploying to a non-production environment for testing without a formal release record.

How deployment actions fit in

The deployer workflow calls deployment actions to execute the actual work of pushing software to infrastructure. CloudBees Unify provides a catalog of deployment actions that cover cloud platforms (AWS, Lambda), container orchestration (Helm, Kubernetes), enterprise platforms (Ansible, Octopus, Spinnaker), and remote execution (SSH).

These actions are the building blocks inside deployer workflows, not the release model itself. Understanding the release model tells you how releases are structured and tracked; the deployment action documentation tells you how to configure each individual tool integration.

Refer to Understanding artifact management to understand how artifacts flow through the release model.

Related pages

Manage applications