You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
They do a really nice thing of running the Rails migrations as a Kubernetes job. That just....makes sense.
Cons of our current setup is
Application is prevented from starting up while migrations are running
^Because of the above long running migrations are pretty dangerous. Those translate to application downtime.
Extra code has to be added to every application.rb
Pros of running it as a job
We can run the migrations before we even tear down old instances of the application meaning no downtime.
Cons of running it as a job
All migrations must be backwards compatible.
You can't remove a column that the application still depends on in a migration because that old instance of the application will still be running. You have to make a migration that adds a new column and changes the code to rely on that new column, then make a new deployment which cleans up the old database column. This is a pretty common paradigm in large scale applications.
The text was updated successfully, but these errors were encountered:
Reading through this article https://www.honeybadger.io/blog/rails-on-kubernetes/.
They do a really nice thing of running the Rails migrations as a Kubernetes job. That just....makes sense.
Cons of our current setup is
application.rb
Pros of running it as a job
Cons of running it as a job
The text was updated successfully, but these errors were encountered: