Release and Deployment Management

What a release is

A release is a version of a service or of other configuration items, or a collection of them, that is made available for use. Kestrel Energy's portal version 4.2 is a release; so is "Portal 4.2 plus the new billing interface plus the updated mobile app", shipped together because they only work together. A release can contain software, configuration, documentation, training for the service desk and updated knowledge articles — everything users and support need for the new functionality to work.

Two practices deal with releases, and they answer different questions:

• Release management is the practice of making new and changed services and features available for use: deciding what goes into a release, when users get it, and making sure they and the support teams are ready.
• Deployment management is the practice of moving new or changed hardware, software, documentation or other components into live or other environments, such as test or acceptance.

In the Product and Service Lifecycle, this work belongs mainly to the transition activity, which training material describes as deploying new or changed products into the live environment.

Deploying is not releasing

For a long time the two happened at the same moment: the new version was installed on Sunday night, and on Monday morning every user had it. That coupling is what made releases risky — any problem hit everyone at once, and the only way back was to undo the whole installation.

Separating them is one of the most useful ideas in modern delivery. With a feature flag, new code is deployed to production switched off. Releasing is then a separate decision — a configuration change, not an installation — and it can be gradual: first Kestrel's own staff, then 5% of customers, then everyone. Turning the flag off again takes seconds.

A dark launch is deploying new functionality to production without making it visible to users, so it can be tested under real conditions first. Kestrel's new tariff calculator runs in production for two weeks, calculating every quote in the background next to the old one; the team compares the results, and users see only the old calculator. When the numbers match, the flag goes on.

Release planning, types and versions

Release management plans which changes go together and when. A release schedule shows the planned releases for the coming months, so the business, the service desk and other teams know what is coming, and so releases do not collide with each other or with busy periods — for an energy supplier, the week the annual bills go out.

Many teams number their releases with semantic versioning: MAJOR.MINOR.PATCH. The major number goes up for changes that break compatibility, the minor number for new compatible functionality, the patch number for fixes only. A service desk agent who sees "4.2.0 → 4.2.1" knows to expect a fix, not new screens.

Release:      Customer Portal 4.2.0                 Owner: Yara Haddad
Changes:      CHG-3381 (portal 4.2.0), CHG-3382 (billing API 2.7.0)
Contents:     Downloadable annual statement (PDF); faster meter-reading
              upload on mobile; 14 fixes (see release note)
Schedule:     Acceptance test   12-16 Oct   business testers, Customer Ops
              Deploy (dark)     20 Oct 21:00-22:00, rolling, no downtime
              Release           21 Oct staff, 22 Oct 5%, 26 Oct 100%
Go/no-go:     19 Oct 15:00 - acceptance sign-off, open defects, back-out test
Back-out:     flag off (seconds); full back-out = redeploy 4.1.3 (15 min),
              tested in acceptance on 15 Oct
Support:      knowledge article KB-0533 and service desk briefing 20 Oct
Not before:   annual bill run 2-6 Nov is change-freeze week

Environments

Before a release reaches production it passes through other environments: separate copies of the infrastructure where it can be built, tested and accepted without affecting users. The sequence is often called DTAP after its four environments (in Dutch: OTAP, for ontwikkeling, test, acceptatie, productie); the term is especially common in the Netherlands and Belgium. The four environments are:

• Development: where developers build and try their changes.
• Test: where automated and functional tests run against an integrated build.
• Acceptance: as close to production as possible, where business users and operations check the release before go-live. Elsewhere this is often called staging.
• Production: the live environment that users depend on.

The closer acceptance resembles production — same versions, same configuration, realistic data volumes — the fewer surprises on release day. Use anonymized or synthetic data in the lower environments; a copy of the production customer database in a test environment is a privacy incident, not a test strategy.

Service validation and testing

Service validation and testing is the practice of making sure new or changed products and services meet their defined requirements — both what they do and how well they do it — before and while they are released. Testing produces the evidence; validation is the judgment that the evidence is good enough to go live.

The Testing & QA topic covers each test level in depth, including the five levels the ISTQB names.

Automated regression tests run on every change to show that what worked before still works. Operational acceptance is the step teams most often skip: are monitoring, backups, runbooks and alerts in place for the new functionality? A release the service desk cannot support is not ready, however well it was tested. SRE teams formalize this check as a production readiness review.

Deployment approaches

How a release reaches production decides how many users a defect can hit and how fast you can go back. The Cloud topic describes the common strategies — rolling deployment, blue-green deployment and canary release. Two older terms you will still hear:

• Big bang: everything, for everyone, at once. Sometimes unavoidable (a new billing system cannot run half the customers on the old one), but then it needs the most rehearsal.
• Phased: by group, location or function — first one region's field engineers, then the rest. Canary releases and feature flags are the automated form of the same idea.

Checking a release on a small share of real users this way is a form of testing in production; INC-22047 shows what happens when a release reaches every instance at once.

Back-out plans and rolling forward

A back-out plan is the documented set of steps to return a service to its previous working state if a deployment or release fails, together with the criteria for deciding to use it. It is part of every change record and every release plan, and it should be tested — in acceptance, with a timer — before it is needed. An untested back-out plan is a hope.

Going back is not always possible. When a release has migrated the database to a new structure, sent emails to customers or exchanged data with a supplier, simply reinstalling the old version would break more than it fixes. Then the team rolls forward: fixes the problem with a quick follow-up release instead. That is a legitimate choice, but it must be made before the deployment, not discovered at 23:00. Good practice: make database changes backward compatible (add new columns first, remove old ones in a later release), so the previous version can still run.

During an incident, rolling back is the first of the generic mitigations; for infrastructure code, reverting and applying again does not bring back a destroyed database.

Releases, changes and CI/CD

A release is usually authorized through change enablement as one or more changes: the change record covers the risk, the timing and the back-out plan; the release plan covers the contents, the users and the readiness. In the plan above, the portal and the billing interface each have their own change, released together.

With continuous integration and continuous delivery (CI/CD), most of this is automated: every change is built, tested and made ready to deploy by the pipeline. With continuous deployment, every change that passes the automated checks goes to production without a manual step. That does not remove release and change management — it moves them into the pipeline. The automated tests are the validation, the pipeline's approval rules are the change authorization (often as pre-approved standard changes), and feature flags are the release decision.

A short release note tells users and the service desk what changes. This one is drafted with the plan above, ready for the full release:

Customer Portal 4.2.0 - release date 26 October 2026

New
- Download your annual statement as PDF (Account > Documents)
- Meter readings upload faster on mobile, also on slow connections

Fixed
- Payment page could show the wrong due date for monthly plans
- "Change address" form rejected postcodes with a space

Known issues
- Annual statement is not yet available for business customers (planned 4.3)

Service desk: see KB-0533 for questions about the annual statement.

Common mistakes

• Big-bang releases by habit. Collecting three months of changes into one release makes every release large, risky and hard to diagnose. Smaller, more frequent releases are easier to test and to back out.
• No back-out test. The back-out plan says "restore the previous version"; nobody has tried it, and the backup turns out to be incomplete.
• Acceptance that does not resemble production. Different versions, tiny data sets or missing integrations make acceptance tests prove little.
• Forgetting support. The service desk learns about the new feature from the first caller. Brief them and publish knowledge articles before the release.
• Releasing in the busiest week. Check the business calendar; that is what the release schedule and change freezes are for.