70 · CF Deploy

Use the MTA CF Plugin to deploy, monitor, resume failures, do staged deploys with --no-start, and undeploy.

Episode 70 — CF Deploy: Deploying an MTA to Cloud Foundry

What you'll learn

How cf deploy works and what it does step by step
How to install and use the MTA CF Plugin
How to handle deploy failures, partial deploys, and rollbacks
How to use --no-start for staged deployments
How to manage multiple MTA versions with cf deploy --strategy

Why this matters

cf push deploys a single app. cf deploy deploys an entire MTA — creating services, running deployers, pushing modules, and wiring bindings — in the correct dependency order. Understanding what cf deploy does under the hood means you can diagnose stuck deploys, pick up from partial failures, and choose the right strategy (standard vs blue-green) for each release.

Installing the MTA CF Plugin

# Download the plugin from the CF Community Plugins repo
cf install-plugin multiapps

# Verify
cf mta --help

The deploy lifecycle

When you run cf deploy my-cap-app.mtar, the plugin executes these phases:

1. Upload archive to CF Deploy Service
2. Resolve descriptor — expand parameters, validate dependencies
3. Create/update resources (managed services)
4. Run content deployers (HDI deployer, HTML5 deployer)
5. Push modules (CF apps)
6. Bind services to modules
7. Start modules

Each phase is idempotent: if a deploy fails mid-way, re-running cf deploy resumes from where it stopped (or you can restart it with cf redeploy <operation-id>).

Basic deploy command

# Build first
mbt build -t ./

# Deploy
cf deploy my-cap-app_1.0.0.mtar

# With verbose output
cf deploy my-cap-app_1.0.0.mtar -f    # force — skip confirmation prompts

Monitoring a deploy in progress

# List active deploy operations
cf mta-ops

# Tail the log of a specific operation
cf dmol -i <operation-id>

# List deployed MTAs
cf mta my-cap-app

# Show modules and resources of a deployed MTA
cf mta-modules my-cap-app
cf mta-services my-cap-app

Resuming or aborting a stuck deploy

# List operations — find the stuck one
cf mta-ops

# Resume from where it stopped
cf resume-mta-op -i <operation-id>

# Or abort it
cf abort-mta-op -i <operation-id>

Staged deployment: `--no-start`

Build and deploy infrastructure (services + deployers) without starting the CAP app:

# Deploy services and run content deployers, do not start the CF apps
cf deploy my-cap-app.mtar --no-start

# Verify the database schema was applied correctly, run smoke tests, then:
cf start my-cap-app-srv
cf start my-cap-app-approuter

This is useful for production deployments where you want a human gate before traffic is routed.

Undeploy (teardown)

# Remove all modules and resources defined in the MTA
cf undeploy my-cap-app --delete-services --delete-service-keys

--delete-services also deletes the bound managed services — use with caution in production; this drops your HANA HDI container.

Partial deploy: single module

When only the CAP service code changed (no schema changes, no UI changes):

# Deploy only the CAP service module
cf deploy my-cap-app.mtar --modules my-cap-app-srv

This skips the HDI deployer and UI deployer — much faster.

Deploy with strategy

# Blue-green deploy (Episodes 72 covers this in detail)
cf deploy my-cap-app.mtar --strategy blue-green

Common mistakes

Mistake	Fix
`cf push` instead of `cf deploy`	`cf push` bypasses the MTA — services won't be bound correctly
Not running `mbt build` before `cf deploy`	Deploy uses the old `.mtar` — always build first in CI/CD
`--delete-services` in production	This drops HANA and XSUAA — data loss risk
Deploying from a laptop	Use a CI/CD pipeline; local network issues cause incomplete deploys
Ignoring `cf mta-ops` output	Check for stuck operations before re-deploying

Checkpoint ✓

You can install the MTA CF Plugin, deploy an MTA with cf deploy, monitor progress with cf mta-ops, resume a failed deploy, use --no-start for staged deployments, and undeploy an MTA. You know the order of operations in a deploy and where to look when something goes wrong.