Lesson 1 of 5
Delivery flows
11 min
Listen to this lesson
Automated tests only protect a release when they run at the right point in the delivery flow and their results can stop a bad change. That point is called a quality gate: a step where evidence is checked and the change either proceeds or stops. Before designing gates you need a clear map of how change actually travels in an SAP landscape, because SAP has three quite different delivery flows and most enterprises run all three at once.
Contoso Motor Co. is a good example. After the conversion, Kenji's ABAP team delivers custom code and configuration to the S/4HANA systems CMD, CMQ and CMP with transports. A small team builds a side-by-side extension on SAP BTP with the SAP Cloud Application Programming Model (CAP) and an SAP Fiori elements front end, a fleet warranty portal for customers such as Great Lakes Fleet Services. And Contoso is evaluating SAP S/4HANA Cloud Public Edition for a future subsidiary, where SAP delivers releases on its own schedule.
Three flows
| Flow | Unit of change | How it moves | Who triggers tests |
|---|---|---|---|
| ABAP (Private Edition, on-premise) | Transport request with tasks | Released in CMD, imported into CMQ and CMP through the transport management system, often orchestrated by SAP Cloud ALM features or ChaRM | Developer on release; release manager on import |
| SAP BTP (CAP, UI5) | Commit, then a built archive (an MTA archive for multi-target apps) | A pipeline builds, tests and deploys; SAP Cloud Transport Management can move the archive through dev, test and production subaccounts | The pipeline on every push or merge |
| Public Edition releases | SAP release or update; customer adaptations through the public cloud transport tools | SAP upgrades the test system first, then development and production about three weeks later | Customer regression, often with the Test Automation Tool |
ABAP: the transport path
- Develop in CMDCode and configuration recorded in transport tasks.
- Release task and requestChecks such as ATC and ABAP Unit can run here, before anything leaves development.
- Import into CMQAutomated regression and manual tests run against the integrated system.
- ApproveTest evidence and sign-off are attached to the change or feature.
- Import into CMPProduction deployment, followed by smoke checks.
In SAP Cloud ALM, a feature bundles the transports that belong to one change. SAP's learning material describes a flow where transports are assigned to a feature, released, deployed to the quality system and, once the feature is ready for production, deployed to production. That gives automated test evidence a natural home: the feature that moves through the landscape. Legacy landscapes managed in SAP Solution Manager use ChaRM for the same purpose, as Contoso's ECC support team still does for ED1, EQ1 and EP1.
After go-live Contoso added one more stop on the ABAP path: CMR, a masked copy of production refreshed quarterly before each regression window. It receives only transports already approved for the next CMP import, and the release regression that gates the production import runs there, while CMQ keeps the project and enhancement testing. For gate design that means two regression points: a fast suite in CMQ when a transport arrives, and the full release regression in CMR before Luis imports into CMP.
BTP: the pipeline
On SAP BTP, delivery is pipeline-driven. SAP Continuous Integration and Delivery is SAP's managed service: it offers predefined pipelines, including one for CAP projects, configured through a user interface, without hosting your own build server. For teams that need more flexibility, SAP's open-source project "Piper" offers pipeline building blocks. A push to the repository triggers the pipeline through a webhook; the pipeline builds the application, runs its tests and, if configured, deploys it and hands the archive to SAP Cloud Transport Management for controlled promotion.
Public Edition: SAP's release cadence
In SAP S/4HANA Cloud Public Edition, SAP owns the upgrade. SAP's learning material describes two major releases a year, a notification about six weeks ahead, the test system upgraded first and development and production about three weeks later. The customer's job is regression in that window, typically using the embedded Test Automation Tool, whose results also appear in SAP Cloud ALM alongside manual test plans.
What would you do?
Grace asks why the BTP warranty portal and the ABAP changes cannot use the same gate. What is the best explanation?
- A quality gate checks evidence at a point in the flow and stops a bad change.
- ABAP changes move as transports; Cloud ALM features or ChaRM orchestrate them.
- BTP apps move through pipelines; SAP Continuous Integration and Delivery and Cloud Transport Management support this.
- Public Edition releases are SAP-driven; customers regress in the window before production.
- Map your own landscape and current tests before designing gates.
Check your understanding · not graded
Lesson check
1. What is the unit of change in the ABAP delivery flow?
2. In SAP Cloud ALM, what bundles the transports that belong to one change?
3. What triggers a BTP pipeline in SAP Continuous Integration and Delivery after a developer pushes code?
4. After go-live, where does Contoso run the full release regression that gates the import into CMP?