Skip to content

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. Bump the backend's replica count on the base:

cub function set --space cubbychat-base --unit backend set-replicas 2

The base has a new revision. The dev deployment is unchanged — and ConfigHub knows it's behind. List its units and note the upgrade column:

cub unit list --space cubbychat-dev

The backend unit shows that an upgrade is needed: its upstream has moved ahead of what was last merged.

Promote to dev

Preview what would change, then promote. -o mutations shows it field by field rather than as a count of units:

cub variant promote cubbychat-dev --dry-run -o mutations
cub variant promote cubbychat-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 (--protect, or cub unit set-protection).

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
kubectl get pods -n cubbychat

Two backend replicas. The full loop: change the base, promote to the deployment, release to the cluster.

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 on the base.
  • cub variant promote merges upstream changes into a deployment, preserving its customizations.
  • cub release publish makes the change live.

Next

Add a Production Deployment

Further reading