I think given how the question was asked, I will recommend reviewing 12factor.net and if you could deliberate each point with personal experience.

Otherwise make the decision based on the trade-offs.

“good practice” generally means running migrations that don’t affect your end-users. In some applications that means going into “maintanence mode” (turn app off) in the middle of the night since no one’s using the app at that time, and running migrations. Or it means using some database techniques to avoid any downtime at all, which what I see more often.

The article Safe Eco Recipes is a resource that collects no-downtime migration techniques (thanks com for the reference!). If you’d rather watch a video there’s some of it here: https://m.youtube.com/watch?v=mOeONt6Hkf8

If you’re migrating a table with 10 rows in it, there’s virtually no downtime regardless of you using “good” or “bad” techniques. If you’re migrating a table with 10 million rows you’ll need to consider no-downtime techniques more seriously.

Maybe more important than any of that ^ is having a boot-up process that can successfully run migrations, checking for success, and if success then booting the rest of the app, and lastly shifting traffic to the new nodes. (see part 2 of the Safe Ecto Migrations guide)

It depends on many factors. I think you should Google “migrations and downtime” or something similar.

For example, lets say you want to rename a database column. Well, if you deploy code first, then things will crash because that column doesn’t exist. If you migrate first, well things will still crash because the currently running code will be trying to use the old column.

From personal experience, we’ve mostly opted to let our application crash for 1-2 minutes while we’re deploying/migrating. But if that’s not acceptable, then you gotta do things like deploy defensive code first (that can handle both situations), then migrate, then deploy again to remove the defensive code.