Release Engineering
Deployment is not release. Versioning, promotion, release manifests, change management and the audit trail that lets you answer "what changed" during an incident.
Deployment means code reaches an environment. Release means functionality becomes available to users. Conflating them makes both riskier than either needs to be.
The practice of keeping software in a state where any commit on the main line could be released — whether or not you choose to release it.
Every change that passes verification reaches production automatically, with no human release step — which is a different and stronger claim than continuous delivery.
The path from commit to production as a designed system: ordered stages, each with an input, a verdict, evidence, and a defined behaviour on failure.
Someone has to own how software becomes a release: versioning, what a release contains, how it is assembled, who decides, and what record it leaves.
One record naming the version, commit, artifact digest, config version, migration version and flag state — so "what is production right now" is a lookup rather than an investigation.
Deciding which changes need what scrutiny, so that ordinary changes stay cheap and genuinely risky ones get attention — without a process people route around.
Who changed what, when, why — and what the previous state was. The last field is the one that turns a log into something you can act on.