Supporting applications running in production while developing drastic new features or rewrites of existing features can be a huge pain. One of the biggest pains we had on a recent long running feature branch with database changes that made the master and feature branches incompatible. Sure, we could have worked to prevent such incompatibilities, but why add all that extra complexity when there is a simpler way?!
We opted for the low tech solution of just maintaining two database.yml files and swapping them anytime we needed to change branches. Due to the number of fixes and tweaks we were doing based off the released master branch, this quickly became a pain. We thought about scripting up this switch into some git-hooks but that seemed to be much more trouble than it was worth. Finally we realized the obvious, simple solution.
It is easy to overlook the fact that your database.yml file will be processed for Erb before it is used to establish a connection. So by adding a little system call execution to some database.yml Erb, we can easily detect the branch we are on, and determine if it is our feature branch.
common: &COMMON
adapter: mysql2
username: dbuser
password:
host: localhost
<% on_feature = `git branch | grep ‘* feature_awesome’`.present? %>
development:
<<: *COMMON
<% if on_feature %>
database: app_development_feature
<% else %>
database: app_development
<% end %>
test: &TEST
<<: *COMMON
<% if on_feature %>
database: app_test_feature
<% else %>
database: app_test
<% end %>
Thanks to the nice little asterisk that git branch puts on our current branch it is easy to determine if we are on the feature branch, and then make some simple decisions about what database name to set in the YAML file.
Just remember to restart your development server when you change branches so the file is reprocessed!
Check out our other development tips:
Vim Tip: How to Reformat Dates in 7 Steps
Application Development Process Tip: Reverse Ticket Priorities on Friday
