Deployment on Brian Faust

Rollback Cannot Restore a Contract You Already Removed

Wed, 01 Oct 2025 00:00:00 +0000

Release A stores a catalogue quote in amount_cents. Release B renames the column to amount_minor and deploys successfully. Every new B process is healthy.

One A process is still serving traffic during the rolling update. Its next query asks PostgreSQL for amount_cents and fails because the column no longer exists. Restoring the A image produces the same error. The old code returned; the contract it needs did not.

The same failure can survive in less visible places. An A queue worker can receive a B-only payload after the web rollout. An A process can read a B-only cache value after the application image is restored. Neither queued bytes nor cached bytes change because a deployment controller selected an older image.

Cache the Deployment, Not the Assumption

Sun, 01 Dec 2024 00:00:00 +0000

Release B serves /inventory and labels its catalogue green. The code is correct. The environment is correct. Yet the application answers /catalogue with blue, while /inventory returns 404.

Nothing corrupted Laravel’s generated files. They contain release A’s configuration and route table because release A created them. The deployment combined those files with release B and produced a system which is consistently wrong.

config:cache and route:cache are often introduced as performance switches. That description misses their more important property: each command turns a set of inputs into a generated artifact. If the artifact is deployed, it must carry the same release identity as the code and environment which produced it.