I observe devs in my company bringing back the "schema.rb" file from production into the Git repository.
I am uncertain about this practice. Modifying directly the schema.rb file has consistently been problematic for me. Perhaps it's less of an issue if you solely use schema:load, but I remain skeptical.
I would prefer a re-entering migration to rectify the schema, such as using 'create index if not exists.' This way, changes are propagated across all databases in various environments.
@benoit We actually do pretty much that at Shopify but with a twist.
I should write some rails-at-scale blog post about it, because a committed schema.rb is something that really doesn't scale well with the number of developers.
It constantly conflicts, and devs constantly mess it up with migrations leaking from one feature branch to the other.
@byroot@benoit I live in slight fear that our schema.rb does not actually match our production schema, even though theoretically it should. So this sort of back porting it from production is attractive at least as a sanity/anxiety check
Add comment