Lesson 5 of 5
Release gates: from green build to signed-off production
10 min
Listen to this lesson
A gate is a point where a release candidate must meet stated criteria before it moves on. The pipeline gives Contoso automated gates; the transport path gives places for human ones. The art is putting each check at the earliest gate that can make it, and writing down what "pass" means before anyone is under pressure. Priya, Luis and Grace agreed on the gates below before the first production release of the fleet order status app.
- Gate 1Build qualityBuild succeeds; unit tests pass; lint errors fail the build; malware scan clean
- Gate 2ComplianceCode quality and security analysis: no new findings above agreed severity, or an approved exception
- Gate 3AcceptanceArchive deploys to the development space; critical end-to-end journeys pass
- Gate 4Test importImport into CMC_TEST Succeeded or warnings reviewed; smoke test passes in cmc-ext-test
- Gate 5Test exitIntegration and regression against CMQ client 100 complete; no open critical or high defects; evidence filed
- Gate 6Change approvalChange approved; import window agreed; rollback plan named
- Gate 7Production verificationImport Succeeded; smoke test in cmc-ext-prod passes; monitoring quiet for the agreed period
Automated gates: make them fail loudly
Automated gates only work if a failure stops the line. In SAP Continuous Integration and Delivery, a failed stage fails the job, and later stages do not run; the lint check has a Fail on Error option. The weak spot is usually the threshold, not the tool: a compliance step that reports 300 findings and passes anyway is decoration. Contoso's rule is "no new findings above medium severity", measured against the previous release, with exceptions approved by Kenji and recorded.
Human gates: evidence, not opinions
Gates 4 to 7 need people, and people need criteria. Each gate has an owner, entry criteria, exit criteria and evidence, the same structure Contoso uses for its S/4HANA test cycles. Approval of the production import is recorded in SAP Cloud ALM, where the feature for the release links the requirement, the test results and the transport request, so the approver sees the evidence in one place.
| Gate | Owner | Exit criteria | Evidence |
|---|---|---|---|
| 4 Test import | Release team | Import status Succeeded, or Warning with each warning reviewed | Transport request ID and import log |
| 5 Test exit | Priya | Planned tests executed; no open critical or high defects; regression pass rate agreed | Test run results in SAP Cloud ALM, defect list |
| 6 Change approval | Luis and the process owner | Gate 5 met; window agreed; rollback and contacts named | Approval record linked to the feature |
| 7 Production verification | Release team, key user | Smoke test passes; no new alerts in the observation period | Smoke test record, monitoring screenshot or export |
Human gates with owners and evidence.
Deploying without drama
Two deployment techniques reduce the risk at gate 7. With the blue-green deployment strategy (cf deploy --strategy blue-green), the new version is deployed as "idle" applications with temporary routes while the old version keeps serving users. The process pauses for a testing phase; you test the idle version on its temporary routes, then resume to switch the productive routes, or abort. SAP's documentation lists the limits: blue-green applies to Cloud Foundry applications, not to bound services or HTML5 repository content; old and new versions share the same service instances, so changes must be compatible (database tables included); and both versions run at once, so the subaccount needs memory quota for double the instances. The pipeline's deploy steps offer blue-green as a deploy strategy and remind you to raise the memory quota first.
- Deploy idleVersion 1.5.0 starts next to 1.4.0 with temporary routes; users still on 1.4.0
- Test idleSmoke test the critical journeys on the temporary routes
- DecideResume to switch productive routes to 1.5.0, or abort
- ObserveWatch errors and response times for the agreed period
Rollback deserves a plan written before go-live. Aborting a blue-green deployment does not roll anything back by itself: apps, routes and services stay as they are, and you may need to remove the idle versions. SAP also documents an experimental rollback option for MTAs that requires backing up the previous version during deployment; treat it as experimental and check its current status for your landscape. The robust fallback is the transport path itself: the previous archive version can be imported again, provided it and its extension descriptor are still available.
What would you do?
The compliance step reports a new high-severity finding in a library the fleet order status app uses. Grace asks whether the release can go ahead because the business wants the new search feature this week. What should happen?
- Gates are agreed criteria at fixed points: build, compliance, acceptance, test import, test exit, approval, production verification.
- Automated gates must stop the line; thresholds matter more than tools.
- Human gates need owners, exit criteria and evidence; Contoso records approval in SAP Cloud ALM.
- Blue-green deploys an idle version you can test before switching routes; services are shared and quota doubles.
- Plan rollback in advance; aborting blue-green is not a rollback.
Check your understanding · not graded
Lesson check
1. In blue-green deployment, what do old and new application versions share?
2. What does aborting a blue-green deployment do?
3. What makes an automated gate effective?
4. Why does blue-green deployment need extra memory quota?