Promotion and rollback

Stage 5 · Payload Integration

Releasing software across environments requires promoting the exact same container artifact while varying configuration parameters.

Conversely, rolling back a deployment reverts desired manifest declarations, but cannot reverse runtime side effects.

Promoting immutable artifacts across environments

Diagram DL-06 — promotion carries the identical artifact forward while overlaying environment-specific configurations.

What stays identical: The container image digest. Do not rebuild images per environment.
What varies: Replica counts, resource allocations, domain hostnames, and ingress TLS certificates.

Diagram DL-07 — the Pod template returns to the previous version; external database mutations and third-party API calls remain in place.

What rollback changes:
- Restores previous spec.template in the Deployment object.
- Scales up the previous ReplicaSet.
- Switches Service endpoints back to the old version.
What rollback CANNOT undo:
- Database schema mutations or written records.
- Emails, push notifications, or SMS sent to passengers.
- External credit card charges and payment authorizations.
- Messages consumed from asynchronous message brokers.

To prevent rollbacks from crashing when databases change:

1. Expand: Apply backwards-compatible database migrations (add nullable columns). Both old and new code can read the database.
2. Deploy: Roll out new application version.
3. Verify: Monitor error budgets and traffic health.
4. Contract: Drop legacy fields only after the new version is verified stable.

1. Active rollout status:

kubectl rollout status deployment/booking -n apollo-airlines-apps

2. Live endpoint verification:

kubectl get endpoints booking -n apollo-airlines-apps

3. Check release history:

helm history apollo-airlines -n apollo-airlines-apps