Prepare a compatible release

A deployable API reads configuration from its environment, reports health, stops gracefully, and changes its contract deliberately.

Validate required configuration at startup. On shutdown, stop accepting new traffic and finish or time out active work. Prefer additive contract changes; when a breaking change is unavoidable, publish a clear migration and version boundary.

Separate liveness from readiness. Liveness answers whether the process can run; readiness answers whether this instance should receive traffic after configuration and required dependencies are available. Keep both cheap and avoid making health probes mutate data. During SIGTERM, fail readiness first, stop new connections, allow bounded active work to finish, close the database, then exit with evidence if the deadline is exceeded.

A code rollback does not undo schema changes or external effects. Use expand-and-contract migrations so old and new versions overlap safely, and keep the previous artifact plus its configuration requirements known. The release record should name the source version, migration state, OpenAPI version, smoke requests, logs to watch, rollback trigger, and owner. Have another person execute the checklist before calling it operational.

Add health and readiness routes, graceful signal handling, an example environment file, OpenAPI output, and a release checklist.