Home/ Questions/Q 945275
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T22:43:36+00:00

I am trying to deploy my first rails app and struggling a bit. My

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0