Release Management

Release management coordinates the packaging, testing, and controlled introduction of changes into production environments. A release groups one or more approved changes into a single deployable unit that moves through environments as a coherent package, enabling coordinated testing and controlled cutover. This task covers the complete lifecycle from release planning through handoff to deployment, excluding the deployment execution itself.

Prerequisites

Before initiating a release, confirm the following conditions exist:

You have release manager authority for the target service or application, documented in the service catalogue or RACI matrix. This authority grants permission to schedule releases, coordinate resources, and approve promotion between environments.

All changes included in the release have completed the change management process with documented approval. Retrieve change reference numbers and verify approval status in the change management system before proceeding.

Environment access credentials are available for each stage in the promotion path. Verify you can authenticate to development, test, staging, and production environments, or have confirmed handoff arrangements with teams who control those environments.

The release policy document is accessible and you have confirmed the release type (major, minor, patch, emergency) and associated requirements. Different release types carry different testing thresholds and approval gates.

Testing resources are scheduled or on standby. Confirm availability of test environments, test data, testing personnel, and any automated test infrastructure required for the release scope.

A release calendar or scheduling system is available to check for conflicts with other releases, maintenance windows, or organisational events that would affect timing.

Release lifecycle

A release progresses through defined stages from initial planning to production deployment. Each stage has entry criteria that must be satisfied before proceeding and exit criteria that confirm readiness for the next stage.

+--------------------------------------------------------------------+
|                        RELEASE LIFECYCLE                           |
+--------------------------------------------------------------------+
|                                                                    |
|  +----------+    +----------+    +----------+    +----------+      |
|  |          |    |          |    |          |    |          |      |
|  |  PLAN    +--->+  BUILD   +--->+  TEST    +--->+  STAGE   +---+  |
|  |          |    |          |    |          |    |          |   |  |
|  +----------+    +----------+    +----------+    +----------+   |  |
|       |              |               |               |          |  |
|       v              v               v               v          |  |
|   Scope and      Assemble        Execute         Acceptance     |  |
|   schedule       package         test plan       verification   |  |
|                                                                 |  |
|  +--------------------------------------------------------------+  |
|  |                                                                 |
|  |  +----------+    +----------+                                   |
|  +->+          |    |          |                                   |
|     |  DEPLOY  +--->+ CLOSE    |                                   |
|     |          |    |          |                                   |
|     +----------+    +----------+                                   |
|          |               |                                         |
|          v               v                                         |
|      Handoff to      Document                                      |
|      deployment      and review                                    |
|                                                                    |
+--------------------------------------------------------------------+

Figure 1: Release lifecycle stages with primary activities

The planning stage establishes release scope by identifying which approved changes to include, determining the release type, and scheduling the release window. Planning outputs include the release definition document and preliminary schedule.

The build stage assembles the release package, which contains all components, configurations, scripts, and documentation required to deploy the release. Build outputs include the deployable package and build verification results.

The test stage executes the test plan against the release package in test environments. Testing validates that changes function correctly individually and in combination, and that the release does not introduce regressions. Test outputs include test results and defect reports.

The staging stage deploys the release package to a production-equivalent environment for final acceptance testing. Staging validates deployment procedures and confirms readiness for production. Staging outputs include acceptance sign-off and deployment runbook verification.

The deploy stage hands off the validated release package to the deployment function for production deployment. The release manager coordinates timing and communications but does not execute deployment procedures directly.

The close stage documents the release outcome, updates configuration records, and captures lessons learned. Close outputs feed into the post-implementation review process.

Procedure

Plan the release

1. Identify approved changes for inclusion by querying the change management system for changes targeting the planned release date. For each candidate change, verify:

   • Change status shows “Approved” or equivalent
   • Change has not been included in a previous release
   • Change target date aligns with release schedule
   • Change owner confirms readiness

   Record change references in the release definition document. A typical release includes 3 to 15 changes; releases with more than 20 changes warrant splitting into multiple releases to reduce risk and simplify troubleshooting.

2. Classify the release type based on scope and risk. Release types determine testing requirements and approval thresholds:

   Release type	Scope	Testing requirement	Approval level
   Major	New functionality, architectural changes	Full regression, performance, security	Service owner + CAB
   Minor	Enhancements, non-critical fixes	Targeted regression, functional	Service owner
   Patch	Critical fixes, security updates	Smoke test, targeted functional	Release manager
   Emergency	Production incidents, security vulnerabilities	Minimum viable verification	Emergency CAB

3. Define the release schedule by selecting a deployment window that satisfies constraints. Production deployments for non-emergency releases occur during defined maintenance windows, which for most organisations fall on weekday evenings or weekends when user activity is lowest.

   Calculate the release timeline working backward from the target deployment date:

   Example: Target deployment Saturday 15 March 20:00

   Staging acceptance:    Thursday 13 March (2 days before)
   Test completion:       Tuesday 11 March (4 days before)
   Build completion:      Friday 7 March (8 days before)
   Planning completion:   Wednesday 5 March (10 days before)

For major releases, extend these intervals by 50% to allow for additional testing cycles.

4. Check the release calendar for conflicts. Query scheduled releases, infrastructure maintenance, organisational events, and staff availability for the planned window. Conflicts requiring schedule adjustment include:

   • Another release targeting the same service or dependent services
   • Infrastructure maintenance affecting target environments
   • Major organisational events increasing user dependency on affected systems
   • Key personnel unavailability during deployment or immediate post-deployment period

5. Create the release definition document containing:

   • Release identifier (format: REL-YYYY-MM-XXX, e.g., REL-2024-03-015)
   • Release type and classification rationale
   • Included changes with reference numbers
   • Target deployment date and window
   • Environment promotion schedule
   • Resource requirements (personnel, environments, tools)
   • Risk assessment summary
   • Rollback constraints and time limits

   Obtain service owner approval on the release definition before proceeding to build.

Build the release package

1. Assemble release components from source control and artefact repositories. A release package contains all elements required for deployment without dependency on external systems during the deployment window.

   +-------------------------------------------------------------------+
   |                    RELEASE PACKAGE STRUCTURE                      |
   +-------------------------------------------------------------------+
   |                                                                   |
   |  +------------------------+    +------------------------+         |
   |  |   APPLICATION CODE     |    |   CONFIGURATION        |         |
   |  |                        |    |                        |         |
   |  | - Compiled binaries    |    | - Environment configs  |         |
   |  | - Container images     |    | - Feature flags        |         |
   |  | - Database scripts     |    | - Connection strings   |         |
   |  | - Static assets        |    | - Service endpoints    |         |
   |  +------------------------+    +------------------------+         |
   |                                                                   |
   |  +------------------------+    +------------------------+         |
   |  |   DEPLOYMENT ASSETS    |    |   DOCUMENTATION        |         |
   |  |                        |    |                        |         |
   |  | - Deployment scripts   |    | - Release notes        |         |
   |  | - Rollback scripts     |    | - Deployment runbook   |         |
   |  | - Verification tests   |    | - Known issues         |         |
   |  | - Health checks        |    | - User communications  |         |
   |  +------------------------+    +------------------------+         |
   |                                                                   |
   +-------------------------------------------------------------------+

Figure 2: Release package composition showing four component categories

2. Version the release package using semantic versioning for application releases. The version number encodes release significance:

   • Major version (X.0.0): Breaking changes, new major functionality
   • Minor version (0.X.0): New features, non-breaking enhancements
   • Patch version (0.0.X): Bug fixes, security patches

   For infrastructure releases where semantic versioning does not apply, use date-based versioning (YYYY.MM.DD) or sequential numbering tied to the release identifier.

3. Generate release notes documenting changes included in the release. Release notes serve technical teams during deployment and end users after deployment. Structure release notes with:

   Release: APPLICATION-NAME v2.4.0
   Date: 2024-03-15
   Type: Minor

   Changes included:
   - CHG-2024-0892: Updated reporting module with export functionality
   - CHG-2024-0901: Fixed calculation error in budget summaries
   - CHG-2024-0915: Added multi-language support for notifications

   Known issues:
   - Export to PDF fails for reports exceeding 500 pages (workaround: export in batches)

   Dependencies:
   - Requires database schema v2.4 (included in package)
   - Compatible with API gateway v3.1 or later

   Rollback:
   - Rollback window: 4 hours post-deployment
   - Rollback procedure: See deployment runbook section 7

4. Execute build verification tests to confirm the package assembles correctly and core functionality operates. Build verification differs from full testing by focusing on package integrity rather than functional completeness. Verification confirms:

   • All declared components are present in the package
   • Binaries execute without missing dependencies
   • Configuration files parse without syntax errors
   • Database scripts apply to a clean schema
   • Container images start and respond to health checks

5. Store the release package in the designated artefact repository with appropriate access controls. Tag the package with the release identifier and version. Retain build logs and verification results with the package for traceability.

Test the release

1. Deploy the release package to the test environment. Test environments replicate production configuration but contain synthetic or anonymised data. Confirm the test environment baseline matches documented configuration before deployment.

2. Execute the test plan systematically. Test coverage scales with release type:

   Test category	Patch	Minor	Major
   Smoke tests	Required	Required	Required
   Functional tests (changed areas)	Required	Required	Required
   Functional tests (unchanged areas)	Sample	Required	Required
   Regression tests	Critical paths	Full suite	Full suite
   Integration tests	Affected interfaces	All interfaces	All interfaces
   Performance tests	Not required	Baseline comparison	Full load test
   Security tests	Vulnerability scan	Vulnerability scan	Penetration test

   Document test execution with timestamps, test case identifiers, and pass/fail status.

3. Record defects discovered during testing with severity classification:

   • Critical: Prevents core functionality; blocks release
   • High: Significantly impairs functionality; requires fix before release
   • Medium: Degrades user experience; fix desirable but not blocking
   • Low: Minor issues; acceptable for release with documented known issue

   Critical and high defects trigger a fix cycle: the change is corrected, a new build created, and testing restarted from build verification. Track defect fix iterations to monitor release stability.

4. Complete test stage when all test cases execute with acceptable results. Acceptable results means no critical or high defects open, and medium/low defects documented as known issues with workarounds where applicable. Generate the test summary report containing:

   • Test execution statistics (total, passed, failed, blocked)
   • Defect summary by severity
   • Open known issues with risk assessment
   • Test coverage confirmation
   • Recommendation to proceed or halt

Stage for acceptance

1. Deploy the release package to the staging environment. The staging environment replicates production infrastructure, configuration, and network topology to validate deployment procedures and final acceptance testing.

   +-------------------------------------------------------------------+
   |                  ENVIRONMENT PROMOTION PATH                       |
   +-------------------------------------------------------------------+
   |                                                                   |
   |  +--------+      +--------+      +---------+      +------------+  |
   |  |        |      |        |      |         |      |            |  |
   |  |  DEV   +----->+  TEST  +----->+ STAGING +----->+ PRODUCTION |  |
   |  |        |      |        |      |         |      |            |  |
   |  +--------+      +--------+      +---------+      +------------+  |
   |                                                                   |
   |  Developer       QA team         Service          Operations      |
   |  builds          validates       owner            deploys         |
   |                                  accepts                          |
   |                                                                   |
   |  Synthetic       Synthetic       Production-      Production      |
   |  data            data            like data        data            |
   |                                                                   |
   |  Isolated        Shared test     Production       Production      |
   |  network         network         network copy     network         |
   |                                                                   |
   +-------------------------------------------------------------------+

Figure 3: Environment promotion path showing data and network characteristics

2. Execute the deployment runbook exactly as written. Staging deployment validates runbook accuracy before production. Record any deviations, corrections, or clarifications needed. Update the runbook immediately when discrepancies are found.

3. Conduct user acceptance testing with representatives from the service consumer community. Acceptance testing confirms the release meets business requirements and operates correctly from a user perspective. Provide acceptance testers with:

   • Test scenarios covering changed functionality
   • Access to staging environment with appropriate credentials
   • Mechanism to report issues (form, email, shared document)
   • Deadline for acceptance testing completion

4. Obtain formal acceptance sign-off from the service owner. Sign-off confirms:

   • Acceptance testing completed satisfactorily
   • Known issues are acceptable for production deployment
   • Deployment timing remains appropriate
   • Rollback criteria and procedures are understood and agreed

   Record sign-off in the release record with timestamp and approver identity. Release cannot proceed to deployment without documented sign-off.

Schedule and communicate

1. Reserve the deployment window in the release calendar. Confirm the window with:

   • Infrastructure team (environment availability)
   • Operations team (deployment execution resources)
   • Support team (post-deployment coverage)
   • Communications team (user notification distribution)

2. Send deployment notification to affected stakeholders. Notification timing depends on release impact:

   Impact level	Advance notice	Notification audience
   High (service outage)	5 business days	All users, leadership, partners
   Medium (degraded service)	3 business days	Affected users, support team
   Low (transparent to users)	1 business day	Technical teams only

   Notification content includes: deployment date and time, expected duration, affected services, user actions required (if any), and contact information for questions.

3. Conduct the release readiness review 24 hours before scheduled deployment. Review confirms:

   • Release package verified and accessible
   • Deployment runbook current and validated
   • Rollback procedures documented and tested
   • On-call personnel identified and available
   • Monitoring dashboards configured for release validation
   • Communication templates prepared for success and failure scenarios

4. Confirm go/no-go decision with service owner on deployment day. Final confirmation accounts for any late-emerging issues, resource availability changes, or business circumstances that would affect deployment timing.

Hand off to deployment

1. Transfer the release package to the deployment team with accompanying documentation:

   • Release definition document
   • Deployment runbook with validated steps
   • Rollback procedures and decision criteria
   • Test results and acceptance sign-off
   • Known issues list
   • Contact information for release manager and technical leads

2. Brief the deployment team on release-specific considerations including:

   • Sequence dependencies between components
   • Configuration changes requiring coordination
   • Verification checkpoints and expected results
   • Rollback trigger conditions and time limits
   • Escalation path for deployment issues

3. Remain available during the deployment window to answer questions, make decisions on issues encountered, and authorise rollback if required. The release manager does not execute deployment steps but retains authority over release decisions during deployment.

4. Receive deployment completion confirmation from the deployment team. Confirmation includes:

   • Deployment status (successful, partial, rolled back)
   • Verification results
   • Issues encountered and resolutions
   • Actual deployment duration
   • Any post-deployment actions required

Close the release

1. Update configuration records to reflect the deployed release. Configuration items affected by the release require version updates, relationship changes, or attribute modifications in the configuration management database.

2. Notify stakeholders of deployment completion. Success notification confirms deployment completed, services are operational, and users can resume normal activity. Include contact information for reporting any issues.

3. Archive release documentation in the designated repository. Retain:

   • Release definition document
   • Release notes
   • Test results and defect reports
   • Acceptance sign-off
   • Deployment logs
   • Post-deployment verification results

   Retention period aligns with organisational records retention policy, with minimum 12 months for audit and troubleshooting purposes.

4. Create or update the post-implementation review request. Major releases require formal PIR within 5 business days of deployment. Minor and patch releases aggregate into periodic PIR sessions covering multiple releases.

5. Close the release record with final status and metrics:

   • Planned vs actual deployment date
   • Planned vs actual deployment duration
   • Defects discovered post-deployment
   • Rollback occurrence (yes/no)
   • Stakeholder satisfaction (if measured)

Release calendar management

The release calendar coordinates scheduling across services and teams to prevent conflicts and ensure resource availability.

+--------------------------------------------------------------------+
|                    RELEASE CALENDAR STRUCTURE                      |
+--------------------------------------------------------------------+
|                                                                    |
|  Week of 11 March 2024                                             |
|  +-------+-------+-------+-------+-------+-------+-------+         |
|  | Mon   | Tue   | Wed   | Thu   | Fri   | Sat   | Sun   |         |
|  +-------+-------+-------+-------+-------+-------+-------+         |
|  |       |       |       |       |       |       |       |         |
|  |       |       |       |       |       | REL-  |       |         |
|  |       |       |       |       |       | 2024- |       |         |
|  |       |       |       |       |       | 03-   |       |         |
|  |       |       |       |       |       | 015   |       |         |
|  |       |       |       |       |       |       |       |         |
|  +-------+-------+-------+-------+-------+-------+-------+         |
|  | Maintenance windows: Sat 18:00-06:00, Sun 18:00-06:00 |         |
|  | Blackout periods: Month-end (28th-2nd), Year-end freeze         |
|  +-------------------------------------------------------+         |
|                                                                    |
|  Scheduled releases:                                               |
|  - REL-2024-03-015: Finance system v2.4.0 (Sat 20:00)              |
|  - REL-2024-03-016: HR portal patch (Sun 19:00)                    |
|                                                                    |
|  Blocked windows:                                                  |
|  - Infrastructure maintenance: None this week                      |
|  - Organisational events: Board meeting Thu (no deploy Thu-Fri)    |
|                                                                    |
+--------------------------------------------------------------------+

Figure 4: Release calendar showing maintenance windows and scheduled releases

Maintenance windows define when production deployments are permitted. Standard maintenance windows occur during periods of lowest user activity. For organisations operating globally, maintenance windows account for time zone distribution of users. A single weekly maintenance window serves most organisations; high-change environments may require multiple windows.

Blackout periods prohibit non-emergency releases during high-risk business periods. Month-end blackouts protect financial close processes. Year-end freezes (from mid-December through early January) prevent changes during holiday periods when support capacity is reduced.

Release conflicts occur when multiple releases target overlapping infrastructure, shared dependencies, or limited deployment resources. Conflict resolution follows priority rules: emergency releases take precedence over scheduled releases; higher-impact releases take precedence over lower-impact releases; earlier-scheduled releases take precedence over later requests.

Verification

Confirm successful release management by validating these outcomes:

The release record contains complete documentation: release definition, included changes, test results, acceptance sign-off, and closure status. Query the release management system for the release identifier and verify all mandatory fields are populated.

Configuration records reflect the deployed release. Query the CMDB for affected configuration items and confirm version attributes match release contents. For application releases, verify the deployed version matches the release package version.

Stakeholder notifications were distributed. Check the communication system or distribution records to confirm notifications reached intended recipients at appropriate times.

Post-implementation review is scheduled or completed. Query the PIR tracker to confirm the release appears in the review schedule or has a completed review record.

Release metrics are captured for trend analysis:

Release: REL-2024-03-015
Metrics:
  Planned deployment date: 2024-03-15 20:00
  Actual deployment date:  2024-03-15 20:00
  Planned duration:        2 hours
  Actual duration:         2 hours 15 minutes
  Changes included:        7
  Defects in test:         3 (0 critical, 1 high, 2 medium)
  Defects post-deploy:     0
  Rollback:                No
  On-time delivery:        Yes

Troubleshooting

See also

• Change Management
• Deployment Practices
• Rollback Procedures
• Post-Implementation Review
• CI/CD Practices
• Testing Strategy
• Configuration Management