Staged Deployments
sam-scolari
PROOP

10 months ago

Problem

I find myself needing to make frequent changes to services that rely on each other, and this leads to unnecessary downtime.

Context
For example, I have a web app that pulls from a Postgres database. Whenever I need to make a migration to the database schema, I also need to update the web app codebase.

Because the database and web app are separate instances, I cannot ensure that the changes apply at the same time. This means my web app will experience downtime as the new changes rebuild and redeploy to my Railway service.

Even though my database migrations often take only a few seconds, the downtime can take at least 10 minutes and sometimes much longer when Railway is experiencing delayed placements.

Solution
Allow users to mark new deployments as "Staged" such that instead of replacing the current active deployment they deploy to a separate instance in the background until manually promoted to the "Active" state. Once the user makes the necessary changes to the external service, they can instantly hot swap in the new deployment that was staged.

This would reduce the required downtime my web app experiences by over 90% because I can have the new deployment ready to go and not beholden to the Railway deployment queue.

Under Review

0 Threads mention this feature

1 Replies

sam-scolari
PROOP

10 months ago

Brought to you by this 1 line commit that is still deploying and has caused my app to experience over 30min of downtime on a migration that took me 5 seconds... 🫠

https://github.com/nouns-esports/nouns-gg/commit/550a33a8b9e798d3df2323f035936acc4b8ea2f9


Loading...