Deploy with --strategy blue-green, test the green version, switch traffic atomically, and roll back when needed.
Standard cf deploy restarts your application — there is a gap where new instances are starting but old ones are gone. For enterprise apps that users access during business hours, even a 30-second gap causes errors. Blue-green deployment keeps the old version (blue) running while the new version (green) starts, then switches traffic atomically. If green fails, you route back to blue with one command.
CF uses routes to direct traffic. In a blue-green deploy:
Before:
myapp.cfapps.eu10.hana.ondemand.com → [Blue v1.0]
During:
myapp.cfapps.eu10.hana.ondemand.com → [Blue v1.0] (still serving)
myapp-green.cfapps.eu10.hana.ondemand.com → [Green v1.1] (smoke testing)
After switch:
myapp.cfapps.eu10.hana.ondemand.com → [Green v1.1] (live)
# Build the new version
mbt build -t ./
# Deploy with blue-green strategy
cf deploy my-cap-app_1.1.0.mtar --strategy blue-green
The plugin:
1. Deploys new modules as my-cap-app-srv-idle with a temporary route
2. Pauses for you to run smoke tests
3. Asks for confirmation before switching routes
4. Deletes the old modules after confirmation
After cf deploy --strategy blue-green pauses, the green version has a temporary route:
my-cap-app-srv-idle.cfapps.eu10.hana.ondemand.com
Run your smoke tests:
# API health check
curl -s https://my-cap-app-srv-idle.cfapps.eu10.hana.ondemand.com/api/health
# Run your smoke test suite
npm run test:smoke -- --url=https://my-cap-app-srv-idle.cfapps.eu10.hana.ondemand.com
Then confirm the switch:
cf resume-mta-op -i <operation-id>
# .github/workflows/deploy.yml
- name: Deploy (blue-green)
run: |
cf deploy my-cap-app_${{ env.VERSION }}.mtar \
--strategy blue-green \
--no-confirm # auto-confirm after smoke tests
- name: Smoke tests
run: npm run test:smoke -- --url=${{ env.GREEN_URL }}
With --no-confirm the switch happens automatically. Use only if your smoke tests are reliable.
Blue and green both use the same HANA HDI container. During the traffic switch, both versions run simultaneously. Your schema migrations must be backward-compatible:
| Safe | Unsafe |
|---|---|
| Add a nullable column | Drop a column still used by blue |
| Add a new table | Rename a column |
| Add an index | Change a column type narrowly |
| Add a nullable FK | Remove a NOT NULL constraint that blue writes |
Migration strategy:
1. Expand: add new columns/tables (both blue and green can coexist)
2. Switch traffic to green
3. Contract: drop old columns in a separate follow-up deploy (blue is gone now)
If green has problems after the switch:
# The old blue version is still stopped (not deleted yet in default strategy)
# Start it and remap the route manually
cf start my-cap-app-srv-old
cf map-route my-cap-app-srv-old cfapps.eu10.hana.ondemand.com --hostname myapp
cf unmap-route my-cap-app-srv cfapps.eu10.hana.ondemand.com --hostname myapp
Or re-deploy the previous .mtar:
cf deploy my-cap-app_1.0.0.mtar
| Mistake | Fix |
|---|---|
| Destructive schema changes during blue-green | Use expand/contract migration pattern |
| Not running smoke tests before confirming switch | Always test the green URL before resuming |
Using --no-confirm in production without reliable smoke tests |
Gate on test results; a bad auto-confirm is a real outage |
| Forgetting to map routes after a manual rollback | Verify route mapping with cf routes |
| Blue-green with singleton stateful services | Identify stateful parts (queues, sessions) and handle separately |
You can deploy an MTA with --strategy blue-green, test the green version via its temporary route, confirm the traffic switch, apply backward-compatible schema migrations during a live switch, and roll back to blue when green has issues.