rails deployment question

Question

I am trying to deploy my first rails app and struggling a bit. My plan is to initially host it on a heroku free account to get a feel for live deployments and do some production testing. Eventually I might move it to a VPS.

I use git and do not use Capistrano at the moment.

Heroku primarily uses git, which is fine, but git manages the entire project state not files. So I have issues managing configuration files that are different from production to development, for example captcha keys in the environment.rb or goolge js api keys. So what I did was to..

1 - Take the environment specific configuration out of the enviornment.rb and put it in the development.rb and production.rb. Created a branch called dev where I do my development and then merge it with master and push master to the production heroku remote.

This all works ok, but wondering if there is a better way to do it.

The other massive problem is I might have to use different gems in dev and in herouku. For example, I use ThinkingSphinix for search in dev, but Heroku I have to use acts_as_solr, which means my "Article.search call in the controller, will have to be Article.find_by_solr in production. This can become messy very fast.

What's the best way to deal with this kind of situation?

Thanks

Answer 1

For non-sensitive keys such as Google's JS API key etc., I found this RailsCasts episode very helpful.

Just created a config file under config/ and store your development settings in there.

# /config/google.yml
development:
  google:
    js:
      key: 123456

test:
  google:
    js:
      key: 345678

production:
  google:
    js:
      key: 567890

Then create an initializer inside config/initializers/ that will parse the yaml and create an object which can be used without worrying about the current environment.

# /config/initializers/google.rb
GOOGLE_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/google.yml")[RAILS_ENV]

The environment variable RAILS_ENV refers to the current environment, so on application startup it picks up the current type, and you can refer to the settings in your code through GOOGLE_CONFIG:

<script type="text/javascript" src="http://www.google.com/jsapi?key=&lt;%= GOOGLE_CONFIG['js']['key'] %>"></script>

For the latter issue, where code itself differs from environment to environment, I believe Capistrano would be a better solution.

Answer 2

I would suggest that it is very unwise to have different code in development and production. Your development, test and production environments should be as similar as possible. In fact, I would go so far as to say the entire point of the different environments is to simply provide an easy system for allowing minor configuration changes between setups. Different databases, different API parameters, different aching options, but the core system MUST be the same.

The the issue you will face is doubling your development effort. You still have to write the code. So in the search example you provide above, you will have to develop and test twice - once for the Solr production system and once for you local Sphinx, then you need to be able to switch and test between the two approaches in all of your environments to ensure test coverage and functionality.

Answer 3

For values that you want to keep different between environments, Heroku offers config vars.

As for using one indexing program in production and another in development, that's a bad idea, and will make things way messier than they need to be. Either start using Solr locally, or set up a Thinking Sphinx instance in EC2 yourself, and have your dynos connect to it.