Deploy and Promote

DevsPortal separates what you deploy from where and how it runs. That separation is what gives you safe promotion — the exact release you tested in development is the one that reaches production — and reliable rollback.

note

DevsPortal is built on the Control Plane Operator engine. The occ CLI and openchoreo.dev/v1alpha1 resources below are unchanged engine internals.

Portal first, CLI second

The portal UI is the recommended path; the equivalent occ CLI commands follow for scripting.

The deployment chain

When you create or update a Component and its Workload, the platform builds a chain:

Component + Workload
  → ComponentRelease   (immutable snapshot — type, params, traits, workload, image)
  → ReleaseBinding     (binds a release to one environment, applies overrides)
  → Deployment + Service + HTTPRoute   (rendered onto a data plane)

• ComponentRelease — an immutable snapshot of everything about the component. A new one is created only when something actually changes. This is the unit you deploy and promote.
• ReleaseBinding — binds a release to a specific environment (development, staging, production) and is where per-environment overrides apply.
• The binding renders the final Kubernetes resources on the target data plane.

The key idea: the same ComponentRelease is bound to each environment. Promotion doesn't rebuild or re-snapshot — it points the next environment at the release you already verified.

The deployment pipeline

Every Project references a DeploymentPipeline that defines the promotion order. The default on Fedshi is:

development → staging → production

A new deployment lands in the first environment; you promote it forward from there. Pipelines can include parallel paths and gates — your platform engineers own that shape.

In the portal: the component's Deploy tab lays the pipeline out as a row of environment cards in promotion order, so you can see the stages at a glance.

Or with the occ CLI, inspect yours:

occ deploymentpipeline get default -n fedshi
occ environment list -n fedshi

Deploy to the first environment

autoDeploy

The simplest path: set autoDeploy: true on the Component. Then every time a new ComponentRelease is created (on creation, or whenever you change the Workload), the platform automatically binds it to the first environment. You still promote to later environments yourself.

Manual deploy

Without autoDeploy, or to deploy a specific release, deploy on demand.

In the portal: open the component's Deploy tab — it shows a card per environment with the current status. Click Deploy on the first environment's card to deploy the latest release there.

Or with the occ CLI:

# Deploy the latest release to the first environment
occ component deploy cart-api -n fedshi -p checkout

# Deploy a specific release
occ component deploy cart-api --release cart-api-5d7f658d9c

Promote to the next environment

Promotion advances the release to the next stage in the pipeline.

In the portal: on the Deploy tab, click Promote on the source environment's card (for example, on the development card to advance to staging). The identical release now runs in the target environment. Because it's the same snapshot, what you validated upstream is exactly what ships downstream.

Or with the occ CLI:

occ component deploy cart-api -n fedshi -p checkout --to staging
occ component deploy cart-api --to production

Check deployment status

In the portal: the Deploy tab shows per-environment status (Ready, NotReady, Failed), the last deploy time, the image and release name, and the endpoint URLs. Click View K8s Artifacts on a card to drill into the rendered Deployments, Pods, Services, and HTTPRoutes.

Or with the occ CLI:

occ component get cart-api -n fedshi
occ releasebinding list -n fedshi -p checkout --component cart-api

Environment overrides

The same release runs everywhere, but each environment can be configured differently — without forking the release. Three override types:

Override	Configures	Example
componentTypeEnvironmentConfigs	ComponentType parameters	replicas, resource limits, port
traitEnvironmentConfigs	Per-trait-instance parameters	alert thresholds
workloadOverrides	Workload-level settings	env vars, file mounts

Overrides in the portal

On the Deploy tab, click the gear icon on an environment card. The Overrides page has tabs for Workload (env vars, files, endpoints), Component (ComponentType parameters), and Traits (per-instance parameters). This is the recommended way to tune a single environment.

Overrides with the occ CLI

Apply overrides at deploy or promote time with --set and dot-notation paths:

# 1 replica in development
occ component deploy cart-api -n fedshi -p checkout \
  --set spec.componentTypeEnvironmentConfigs.replicas=1

# 3 replicas and tighter logging in production
occ component deploy cart-api --to production \
  --set spec.componentTypeEnvironmentConfigs.replicas=3 \
  --set spec.workloadOverrides.env.LOG_LEVEL=warn

Overrides in YAML

You can also edit the ReleaseBinding directly:

apiVersion: openchoreo.dev/v1alpha1
kind: ReleaseBinding
metadata:
  name: cart-api-production
  namespace: fedshi
spec:
  owner:
    projectName: checkout
    componentName: cart-api
  environment: production
  releaseName: cart-api-5d7f658d9c
  state: Active
  componentTypeEnvironmentConfigs:
    replicas: 3
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"

tip

Use overrides for anything that legitimately varies by stage — replica counts, resource limits, log levels, feature flags. Keep these out of the Workload's base spec so the release stays portable and promotion stays honest.

Undeploy, redeploy, and rollback

Undeploy removes the running workload from an environment but keeps the ReleaseBinding, so you can bring it back without reconfiguring. Redeploy reactivates it. Both are buttons on the environment card in the console.

Rollback is just deploying an older release. In the portal, pick an earlier release from the environment card's release history and deploy it; or with the occ CLI, deploy it by name:

occ componentrelease list -n fedshi -p checkout --component cart-api
occ component deploy cart-api --release cart-api-a1b2c3d4e5

This creates a new binding pointing at the older release — a clean, auditable rollback.

Troubleshooting deployments

Symptom	Likely cause	Check
Stuck in NotReady	Data-plane connectivity	Cluster agent pod logs on the data plane
Pods in CrashLoopBackOff	Application error	occ component logs, or the Logs tab
Image pull error	Wrong image or missing registry credentials	The image reference and registry access
No endpoint reachable	HTTPRoute missing or wrong visibility	Endpoint visibility; View K8s Artifacts
Deployment never appears	ReleaseBinding not created	occ releasebinding list; component conditions

For reading logs, metrics, and traces in depth, see Observability.

What's next

• Observability — watch and troubleshoot the running deployment.
• Workloads and endpoints — what's inside a release.
• Governance and guardrails — how pipelines and promotion gates are set up for your team.