Deliver several repos as one chart

A Product with several repos, such as a web app and its API, can ship them together. With umbrella delivery, each deployment is one version of the Product's umbrella chart: every repo's newest build, or its previous image carried when it has no new build. Every environment then deploys that chart version. One version names everything that runs there, and a rollback puts back the previous version as a whole, so you never have to work out which combination of repos was last known good.

The default is isolated delivery: a deployment ships one commit of one repo and pins its image into each environment (Deliver a single app).

	Isolated (default)	Umbrella
A deployment ships	One commit of the delivery repo (spec.delivery.repo, else the first)	One version of the umbrella chart, with every repo's image
Its version	A tag vX.Y.Z on the delivery repo, with a release on the forge	A tag vX.Y.Z on every repo, with a release on each, and a tag <product>-X.Y.Z on the chart in the org's charts repo
An environment deploys	The generic chart in the gitops repo, with the deployment's image	The umbrella chart at its tag, with the environment's own values
A rollback puts back	The previous image	The previous chart version: every repo's previous image

Turn it on

On the Product's page, open Product settings, go to Delivery, and choose Umbrella. The panel lists what each deployment would pin: the delivery repo as the chart's own image, and each other repo as its own Kubernetes Deployment. Only org admins can change it. The change takes effect at the next deployment, and until then every environment keeps what it runs. Moving back to Isolated works the same way: the next deployment points each environment at the generic chart again.

Through the API, set spec.delivery.strategy to umbrella (or back to isolated) with replace-product.

What a deployment does

1. Resolves every repo. The delivery repo builds in the Product's kpack Image, and every other repo in its own, <product>-<repo>. Infrared adds those Images for a Product it scaffolded; for any other, create them with those names. A repo whose newest build differs from the chart's pin is changed; the others are carried. A deployment with nothing changed is refused.
2. Tags each changed build with the version, by digest, as an isolated deployment tags its one image.
3. Writes the chart charts/<product> in the org's charts repo, which Infrared creates. The chart is the generic web chart from the gitops repo (products/<product>/chart), copied at each deployment. The delivery repo runs from the chart itself, and every other repo from its own copy under charts/<repo>, with a Kubernetes Deployment and Service named <product>-<repo>. Infrared commits the version and the pins, and tags the commit <product>-<version>.
4. Tags every repo. Each repo, changed or carried, gets the chart's version as a git tag vX.Y.Z at the commit it ships, and a release on the forge. A repo that already has a tag of that name on another commit keeps it, and the Versions view says why that repo was not tagged.
5. Promotes it environment by environment, as isolated delivery does: a pull request to the gitops repo points the environment's Application at the chart's tag, Argo CD runs it, and the release guard checks it. An environment counts as running the new version only when every repo's image runs there.

A push to any of the Product's repos starts a deployment, as for isolated delivery (On a push), and pushes to several repos within two minutes ship as one. A repo that was pushed to ships its build of the pushed commit: the deployment waits for kpack to build it rather than taking the build before it.

Edit the templates in the gitops repo, not in the charts repo, since each deployment copies them again. Each environment keeps its own values file, products/<product>/zones/<zone>/values.yaml.

A check for another repo of the Product reaches it at http://<product>-<repo>.<zone>.svc/.

Rollback

When an environment fails its release guard and rolls back, Infrared opens and merges a pull request that points its Application back at the previous chart tag, waits for Argo CD to run every image of that version, and marks the environment Rolled back to that version. As with isolated delivery, data is never rolled back.

On the Deployments tab

The Versions view lists each deployment's chart version, linked to its tag, and its repos: the changed ones first with how many commits each gained, then the carried ones folded under carried. A repo whose build the deployment still waits for reads building. See Products.

On an umbrella Product's environment tile and page, the resource use, pods and logs are the delivery repo's. The other repos' Kubernetes Deployments run beside it in the same namespace.

The control plane as an environment

Infrared delivers itself the same way, in the platform org: an umbrella Product whose one environment has target: controlPlane. Each deployment copies the changed components' images to its release registry (releaseRegistry), commits their pins and the version to the umbrella chart, pushes the chart to an OCI registry (spec.delivery.charts), and after approval upgrades the control plane to it.

That environment's release guard is the upgrade guard: a Job running the operator that was there before, so a broken new operator can't stop it from rolling back. For two minutes it checks Argo CD, every Kubernetes Deployment of Infrared, the gitops repo and the environment's own checks. It reads the control plane's SLOs over that time with the same error budget check as any environment (its uptime, and the edge's errors and latency for Infrared's own address, which are recorded but never alert). If they don't pass within controlPlane.guardTimeout, it rolls the upgrade back. A connection the edge resets is tried again at once, so one reset doesn't restart the two minutes.

Starting a deployment and approving it take the Product's own roles, as for any environment. Only the platform org may hold such an environment. See the CRD reference.

Limits

• Argo CD must be able to read the org's charts repo. On an org whose gitops repo and Products share a forge, the org's repository credentials cover it. Infrared adds the charts repo to the products AppProject's sources when none matches it.
• Every repo builds with the Product's scaffold kind (static, node or go) and is served on port 8080 with the generic chart's defaults. Per-environment settings (replicas, resources, environment variables) apply to the delivery repo only.
• A repo can't be named after a key of the generic chart's values (image, replicas, port, env and the like).