2.3Release & deployment management

If change management is the process that decides "whether a change may be made," release and deployment management is the process responsible for "how approved changes are packaged and safely delivered to production." For the same approved change, whether it is distributed to all users at once or rolled out gradually from a subset completely changes the impact scope if it fails. This section covers how a service manager plans and judges distribution to a live service through designing the release unit, choosing the deployment approach, and separating build, test, and deploy.

2.3.1Release units and build/test/deploy

• A release unit is the bundle of changes moved to production together. Packaging related changes into one release lets coordination and testing happen once, but packaging too much makes failures hard to isolate and rollback heavy. Splitting too finely increases the number of coordination cycles. Design the unit by balancing impact scope against ease of testing and rollback.
• Separating build, test, and deploy means building and testing the release in an environment equivalent to production before deploying, to confirm quality. Deploying the tested artifact as-is to production reduces differences that appear only in production. Deploying directly to production without testing increases release-caused incidents.

2.3.2Choosing a deployment approach

• Big-bang deployment deploys to all targets at once. It finishes quickly and puts all users in the same state, but if it fails, all users are affected simultaneously. It suits low-impact, well-verified releases.
• Phased deployment splits the targets and rolls out to a subset first, then expands. It includes a pilot (deploying first to a limited set of users or sites, confirming there are no problems, then expanding to the whole). It confines the impact of a failure to a subset, detects problems early, and can halt the remaining rollout, so it suits high-impact, high-uncertainty releases—though a period of mixed old and new states arises until completion.

A service manager is deciding how to design the release unit and deployment approach for rolling out an approved large-scale feature-revision release (including a screen redesign and business-logic changes) to a business system used across 100 sites nationwide. First, on the release unit, because the screen redesign and logic changes are mutually dependent, the manager packages them into one release, while separating the release unit for an unrelated master-data update scheduled for the same period, so that if either fails, isolation and rollback remain easy. Next, on the deployment approach, the change has a wide impact scope and may still harbor defects that surface only in real use, so a big-bang deployment distributing to all 100 sites at once carries too great a risk of halting every site's operations simultaneously if it fails. The manager therefore first deploys to a few sites as a pilot, monitors real-business behavior, performance, and the volume of inquiries for a period to confirm there are no problems, and then rolls out phased to the remaining sites. With this approach, if the pilot uncovers a serious problem, the remaining rollout can be halted, confining the impact to a few sites and rolling back. However, phased deployment creates a period where deployed and not-yet-deployed sites run mixed old and new versions, so the manager confirms in advance that operations exchanging data between sites will not become inconsistent (compatibility of old and new formats), preparing transitional compatibility handling if needed. Furthermore, on any deployment, the manager uses artifacts already built and tested in a staging environment equivalent to production, and ties a back-out plan (the procedure to cancel that batch's deployment and revert to the old version, and the decision deadline) to each stage. Release and deployment management is thus not "just distributing an approved change," but the judgment to design the release-unit split, the deployment approach (big-bang or phased), consideration for mixed old and new states, and rollback preparation according to the release's impact and uncertainty.

2.3.3Section summary

• Release and deployment management safely distributes changes approved in change management to production (deciding whether a change may be made is change management's role)
• Design the release unit by balancing impact scope against ease of testing and rollback, and confirm quality by building and testing before production
• Choose the deployment approach—big-bang or phased (including a pilot)—by the release's impact and uncertainty; the higher the impact, the more phased deployment localizes it