BTP & Integrationintermediate

BTP Cloud Foundry Part 2: Deploying with Manifests and Multitarget Applications

Key takeaway

Deploy repeatably: manifest. yml for single apps (memory, instances, routes, services), multitarget applications (MTA) with mta. yaml describing modules and resources, building an . mtar with the MTA build tool and deploying with cf deploy — including resource creation and dependencies.

Explanation

📌 KEY POINTS
✅ manifest.yml defines app settings (memory, instances, routes, services) for cf push.
✅ MTAs describe several modules (app router, services, UI) and resources (XSUAA, HANA HDI, destination) in mta.yaml.
✅ mbt build creates an .mtar archive; cf deploy creates/updates resources and modules in order.
✅ MTAs are the standard for CAP and SAP apps and work with transport management.
⚠️ Manually creating services outside the MTA leads to drift between environments.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 covered basics. Now repeatable deployment.

━━━━━━━━━━━━━━━━━━━━
▶ 1. MANIFEST

App-level settings for cf push.

━━━━━━━━━━━━━━━━━━━━
▶ 2. MTA STRUCTURE

Modules, resources, requires/provides.

━━━━━━━━━━━━━━━━━━━━
▶ 3. BUILD

mbt build → .mtar.

━━━━━━━━━━━━━━━━━━━━
▶ 4. DEPLOY

cf deploy (MultiApps CLI plugin); blue-green option.

━━━━━━━━━━━━━━━━━━━━
▶ 5. ENVIRONMENTS

Extension descriptors (.mtaext) per environment.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Write a small mta.yaml with app + xsuaa.
Build with mbt.
Deploy with cf deploy and check resources.

✅ CHECKPOINT: redeploy updates without manual steps.

Code example

ABAP Code

===== mta.yaml (simplified) =====ID: acme.ordersversion: 1.0.0modules:  - name: orders-srv    type: nodejs    path: gen/srv    requires: [ { name: orders-auth }, { name: orders-db } ]resources:  - name: orders-auth    type: org.cloudfoundry.managed-service    parameters: { service: xsuaa, service-plan: application }  - name: orders-db    type: com.sap.xs.hdi-container ===== COMMANDS =====mbt build          # creates mta_archives/acme.orders_1.0.0.mtarcf deploy mta_archives/acme.orders_1.0.0.mtarcf deploy ... -e prod.mtaext   # environment-specific values

Real project scenario

A team deployed apps with cf push and created services by hand in each space; test and production differed. Moving to an MTA with extension descriptors made deployments identical and ready for transport management.

Common mistakes

Manual services.
Editing mta.yaml per env.
No versioning.
Ignoring dependencies.
Pushing from laptops to prod.

Best practices

Services as MTA resources.
mtaext per environment.
Version MTAs.
Declare requires/provides.
Pipeline-based deployment.

Interview angle

Questions: "Manifest vs mta.yaml?", "How is an MTA deployed?", "How do you handle environment differences?"
Strong answer: manifest, MTA structure, build/deploy, extension descriptors, pipelines.

Practice this lesson

Quick check

1. When executing cf push on an application that already has running instances, what mechanism helps achieve near zero-downtime during redeployment?

2. A team creates services manually in each space and environments drift apart. What fixes this?

3. What is the primary purpose of a manifest.yml file when deploying an application to Cloud Foundry using the cf push command?

Interview questions

1. What are the most important design decisions, trade-offs, and best practices in Cloud Foundry?

Answer it in your own words first, then compare.

2. Deployments differ between test and production spaces. How do you make Cloud Foundry deployments reproducible?