I’m a bit surprised to hear that is the state of migrations in Rails. Being a Django developer I’m used to having most of the points you mention covered for a r

I’m a bit surprised to hear that is the state of migrations in Rails. Being a Django developer I’m used to having most of the points you mention covered for a really long time already. It’s timeless by looking at a captured schema, that doesn’t change with later code changes. Which means you can’t import / use methods of models and have to copy those over. So a different way than using the vcs for this, but still. Not sure I’d name the second point “scalable”, but you can easily do data migrations as well. It is really easy to use! And you can certainly write tests for it, although it isn’t included in the framework [0]. But you can do that with just SQL too [1]. What I find much harder with (somewhat) larger dbs, is is a) determining whether it will lock up too much and b) whether it backwards compatible (so that you can roll back). Which is splitting in these pre- and post-migration steps as the article mentions. We currently use a linter for that but it is still a bit basic [2]. [0] https://www.caktusgroup.com/blog/2016/02/02/writing-unit-tests-django-migrations/ https://www.caktusgroup.com/blog/2016/02/02/writing-unit-tes... [1] https://tapoueh.org/blog/2017/08/sql-regression-tests/ https://tapoueh.org/blog/2017/08/sql-regression-tests/ [2] https://github.com/3YOURMIND/django-migration-linter https://github.com/3YOURMIND/django-migration-linter