Add a Production Deployment

So far the component has one deployment. The point of the base/deployment structure is that adding another one is cheap. In this step you'll bring up a second cluster and stamp out a production deployment of CubbyChat onto it.

Bring up a second cluster

cub cluster up --name prod

Same as before: a local kind cluster with Argo CD, registered in ConfigHub as the target prod/target.

Create the prod deployment

cub variant create prod cubbychat/base \
    --target prod/target \
    --namespace cubbychat

This clones the base into cubbychat/prod: the whole configuration copied and linked upstream, targeted at the prod cluster, namespace placeholder filled. Just as with dev, because the target is a cub cluster, ConfigHub also creates the Argo CD Application that lets the prod cluster pick up the deployment.

Confirm nothing is left undecided. get-placeholders lists every remaining placeholder in the variant; with the namespace filled in, it lists none:

cub function get --variant cubbychat/prod get-placeholders --show output

Release it

cub release publish cubbychat/prod

As before you can check live status with:

cub release list --variant cubbychat/prod

CubbyChat is now running in two clusters.

Step back and look

You now have the shape that ConfigHub is built around — one component, three variants:

cub component tree cubbychat

cubbychat
└── base
    ├── dev     → dev/target
    └── prod    → prod/target

Without a component name, cub component tree draws every component you have. The web UI shows the same tree, with per-deployment badges for pending upgrades and unreleased changes:

cub component open cubbychat

Summary

A second deployment is one cub variant create away, and it is as complete and as live as the first.
Every deployment is a sibling under the same base, which is what makes the next step possible.