Make a Change

CubbyChat is live. Now let's change it — the right way: make the change on the base, flow it to the deployment, and release it. This loop — change → promote → release — is the daily rhythm of working with ConfigHub.

Change the base

Configuration in ConfigHub is data, not text, so you change it with functions that operate on specific fields rather than by editing YAML by hand. The verb says what kind of function you are running: cub function set for one that changes data, cub function get for one that reads it, cub function vet for one that validates. Two flags say where it runs: --variant names the variant, and --resource names the resource the way kubectl does, as kind and name. Preview the change first:

cub function set --variant cubbychat/base --resource Deployment/backend \
    --dry-run -o mutations set-replicas 2

--dry-run computes the result without writing it, and -o mutations shows it field by field: the backend Deployment's spec.replicas, 1 → 2. Nothing else. Now make it:

cub function set --variant cubbychat/base --resource Deployment/backend set-replicas 2

The base has a new revision. The dev deployment is unchanged — and ConfigHub knows it's behind.

Promote to dev

Preview what would flow down, then promote:

cub variant promote cubbychat/dev --dry-run -o mutations
cub variant promote cubbychat/dev

The preview shows the same change, now arriving in dev. Promotion merges the base's changes into the deployment. It is a merge, not an overwrite: only the paths the base actually changed are written, so the deployment's own customizations — the namespace it filled in, for one — are left as they are. A downstream value that the base does change is overwritten unless it has been protected, which you'll do on a later page.

Release it

The deployment's configuration has changed, but the cluster is still running the previous release. Publish a new one:

cub release publish cubbychat/dev

You can check progress with:

cub release list --variant cubbychat/dev

The list has a "LIVE" column which receives the latest live status from argobot.

Why three steps?

With one deployment this may feel like ceremony — why not just edit and be done? The payoff comes from what each boundary gives you:

Base vs. deployment: one place to make a change that many deployments will receive.
Promote: each deployment picks up the change on its own schedule, with a preview, without losing its local differences.
Release: what's running only changes when you say so, and each release is a precise, immutable record of what went out.

The next step makes the payoff concrete by adding a second deployment.

Summary

Change config with functions: cub function set --variant <component>/<variant> --resource <kind>/<name> <function> <args>. Preview with --dry-run -o mutations.
cub variant promote merges upstream changes into a deployment, preserving its customizations.
cub release publish makes the change live.