Apply PostgreSQL migrations with release compatibility checks #8

New issue

Open

opened 2026-11-01 20:11:29 +00:00 by viacheslavshuka · 0 comments

viacheslavshuka commented

2026-11-01 20:11:29 +00:00

Owner

Application-image rollback must remain usable after schema changes. Establish a migration workflow that preserves each replaced production version for seven days.

Scope

Select and configure migration tooling compatible with pooled asyncpg application access. Provide explicit migration commands for development, disposable tests, and deployment. Product issues retain ownership of their domain schemas.

Acceptance criteria

An empty disposable PostgreSQL database reaches the current schema through committed migrations. Repeating the migration command does not reapply completed work.
Migration failures stop deployment preparation. Two concurrent invocations cannot apply the same migration twice or leave a successful migration falsely unrecorded.
The workflow separates additive schema changes, data migration, and destructive cleanup. It records the compatibility expectations needed for deployment and recovery.
A replaced production version remains compatible for seven days after replacement. A later release preserves all compatibility windows that remain active.
Destructive cleanup cannot proceed while an affected compatibility window remains active. Image retention alone does not extend that compatibility guarantee indefinitely.
A previous compatible application can read and write representative data after an additive migration. New writes do not silently violate the previous application's supported representation.
The workflow never restores a database or deletes data as an automatic consequence of image rollback.
PostgreSQL tests apply the real migrations and isolate mutable state across concurrent runs. No SQLite substitute establishes PostgreSQL behavior.

Validation

Use Testcontainers to exercise first application, repeated application, interrupted application, and simultaneous invocations. Demonstrate compatible old/new application access using a representative schema change. Cover the compatibility-window boundary and overlapping windows.

Dependencies

#6: Start the FastAPI runtime with owned database resources. The migration connection configuration must match the application runtime.

#41: Recover failed deployments with a compatible previous image

Application-image rollback must remain usable after schema changes. Establish a migration workflow that preserves each replaced production version for seven days. ## Scope Select and configure migration tooling compatible with pooled asyncpg application access. Provide explicit migration commands for development, disposable tests, and deployment. Product issues retain ownership of their domain schemas. ## Acceptance criteria - An empty disposable PostgreSQL database reaches the current schema through committed migrations. Repeating the migration command does not reapply completed work. - Migration failures stop deployment preparation. Two concurrent invocations cannot apply the same migration twice or leave a successful migration falsely unrecorded. - The workflow separates additive schema changes, data migration, and destructive cleanup. It records the compatibility expectations needed for deployment and recovery. - A replaced production version remains compatible for seven days after replacement. A later release preserves all compatibility windows that remain active. - Destructive cleanup cannot proceed while an affected compatibility window remains active. Image retention alone does not extend that compatibility guarantee indefinitely. - A previous compatible application can read and write representative data after an additive migration. New writes do not silently violate the previous application's supported representation. - The workflow never restores a database or deletes data as an automatic consequence of image rollback. - PostgreSQL tests apply the real migrations and isolate mutable state across concurrent runs. No SQLite substitute establishes PostgreSQL behavior. ## Validation Use Testcontainers to exercise first application, repeated application, interrupted application, and simultaneous invocations. Demonstrate compatible old/new application access using a representative schema change. Cover the compatibility-window boundary and overlapping windows. ## Dependencies - [#6: Start the FastAPI runtime with owned database resources](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/6). The migration connection configuration must match the application runtime. ## Related work - [#41: Recover failed deployments with a compatible previous image](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/41)

viacheslavshuka referenced this issue

2026-11-01 20:11:33 +00:00

Authenticate Telegram users through protected Quorum sessions #14

viacheslavshuka referenced this issue

2026-11-01 20:11:34 +00:00

Enforce Python behavior coverage and mutation checks #15

viacheslavshuka referenced this issue

2026-11-01 20:11:35 +00:00

Run durable PostgreSQL jobs with atomic effects #16

viacheslavshuka referenced this issue

2026-11-01 20:11:51 +00:00

Deploy validated main images to development #34