Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 3 of 5

Deployment plans and releases

11 min

Features answer "what changes". Deployment plans and releases answer "when, and to which systems". Without them, every feature goes to production on its own schedule, which is fine for a bug fix and dangerous for a go-live.

The terms

TermMeaning in Cloud ALMContoso example
SystemA tenant used for a product line, maintained in landscape managementCMD, CMQ and CMP
System groupThe systems of one product line that changes move throughContoso S/4HANA: CMD → CMQ → CMP
ReleaseA common timebox across projects that drives the schedule to production; its end date can be read as the go-live dateRelease 1 (Q3 go-live), Release 1.1 (first hypercare drop)
Deployment planA collection of system groups and release timelines; one plan can serve several projectsContoso S/4HANA Deployment Plan

Deployment planning vocabulary, from SAP Learning’s deployment management lesson.

You create the deployment plan, give it its releases, and assign its system groups. Then you assign the plan to the project. Only after that can you assign releases to requirements, user stories and features. SAP's guidance distinguishes two levels: the release on a requirement indicates the planned release to production; the actual release to production is planned on the feature.

Deployment planContoso S/4HANA Deployment Plan: system groups plus release timelines
ReleasesRelease 1 (ends on go-live weekend), Release 1.1 (four weeks later)
ProjectsS/4HANA conversion project and the integration project share the plan
Requirements and featuresEach feature carries the release it is meant to go live with
The planning hierarchy that lets several projects go live together.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-301

Releases as timeboxes

Think of a release as a train timetable. Features board the train they are ready for. Plan the releases to match your sprint or build-cycle plan, so that work finished in a sprint has a release to deploy with. At Contoso, Grace, the PMO lead, aligned Release 1's milestones with the integration test and user acceptance test cycles, so each feature's release date also says which test cycle it must pass.

  1. Build cycles 1–3Features enter In ImplementationAssigned to Release 1 in the deployment plan
  2. Integration testFeatures in testingTransports in CMQ; test runs linked to features
  3. UAT exitFeatures Successfully TestedMaria and Dan sign off their processes
  4. Go-live weekendFeatures Ready for ProductionLuis approves and mass-deploys Release 1
  5. Hypercare week 4Release 1.1Fixes and small changes from hypercare deploy together
Release 1 at Contoso: feature statuses follow the test calendar.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-301

Deploying a release

For a single change, the Deploy button in the feature sends all its transports to the target. For a go-live, the Features overview lets you select many features and choose Deploy to Production once, for example every feature in Release 1 that is Ready for Production. Cloud ALM ignores transports that are still modifiable, and imports the transports that are furthest from production first, which matters when different transport tracks have different numbers of systems.

For repeated deployments, the Deployment Scheduler lets you schedule transport deployments by system role (quality assurance, pre-production, production) in a controlled sequence, and the Deployment app works with the features assigned to a deployment plan as a bundle. Capabilities in this area are added most quarters, so check the What's New page of your tenant before you design the process around a specific button.

Which train does a change catch?

Not every feature belongs on the go-live train. A hot fix for a production incident after go-live should not wait four weeks for the next planned release. Agree up front which kinds of change travel how, and write it into the release procedure so nobody negotiates it under pressure.

Small, not urgentBoard the next planned release; routine test and approval
Small, urgentEmergency release with a single feature; focused test, Change Manager approval, review afterwards
Large, not urgentPlan into a future release; full regression and process owner sign-off
Large, urgentEscalate to Grace and the process owners; usually split the change or accept a workaround
Which train a feature catches, by urgency and risk.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-301

Keep the feature-to-release assignment honest. If a feature slips, change its release in Cloud ALM the day it slips, not on go-live weekend. Luis reviews a filtered list of Release 1 features every week with Grace: status, release and responsible person. Features with no release, or with a release that has already passed, are the first agenda item.

What would you do?

It is two days before go-live. 112 features are Ready for Production in Release 1, but three are still In Testing. Grace asks Luis to deploy "everything in Release 1". What should Luis do?

Key points
  • A deployment plan holds system groups and release timelines and can serve several projects.
  • A release is a common timebox; its end date is effectively the go-live date.
  • Requirements carry the planned release; features carry the actual release to production.
  • Mass Deploy to Production deploys many Ready for Production features together; the Deployment Scheduler automates imports by system role.

Check your understanding · not graded

Lesson check

  1. 1. What must you do before you can assign releases to requirements and features?

  2. 2. Which statement about a release in Cloud ALM is accurate?

  3. 3. During a mass deployment, what happens to transports still in modifiable status?

  4. 4. Where is the actual release to production planned?