Skip to main content

Deployment Pipeline

A DeploymentPipeline declares the promotion paths between Environments — which stage a release can advance to from which. It is an organization's delivery process expressed as data: declarative, reviewable, and the same for every team that binds to it. A Project references one pipeline, so a team inherits exactly the stages and paths you authored.

KindDeploymentPipeline (short: deppipe)
API groupopenchoreo.dev/v1alpha1
ScopeNamespaced
AudiencePlatform engineer
WiresEnvironments into promotion paths
Bound byProject (spec.deploymentPipelineRef)

Key spec fields​

FieldDescription
spec.promotionPaths[]The list of source-to-target rules
spec.promotionPaths[].sourceEnvironmentRef.nameThe environment a release promotes from
spec.promotionPaths[].targetEnvironmentRefs[].nameThe environments it may promote to (a list — a source can fan out)

A release deployed to the first environment can only be promoted to a target the pipeline allows. There is no "deploy straight to production" path unless you wrote one — the pipeline is itself a guardrail.

Create in the portal​

  1. Open Create… → Platform Resources → Deployment Pipeline.
  2. Name it (e.g. default) and wire the promotion paths between the Environments you defined (e.g. development → staging → production).
  3. Click Create. Bind a Project to it so its components inherit the path.

Prefer YAML/GitOps? See the Example below, or Environments and pipelines.

Example​

A linear development → staging → production pipeline:

apiVersion: openchoreo.dev/v1alpha1
kind: DeploymentPipeline
metadata:
  name: default
  namespace: fedshi
spec:
  promotionPaths:
    - sourceEnvironmentRef:
        name: development
      targetEnvironmentRefs:
        - name: staging
    - sourceEnvironmentRef:
        name: staging
      targetEnvironmentRefs:
        - name: production

Because targetEnvironmentRefs is a list, a single source can fan out to parallel branches (e.g. qa and preproduction) that later converge on production.

See also​