README.md in good_migrations-0.0.1 vs README.md in good_migrations-0.0.2

- old
+ new

@@ -1,10 +1,13 @@ # good_migrations -**tl;dr: prevent loading app code from migrations by adding `good_migrations` to -your Gemfile** +[![Build Status](https://travis-ci.org/testdouble/good-migrations.svg?branch=master)](https://travis-ci.org/testdouble/good-migrations) +This gem prevents Rails from auto-loading app code while it's running migrations, +preventing the common mistake of referencing ActiveRecord models from migration +code. + ## Usage Add good_migrations to your gemfile: ``` ruby @@ -28,21 +31,24 @@ That means that if your migrations reference the ActiveRecord model objects you've defined in `app/models`, your old migrations are likely to break. That's not good. -By adding this gem to your project's `Gemfile`, autoloading paths inside 'app/` +By adding this gem to your project's `Gemfile`, autoloading paths inside `'app/'` while running any of the `db:migrate` Rake tasks will raise an error, explaining the dangers inherent. Some will reply, "who cares if old migrations are broken? I can still run `rake -db:setup` because I have a `db/schema.rb file". The problem with this approach +db:setup` because I have a `db/schema.rb` file". The problem with this approach is that, so long as some migrations aren't runnable, the `db/schema.rb` can't be regenerated from scratch and its veracity can no longer be trusted. In practice, we've seen numerous projects accumulate cruft in `db/schema.rb` as the result of erroneous commits to work-in-progress migrations, leading to the development and test databases falling out of sync with production. That's not good! + +For more background, see the last section of this blog post on [healthy migration +habits](http://blog.testdouble.com/posts/2014-11-04-healthy-migration-habits.html) ## Options There's no public API to this gem. If you want to work around its behavior, you have a few options: