Live-ing Dangerously With Rails
Recently at work, we’ve been spinning up a bunch of demo apps on Heroku. This has worked out well for us so far. However, some of these apps require background data crunching. This hasn’t been a problem as we just add a Rake task, or two, and set the Heroku scheduler to take care of things.
Then comes the day when the sales team says:
“Oh hey. Can we re-run all the numbers but with different configurations?”
Sure, that’s not a problem you think:
1
|
|
However, there’s a few issues with this:
- The
config.yml
needs to be on Heroku - This counts against your active dyno time
See the thing is, Heroku doesn’t let you create files that aren’t already in your VC system from outside the app. It’s now sorta possible on Cedar, but not really for this purpose.
Additionally, if these tasks turn out to be long running, that’ll quickly eat up the overhead on the ‘free’ dyno. For demo apps of non-paying customers that’s not always an option.
Enter the live
environment.
Just add a new live
environment to the Rails application. This allows us to
run Rake locally, but against the production database. Additionally, allowing
for custom configuration files to just be stored on our local system. And we
don’t spin up a new dyno on Heroku. Win, win!
To set this up:
- Update the
Gemfile
1 2 3 4 5 |
|
- Add the live specific sample file:
.env.live-example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
- Update the
database.yml
file
1 2 3 4 5 6 7 8 9 10 |
|
- Copy
config/environments/production.rb
toconfig/environments/live.rb
. If you wish to symlink it instead be wary of how git treats that.
Now running our tasks is as simple as:
1
|
|