Two environments, side by side
What differs between staging and production, told two ways — what was declared, and what is actually running — plus why a two-sided diff is useless here.
Production is supposed to lag. That is what a promotion pipeline is. So the useful question is never "are they the same" but "what differs, and was that deliberate".
Staging beside production, field by field.
Compare two environments →
Two bases, and they answer different questions
What the platform decided each environment should be: the release, the component type, the traits, the environment configs, resolved.
This is the one to read when you are asking "did my promotion carry what I thought it carried".
What is actually in the cluster, read from the data plane.
This is the one to read when the rendering looks right and the behaviour does not — the gap between them is drift, and it is a different fault entirely.
A two-sided diff of a rendering against a live object is unreadable, and this
is not a preference. Kubernetes defaults dozens of fields the rendering never
mentions, so a naive diff is a hundred rows of terminationMessagePath above
the one line that matters.
The drift check compares only the fields the desired object actually asserts. Everything the platform did not ask for is not a difference.
Three classes of difference, and only one is a problem
| what differs | verdict |
|---|---|
| the release, because production has not been promoted yet | the pipeline, working |
| a size class or a replica count, declared per environment | deliberate |
| a live field the rendering asserts and the cluster disagrees with | drift |
chess is the project to look at for the second: its production bindings
declare three deliberately different classes of knob, so the compare page has
something real to show rather than a wall of "identical".
Down to the objects
Every environment view goes all the way to the Kubernetes objects, because the rule is that you can always reach the real thing.
Environments in promotion order, each with its components and its resources.
One project, per environment →The actual Deployments, Services, Secrets and CRs, as one graph.
Every object in one cell →
A database that lives in staging is part of what staging is, so resources are
listed inside their environment rather than in a separate section at the bottom.
An environment occupied only by a resource — chat is exactly that, owning
Zulip and declaring no components — is still an environment with something in it.
Release history, per environment
A component's releases can be read two ways, and the second is the one people usually want.
- As built — every ComponentRelease in creation order, each diffed against the one before it.
- As an environment saw them — only the ones that actually ran there, in the order that environment saw them.
They differ whenever a promotion gate holds something back: in creation order you are diffing two releases that were never adjacent anywhere.
Add ?environment=production for the second reading.