Skip to content

Flow a Change

With two deployments downstream of one base, a change now has a path to travel: base → dev → prod. In this final step you'll flow a change through the whole graph, verifying it in dev before it reaches production — and see that a deployment's own local edits survive the merge.

A local tweak in dev

Real deployments accumulate local differences. Suppose someone on the dev team renamed the chat title in dev while testing. Make that edit directly on the dev deployment:

cub function do --space cubbychat-dev --unit backend set-env-var backend CHAT_TITLE "Cubby Chat (dev)"

When you change a unit in a deployment directly, ConfigHub records that the deployment now owns that field. Remember this — it matters in a moment.

Change the base

Now the team ships two changes to the base: a company-wide rebrand of the chat title, and a scale-up of the backend.

cub function do --space cubbychat-base --unit backend set-env-var backend CHAT_TITLE "Cubby Chat 2.0"
cub function do --space cubbychat-base --unit backend set-replicas 3

Both deployments are now behind the base. Neither has changed yet — promotion is per-deployment and deliberate.

Promote and verify in dev

Preview which units would flow down, then promote:

cub variant promote cubbychat-dev --dry-run
cub variant promote cubbychat-dev

Look at what happened to the backend unit in dev:

cub unit data --space cubbychat-dev backend | grep -E "replicas:|CHAT_TITLE" -A1

The replica count picked up the base's change — it flowed to 3. But CHAT_TITLE is still Cubby Chat (dev), not the base's Cubby Chat 2.0. Dev owns that field, so the promote preserved dev's value while merging in everything dev hadn't touched. This is the heart of the model: one change on the base reaches every deployment, without stepping on the local differences each deployment has earned.

Release it and check dev is healthy before letting anything near prod:

cub release publish cubbychat-dev
source ~/.confighub/clusters/dev.env
kubectl get pods -n cubbychat

Promote to prod

Preview first — production deserves a look before you promote:

cub variant promote cubbychat-prod --dry-run

Prod never overrode the chat title, so it has no local claim on that field — it takes both changes: CHAT_TITLE becomes Cubby Chat 2.0 and the backend scales to 3. Then:

cub variant promote cubbychat-prod
cub release publish cubbychat-prod

The rebrand is live in prod and in dev — but dev still shows its own title. Same base change, two outcomes, each correct for where it landed.

The rhythm

That's the whole workflow, and it's the same whether you have two deployments or two hundred:

  1. Change the base once, with functions.
  2. Promote each deployment when it's ready, previewing the merge — local edits are preserved.
  3. Release each deployment to its target when you're ready for it to be live.

Each step is inspectable and each deployment moves at its own pace — a canary region first, the rest after; dev continuously, prod on approval.

Where to go next

  • Scale it up. The value of this model compounds with fleet size. The Components view example walks a six-app, seven-target promotion setup.

Cleanup

cub cluster down tears down a cluster's live kind cluster; with --delete-config it also deletes the cluster's ConfigHub spaces — the <name> and <name>-argo-apps spaces and every deployment bound to the cluster's target.

Dev has no delete gates, so it comes down in one command:

cub cluster down --name dev --delete-config

Prod is different: you gated cubbychat-prod's units with --unit-delete-gate critical, so the recursive delete refuses to remove them. That's the gate doing its job. Force past it deliberately, then tear the cluster down:

cub space delete cubbychat-prod --recursive-force
cub cluster down --name prod --delete-config

Finally, remove the shared base, which isn't tied to any cluster:

cub space delete cubbychat-base --recursive