Production Deployment

biblio-api works: the catalog is exposed, validated, secured, documented, tested, and optimized. What remains is the stage where you discover that "works on my machine" and "works in production" are two different properties, and that the second cannot be deduced from the first.

The failures of a first deployment are always the same, and none of them is a code bug. A database password committed six months earlier and still valid. A ddl-auto: update left in the active profile, which adds a column to the production table on first startup. A container restarted in a loop by the orchestrator because the readiness probe queries an endpoint that responds before the application is ready. An update that cuts off in-flight requests because the process is killed without warning. Unreadable logs, where three instances write at the same time and there is no way to connect the lines belonging to a single request.

These five problems have one thing in common: they are fixed through configuration, before the first deployment, and become far more expensive afterward. That is what this final lesson addresses.