SDLC · Stage 05 of 07
Release and deploy
No cluster holds another cluster's credentials. The only thing that crosses a boundary is a reviewed, merged commit.
Principles: Every change is a reviewed commit, Event-driven by default
Shipping should feel calm. Getting a change in front of customers ought to be a reviewed, reversible step you can explain to anyone, not a moment everyone holds their breath.
Deploy and release answer different questions, so they get different rigor. Deploy is the fast inner loop to a lower environment: did my change work at all? Release is governed promotion: the release stage never touches a cluster. It opens a pull request against the app's GitOps repo, carrying the exact image digest that already passed test and deploy (never rebuilt). Governance gates report as required checks, a human reviews, and ArgoCD's own sync is the only thing that ever changes the target cluster.
Every upper cluster runs its own ArgoCD watching the same GitOps repo, instead of one ArgoCD holding credentials for them all, because a remote-cluster credential is just the dev-to-prod blast radius moved somewhere else. Outcomes come back to dev as events. The first version used ArgoCD Notifications; live testing showed it fired on any sync, including drift correction with no release involved, so it was replaced with sync hooks that fire only when a release really converges.
Workloads roll out as Argo Rollouts with analysis templates from a curated library, and the lower/upper environment split is enforced by a separate AppProject, not just by folder names.
Where Hangar does this
And for AI agents
Durable changes are commits. Ephemeral runs are claims.
An agent's durable write is a git write, and it goes through the same release path as everyone else's. Only its run, which is short-lived, stateless and rebuildable from git, is created directly, as a narrowly scoped claim to Crossplane on dev clusters. Upper clusters get neither.