Lesson 3 of 5
Promotion with SAP Cloud Transport Management
10 min
Listen to this lesson
The release pipeline ends with an archive that passed every automated gate. From here, Contoso does not want the pipeline to deploy to production on its own: production changes need an audit trail, an approval and a time window. That is the job of SAP Cloud Transport Management, which moves the archive along a route of transport nodes. Course sap-rel-203 covers the service in depth; this lesson connects it to the pipeline.
- Release pipelineBuilds and tests fleet-order-status_1.4.0.mtar
- Export from CMC_DEVThe Release stage adds the archive to a transport request that can no longer be changed and places it in the import queue of the next node
- CMC_TEST import queueImports automatically into cmc-ext-test; Priya's team then runs integration and regression tests against CMQ client 100
- Forward after sign-offCMC_TEST uses forward mode Manual: Priya chooses Forward once testing is signed off
- CMC_PROD importThe scheduled import Luis set for the approved release window picks it up; the request records what was imported and when
Connecting the pipeline to transport
The Release stage of a Cloud Foundry Environment job offers a Cloud Transport Management step with two transport operations. Upload to adds the archive to a transport request in the queue of the named upload node; someone then imports it there. Export from adds the archive to a transport request that cannot be changed anymore, exports it from the named export node and puts it into the import queue of the node that follows. SAP's documentation recommends Export from for lifecycles driven by SAP Cloud ALM. Either way, the job authenticates with a service key credential for the transport service, or for SAP Cloud ALM, which includes the cloud transport management capability.
Contoso uses Export from with CMC_DEV as the export node. The pipeline has already deployed to development during Acceptance, so the first import that matters is CMC_TEST.
Nodes, routes and forwarding
Each transport node represents a target end point, connected through a destination to the deploy service of a subaccount and space. Nodes are joined by routes; a node can be the source of several routes but the target of only one. Each node has a forward mode that decides when a request moves on to the next queue:
| Forward mode | When the request is forwarded | Use it when |
|---|---|---|
| Pre-Import (default) | Before the import in this node starts | Queues should fill early and imports run independently |
| Post-Import | After the import, regardless of the result | Rarely; failed imports still travel on |
| On Success | Only after a successful import (Succeeded, Warning or Skipped) | A failed test import must not reach production's queue |
| Manual | Only when someone chooses Forward in the queue | Forwarding itself is a deliberate decision |
Contoso sets CMC_TEST to Manual. Production imports run on a schedule in the approved release window, so anything that reaches the CMC_PROD queue is imported on the next run. On Success would not be enough: it forwards after a technically successful import, which is not the same as a tested and approved one. With Manual, Priya chooses Forward only after test sign-off, so the production queue only ever holds tested requests.
Imports and statuses
Imports can be started by hand, scheduled (daily or weekly patterns), or made automatic, so a request is imported as soon as it enters the queue. Contoso uses automatic import for CMC_TEST, so testers get new versions without waiting, and a scheduled import in CMC_PROD that runs in the approved release window. Statuses tell the story of each request: Initial before import, Running, then Succeeded, Warning, Error or Fatal. SAP's documentation draws a useful distinction: Fatal means nothing was imported, often because of a wrong destination or failed authentication, and the request can simply be imported again once that is fixed; Error means the content itself failed, so it must be reset before a re-import, and re-importing unchanged content will not fix it.
| Status | What it tells the release team | Typical next step |
|---|---|---|
| Succeeded / Warning | Imported; read warnings before testing | Start the test cycle; review the warning text |
| Fatal | Nothing imported; deployment did not start | Fix destination or credentials, then import again |
| Error | Imported partially or with errors; the content is the problem | Fix the content in a new version; reset only if a re-import makes sense |
| Initial | Waiting in the queue | Import when the window and approval allow |
Reading import statuses.
What would you do?
The overnight automatic import into CMC_TEST ends with status Fatal within seconds. The log says authentication to the deploy service failed. What should the release team do first?
- The Release stage can hand the archive to SAP Cloud Transport Management with Upload to or Export from.
- Export from is recommended for lifecycles driven by SAP Cloud ALM; it creates a request that can no longer be changed.
- Nodes are joined by routes; forward modes are Pre-Import, Post-Import, On Success and Manual.
- Imports can be manual, scheduled or automatic; behind a scheduled production import, Manual forwarding from test is the sign-off gate.
- Fatal = nothing imported (fix connection, re-import); Error = content problem (fix content).
Check your understanding · not graded
Lesson check
1. Which transport operation does SAP recommend for lifecycles driven by SAP Cloud ALM?
2. With forward mode On Success, when does a request move to the next queue?
3. What does the status Fatal tell you?
4. How many routes can target the same transport node?