Lesson 1 of 5
MTA packaging: one archive, one lifecycle
11 min
Listen to this lesson
Contoso Motor Co.'s fleet order status app has grown up. What started as a single Node.js service now has a user interface, a service layer built with the SAP Cloud Application Programming Model, a database deployer for SAP HANA Cloud, and bindings to the destination, authorization and HTML5 repository services. Each piece could be deployed by hand, but then nobody could say for sure which version of which piece is running in which subaccount. The answer on Cloud Foundry is the multitarget application (MTA): one application made of several parts that share one lifecycle and are deployed together.
The three descriptors
SAP's documentation distinguishes three YAML files, and mixing them up is the most common source of confusion. The development descriptor, mta.yaml, lives in the source repository and lists modules, resources, properties and dependencies. Tools such as SAP Business Application Studio generate it, but developers usually edit it. The deployment descriptor, mtad.yaml, is what the SAP Cloud Deployment service actually reads; the Cloud MTA Build Tool generates it from the development descriptor during the build. The extension descriptor, a file ending in .mtaext, sits outside the archive and adds or overrides parameters and properties for one target, such as production. Lesson 4 is about extension descriptors.
| mta.yaml | mtad.yaml | .mtaext | |
|---|---|---|---|
| Name | Development descriptor | Deployment descriptor | Extension descriptor |
| Lives in | Source repository | Inside the MTA archive | Outside the archive, per target |
| Written by | Developers, with tool support | Generated by the build | Platform or release team |
| Purpose | Describe modules, resources and dependencies | Tell the deploy service what to create | Adjust parameters and properties for one environment |
| Changes per stage? | No | No: built once | Yes: one per target |
The archive: what actually moves
The build produces an MTA archive (.mtar): a package that follows the JAR file format and contains the deployment descriptor, the built module binaries and configuration files. That archive is the unit of deployment and the unit of transport. SAP Cloud Transport Management accepts .mtar files for the MTA content type, and the SAP Cloud Deployment service deploys them, for example with the Cloud Foundry CLI command cf deploy. When Priya asks "what exactly are we testing?", the honest answer is a file name and a version: fleet-order-status_1.4.0.mtar.
The deploy service validates the descriptor against the MTA specification version before it changes anything. If validation fails, the deployment stops at the start, which is far better than a half-deployed app. It then creates or updates service instances, deploys modules as Cloud Foundry applications or content, binds them, and starts them, following the dependencies in the descriptor.
Build once, promote many
The single most important rule in this course follows from the archive: build once, then promote the same archive through test and production. If the pipeline rebuilds from source for each stage, the production archive may pull a newer library, a different build tool version or an uncommitted change, and the test results no longer describe what reaches production. Differences between stages belong in configuration (lesson 4), never in a rebuild.
- CommitA developer pushes a change to the main branch of the fleet order status repository
- BuildThe pipeline runs the Cloud MTA Build Tool: mta.yaml in, fleet-order-status_1.4.0.mtar out
- Test in developmentThe same archive is deployed to the development space and tested
- Promote to testThe same archive enters the CMC_TEST import queue and is imported into cmc-ext-test
- Promote to productionThe same archive is imported into cmc-ext-prod after sign-off
| Question from the test lead | Where the answer lives |
|---|---|
| Which modules does this release contain? | modules section of mta.yaml, and the archive contents |
| Which services does it need? | resources section, with service and service-plan parameters |
| What runs in production right now? | The MTA ID and version shown for deployed MTAs in the target space |
| Was the tested archive the one imported? | The transport request in SAP Cloud Transport Management, which names the archive |
Turning the MTA model into test evidence.
What would you do?
The fleet order status app passed all tests in cmc-ext-test with archive 1.4.0. Before the production import, a developer offers to "rebuild it quickly from main with the latest fixes, same version number". What should Priya say?
- An MTA is one application made of modules and resources that share a lifecycle.
- mta.yaml is the development descriptor; mtad.yaml is the deployment descriptor; .mtaext files extend it per target.
- The .mtar archive is the unit of deployment and transport; the deploy service validates it before changing anything.
- Build once and promote the same archive; put stage differences in configuration, not in rebuilds.
- Version every release candidate; versions tie together deployments, transports and test evidence.
Check your understanding · not graded
Lesson check
1. Which file do developers normally edit to describe modules, resources and dependencies?
2. What is an MTA resource?
3. Why should the same archive be promoted through test and production?
4. What happens if the deployment descriptor fails validation?