A release makes a defined set of software changes available for deployment or use. Treat it as an operational responsibility: success depends not only on code, but also on planning, communication, practice, and recovery options. Modern teams may release several times a day, while larger or riskier changes still require carefully managed downtime. section 9.7
Build a release approach around the system, business tolerance, and available resources:
- Prefer small, frequent releases when the architecture and organization can support them. section 9.7
- For outage releases, identify affected components, estimate shutdown through user reentry, assign each step and hand-off, and reserve contingency time. section 9.7.1
- Agree on release dates with the business, notify stakeholders, and communicate promptly when progress or timing changes. section 9.7.1
- Document preparation steps, success criteria, failure detection, cancellation points, and separate procedures for patches, hot fixes, and full releases. section 11.2.5
Planned outage release
A data migration requires taking an enterprise system offline. The team identifies the affected components, prepares a maintenance page, schedules the lowest-usage period, assigns owners to shutdown, update, restart, testing, and user reentry, and allows extra time for problems. During execution, it reports delays rather than going silent; afterward, it conducts a postmortem and improves the plan. section 9.7.1
A dependable release process should be repeatable, documented, and practiced where feasible. Automation can reduce effort, but documentation prevents releases from depending on one specialist. Virtualization, cloud infrastructure, and blue-green strategies can further reduce release risk. section 9.9 section 11.2.5
