Chapter 22
Migrations

Rails encourages an agile, iterative style of development. We don’t expect to get everything right the first time. Instead, we write tests and interact with our customers to refine our understanding as we go.

For that to work, we need a supporting set of practices. We write tests to help us design our interfaces and to act as a safety net when we change things, and we use version control to store our application’s source files, allowing us to undo mistakes and to monitor what changes day to day.

But there’s another area of the application that changes, an area that we can’t directly manage using version control. The database schema in a Rails application constantly evolves as we progress through the development: we add a table here, rename a column there, and so on. The database changes in step with the application’s code.

With Rails, each of those steps is made possible through the use of a migration. You saw this in use throughout the development of the Depot application, starting when we created the first products table in ​Generating the Scaffold​, and when we performed such tasks as adding a quantity to the line_items table in ​Iteration E1: Creating a Smarter Cart​. Now it’s time to dig deeper into how migrations work and what else you can do with them.