Release and deployment are not the same job

Release and deployment get used as if they were one word. They are related, and they are not the same job. When we blur them, readiness questions get skipped and pipeline success gets mistaken for go-live confidence.

Why it matters

A clean deployment can still be a bad release. The build may land perfectly while training is missing, support notes are stale, or a dependent service is not ready. Conversely, a well-planned release can fail because the deployment path was unclear or rollback was never rehearsed.

Release management answers whether we should go, with what, and with whom standing by. Deployment executes the technical path into the target environment.

How I separate the work

For a release, I care about scope, schedule, stakeholders, entry and exit criteria, early life support, and the decision to proceed or stop.

For deployment, I care about the method, sequence, environments, automated checks, access, and the mechanics of rollback or remediation.

Both need owners. Sometimes one person wears both hats in a small team. The roles still need distinct checklists so nothing is assumed.

What good looks like

The release plan names what is in and out of scope, who authorises go-live, and what “done” means after deployment.

The deployment runbook is specific enough that a peer can execute it. Timings, order of components, and verification steps are written down.

Pipeline green is an input, not the release decision. Business and support readiness still get a voice.

After go-live, early life support watches the service with agreed signals, not only “no ticket yet.”

Common mistakes

Treating the merge to production as the release plan.

Declaring success when the job finishes in the tool, before users and monitoring confirm behaviour.

Leaving rollback as “redeploy the previous version” with no owner, no data considerations, and no time limit for the decision.

Planning the release calendar around wishful dates instead of readiness.

Takeaway

Deploy what you planned to release, and only release when deployment and the organisation are both ready. Keep the jobs distinct so neither one is skipped.