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: