This structured release management process allows phased deployment (rollout), testing, and rollback in case of problems.
Deployment architectures vary significantly, but, broadly, the tiers are bookended by starting at development (DEV) and ending at production (PROD).
The last step, deploying to production ("pushing to prod") is the most sensitive, as any problems result in immediate user impact.
For this is often handled differently, at least being monitored more carefully, and in some cases having phased rollout or only requiring flipping a switch, allowing rapid rollback.
Sometimes deployment is done outside of this regular process, primarily to provide urgent or relatively minor changes, without requiring a full release.
The purpose of the test environment is to allow human testers to exercise new and changed code via either automated checks or non-automated techniques.
[6] Highly automated and parallelized test environments are important contributors to rapid software development.
This ensures all major and minor upgrades to a production environment are completed reliably, without errors, and in a minimum of time.
Staging is also used by some organizations to preview new features to select customers or to validate integrations with live versions of external dependencies.
This is similar to staging, except actually done in production, and is referred to as a canary release, by analogy with coal mining.
This adds complexity due to multiple releases being run simultaneously, and is thus usually over quickly, to avoid compatibility problems.