Database migrations are where many clean deployment diagrams become real production risk. The application can build, the image can publish, and the deploy can still leave users with a half-upgraded system.
WebKD is a good example because access-control software is not tolerant of ambiguous rollout state. Operators need the API, frontend, data model, permissions behavior, reports, and device communication to agree with each other.
CloudFloo treats migrations as release gates. A Helm chart can run a migration Job before backend pods become ready. Backend pods can wait in an init container until that migration succeeds. Readiness probes can keep traffic away from pods that are not safe to serve.
This pattern is not glamorous, but it is valuable. It makes the rollout sequence explicit: build what changed, publish images, run migration, wait for success, start backend pods, pass probes, expose traffic.
A practical deployment script also handles failed state. Stuck migration jobs, old hooks, partial rollouts, and retry behavior need names and cleanup paths. Otherwise the second deploy is often more dangerous than the first.
Nx affected builds add another layer of control. In a monorepo, not every change should rebuild every service. Affected builds make the delivery path faster while still keeping the release graph visible.
The buyer lesson: ask your vendor what happens when the migration fails. If the answer is only "we rerun deploy," the release system is not mature enough for operational software.