Lesson 2 of 5
Designing the pipeline: build, test, release
10 min
Listen to this lesson
A pipeline turns the build-once rule into something that happens every time, not only when someone remembers. SAP Continuous Integration and Delivery is SAP BTP's service for this. It offers predefined pipelines for SAP development scenarios; your own configuration of a pipeline is called a job. Contoso runs the service in its shared services subaccount, cmc-central-services, next to SAP Cloud Transport Management, as SAP's DevOps reference architecture recommends for shared tools.
- BuildPackages the app into a deployable archive with the chosen build tool (mta by default); optional static code and lint checks. Mandatory
- Additional Unit TestsRuns the test scripts you name from the build descriptor
- Malware ScanScans the project files for malware
- AcceptanceDeploys to a Cloud Foundry space and runs automated end-to-end tests against it
- ComplianceRuns automated code quality and security analysis against a code-analysis server you provide
- ReleaseDeploys to a Cloud Foundry space and/or hands the archive to SAP Cloud Transport Management
Setting up a job
A job connects four things: a repository and branch (for example, main of the fleet order status repository), a pipeline (for a CAP or SAP Fiori app on Cloud Foundry, the Cloud Foundry Environment pipeline), the stage configuration, and credentials. A webhook in the source code management system tells the service about each push, so a commit starts a build. The stage configuration can be kept in the job editor, which SAP recommends, or in a configuration file in the repository; teams that review pipeline changes like code often prefer the repository option.
Credentials deserve care. The Acceptance and Release stages need a user with the Space Developer role in the target space, and SAP's documentation says to use a technical user, not personal credentials. The transport step needs a service key for SAP Cloud Transport Management. These are stored as credentials in the service and referenced by name, so they never appear in the repository.
Two pipelines, not one
SAP's DevOps reference architecture describes a split that suits enterprise teams: a CI pipeline qualifies every change pushed by developers, and when the team is satisfied with the results, the qualified release candidate is submitted to a release branch, which triggers a release pipeline. The release pipeline can run compliance checks and, as its last step when all tests have passed, trigger a transport in SAP Cloud Transport Management. The reference architecture notes that one pipeline covering both is possible, but separate pipelines decouple development from delivery.
| CI pipeline (main) | Release pipeline (release branch) | |
|---|---|---|
| Triggered by | Every push to main | A merge of a release candidate into the release branch |
| Stages Contoso uses | Build, Additional Unit Tests, Malware Scan, Acceptance in the development space | Build, unit tests, Malware Scan, Compliance, Acceptance, Release to transport |
| Output | Fast feedback to developers | One versioned archive in the CMC_TEST import queue |
| Who watches it | Developers | Release and test team |
Tests in the pipeline
A pipeline is only as good as its tests. The Build stage can run static code checks and lint checks, and can fail the build on lint errors. The Additional Unit Tests stage runs unit tests named in the build descriptor; if they fail, the job fails and later stages do not run. The Acceptance stage first deploys the archive to a Cloud Foundry space, then runs browser-based end-to-end tests against the app's URL, authenticating with a technical test user. For a CAP app, Contoso's split is simple: service logic and authorization checks in unit tests, the few critical user journeys (search an order, open its delivery status) in end-to-end tests.
| Test type | Where it runs | What it proves for the fleet order status app |
|---|---|---|
| Static and lint checks | Build stage | Code follows rules; obvious errors caught without running it |
| Unit tests | Additional Unit Tests stage | Order status mapping and authorization logic work in isolation |
| End-to-end tests | Acceptance stage, development space | A fleet user can find an order and see its delivery status |
| Code quality and security analysis | Compliance stage | No new findings above the agreed threshold |
| Integration and regression tests | cmc-ext-test after import, against CMQ client 100 | The app works with the real S/4HANA test system and roles |
Which test runs where.
Pipelines also need operating rules. Build logs are kept for a set number of days and builds; Contoso sends build notifications through SAP Alert Notification service to the team channel so a red build is seen within minutes, and fixing a broken main build beats starting new work.
- Did the build or a unit test fail?Yes → fix on main before anything else; the job stops here · No → continue
- Did the malware scan or compliance step report findings above threshold?Yes → stop; fix or record an approved exception · No → continue
- Did the end-to-end tests in the development space pass?Yes → the release pipeline may hand the archive to transport · No → fix and push a new version
What would you do?
Kenji's BTP developers complain that the release pipeline takes 25 minutes and ask to remove the Acceptance stage "because Priya's team tests in cmc-ext-test anyway". What is the best response?
- SAP Continuous Integration and Delivery runs predefined pipelines; your configuration of one is a job.
- Cloud Foundry Environment stages: Build, Additional Unit Tests, Malware Scan, Acceptance, Compliance, Release.
- Use technical users and stored credentials; a webhook starts builds on push.
- Separate CI and release pipelines decouple development feedback from delivery.
- Pipeline tests prove the archive works; integration and regression testing still happen in the test subaccount.
Check your understanding · not graded
Lesson check
1. In SAP Continuous Integration and Delivery, what is a job?
2. Which stage is mandatory and runs with every build?
3. What credentials should the Acceptance and Release stages use for Cloud Foundry?
4. In the reference architecture, what triggers the release pipeline?