Codefol.io

Interested in taking your Rails migration code to the next level? Welcome. You’re in the right place.

What’s that? Somebody in the back says they’re not already up on the basics? No problem. The Rails Guide on migrations is like most Rails guides – pretty darn awesome. It’ll have you adding tables, dropping columns and altering multi-column indices before you know it.

For the rest of you who know the basics, let’s learn what awesome Rails programmers already know about migrations.

Downtime

Migrations can bring down a busy site in a hurry. Many things you do in a migration will lock the table you’re touching, which will block every SQL query and every Rails route that touches that table, sometimes for minutes or hours. You can’t “scale” your way out of it – you only get one database, and it’s locked for all app servers.

database

A question you’ll occasionally see: when do you run your migrations in production? There’s a standard answer, so let’s talk about it.

The Answer

You’ll run your migrations before you deploy new code. In general, that means “every time you push code to production, you run all the migrations since the last time you pushed code to production. Do it before you replace the old code.”

Easy enough. Why?

First, because that’s the order you think about things. If you’re adding a new column to a table, you’ll want to make your code use it. If you run the migration first, that all works out nicely.

database

Migrations can be tricky, and it’s time-consuming to test them properly. One answer is to have other people look over your code.

In addition to the checks you can enforce with automated tools, there are a lot of things a human should look over. Let’s talk about some of the rules for code reviewing a migration that aren’t covered by the Good Migrations or Strong Migrations tools.

Keep Each Migration Small

Small migrations are (usually) happy migrations. It can be hard to roll back migrations, especially when they modify large tables. If your database supports rolling back schema changes at all, it can still take minutes or hours to do. Even a large, hard-to-divide operation like adding a column to a two-terabyte table is happiest if it’s mostly done by itself.

database

Remember that problem I had writing migration code where the whole site went down? Turns out I could have fixed that in advance by just following best practices for migrations.

There are several libraries meant to help you follow migration best practices. Two of them are “Good Migrations” and “Strong...

database

As I look into database migration dangers for (edited to add: now defunct) a book I’m working on, I find a lot of great existing stuff that I had no idea existed.

Thanks, guys!

Andrew Kane of Instacart has a bunch of wonderful guides, including one on “strong migrations” — migrations that run without downtime on MySQL and Postgres. It sums up some wonderful previous articles about downtime-free migrations on Postgres with high data volume, how to create indices without downtime on Postgres, and no-downtime migrations in general.

database

Back when I worked at On-Site, years ago, I screwed something up in my code. I discovered it when everything stopped working in production.

Oops.

By “everything” I mean “nearly every action a user could take would just hang.” So that’s not great.

But I learned something important about database migrations. And that’s nearly as good as not crashing production, right?

Right?

I’ll tell you what happened with me and crashing our servers, but first let’s talk about database migrations.

database