SAP BTP DevOps: CI/CD with Multi-Target Applications (MTA)

Packaging, building, and deploying multi-module BTP applications using the Multi-Target Application format and CI/CD pipelines.

A BTP application is not one deployable thing. A CAP project typically has four or five parts that must go out together.

Deploying a multi-module BTP application without MTA is like coordinating a house move by having different moving trucks show up at random uncoordinated times for furniture, plumbing, and electrical separately; MTA is a single coordinated moving day where everything arrives and gets set up together as one planned operation, and a CI/CD pipeline is the professional moving company's checklist ensuring nothing gets loaded onto the truck until it's been properly inspected and approved first.

Key Concepts

    db module        HANA artefacts: tables, views
    service module   Node.js or Java
    UI module        the Fiori or UI5 application
    resources        XSUAA, destination and connectivity bindings

Deploy them separately and they drift: the service expects a column the database module has not got yet, or the UI calls an endpoint that is not deployed.

MTA packages them as one unit. A single mta.yaml declares every module, the services to create and bind, and the order and dependencies between them:

mta.yaml

    mbt build            -> one .mtar archive
    cf deploy app.mtar   -> provisions and deploys it as one operation

If part of it fails, the deployment fails as a unit rather than leaving half a system live.

A pipeline wraps that with the usual stages.

    tests           CAP service tests, UI5 tests -- gate the build
    code scanning   quality and security
    mbt build       produce the archive
    deploy dev      automatic
    deploy QA       after the gate
    deploy prod     approved

SAP Continuous Integration and Delivery is the managed option, pre-integrated with MTA builds and Cloud Foundry. Jenkins, GitHub Actions and Azure DevOps work just as well, because mbt build and cf deploy are command-line tools any runner can invoke. That is worth saying — the SAP-specific part is the packaging format, not the pipeline.

mbt buildcf deploy

Environment-specific values belong in substitution, not in copies. One mta.yaml with placeholders resolved per environment:

mta.yaml

    destination: ~{backend-url}     # resolved per environment

Maintaining a separate descriptor per environment is the alternative, and they diverge — the production one missing a change somebody made only in development.

Blue-green deployment, for releases without downtime. Cloud Foundry can deploy the new version alongside the running one and switch traffic only once it is healthy:

    v1 serving traffic
    v2 deployed alongside, not yet routed
    health check passes -> traffic switches to v2
    v1 kept briefly, so a rollback is a switch back

And the framing. None of this is unique to SAP. Repeatable builds, automated test gates, environment parity and safe rollout are ordinary DevOps practice. What BTP adds is the MTA format, because the thing being deployed is genuinely several modules that must stay in step.

What the interviewer is probing.1. "What is an MTA?" Probing: the vocabulary. Stalls: "A package." Moves up: a deployment unit describing several modules and the resources they need, so one deploy brings up the app, database and UI consistently.

2. "What does mta.yaml declare?" Probing: the detail. Stalls: "The app." Moves up: modules, their types and dependencies, and required resources such as service instances — which is what makes the deploy reproducible.

3. "How do you promote through environments?" Probing: the pipeline. Stalls: "Rebuild." Moves up: build the MTAR once and deploy the same artifact to each subaccount, with destinations and service bindings supplying the differences.

4. "What testing belongs in the pipeline?" Probing: the engineering standard. Stalls: "Manual tests." Moves up: unit tests on CAP handlers and UI5 code, plus an integration test against a deployed instance — otherwise the pipeline only proves it compiles.