Release Versus Deployment

Release and deployment are different events. Deployment moves components into an environment, while release makes a service or feature available for use, and the two moments do not have to happen at the same time.

• Define release and deployment states. Treat them as distinct states with clear owners, a shared view of what good looks like and agreed review points.
• Control activation separately where useful. In the article's example, a feature is deployed behind a control, validated in production and released to customers only after support readiness is confirmed. Failing to plan activation and rollback is a named pitfall, as is hiding dormant features.
• Communicate availability precisely. Announcing availability at the moment of technical deployment is a common mistake; consumers should be told when a feature is actually released and usable.
• Measure both technical and consumer readiness. Useful measures are deployment success, release adoption and the time between deployment and availability. Use deployment success as the starting signal, but compare it with release adoption before deciding whether the change worked, and read the measures as a set so a strong headline does not hide problems with quality, risk or consumer effort. Review results with delivery teams and affected consumers.