6

I am deploying the production environment of my ruby on rails application with the capistrano gem onto a virtual private server. I run the following command to deploy: 

bundle exec cap production deploy

All seems to be working well unless I try to check what environment my current production release is operating in.

One way I use to check this is to run:

rails console
Rails.env

The answer I receive is "development" which is quite frightening.

During another test: when I run the following in my current release:

rails db

I get an error that states that mydatabase_development is not created.

My application seems to be running well but I do not know if this will cause major problems moving forward. First of all: Is there a way to determine if I my live copy is actually running in development? Secondly: Given that I have a problem, how do I configure capistrano to deploy a production environment?

hec
  • 569
  • 1
  • 6
  • 12
  • Which system are you running `rails console` on? – tadman Jun 04 '14 at 21:32
  • Running `rails console` on the VPS which has a Ubuntu 14.04 distribution installed. The directory in which I run the command is: `/var/www/myapp/current/` – hec Jun 05 '14 at 07:45

1 Answers1

7

Keep in mind that rails console engages in the current environment as dictated by RAILS_ENV or RACK_ENV in your environment. If you don't set up this explicitly on your server then it will probably default to development.

One way to fix this is to force it in your .bash_profile or whatever shell profile you're using. For example:

export RAILS_ENV=production

That should make it available and when you engage your Rails shell it'll kick in properly.

As a note, you shouldn't even be able to start in development mode on your production server since there shouldn't be an entry with that name in config/database.yml. A best practice is to store config/database.yml only on the production server and move it over during your Capistrano deploy.

Add this to your config/deploy.rb:

set :linked_files, %w[
  config/database.yml
]

Then you create a production only config in shared/config/database.yml that will be linked into place when you deploy. Be sure to exclude config/database.yml from your version control system so it doesn't get deployed.

The reason your site is probably okay is because a launcher like Passenger automatically sets RACK_ENV to production unless otherwise configured. This does not impact your shell, though, which defaults to development.

tadman
  • 208,517
  • 23
  • 234
  • 262
  • Brilliant answer tadman. Thanks. Do I need to do the same with my `config/application.yml` file (used for environmental variables by the figaro gem) as with the `config/database.yml` file? – hec Jun 05 '14 at 08:04
  • It's generally a bad idea to check things like API keys, credentials, passwords and such into your source code repository. Stuff like that should be stored securely on your server, and only on your server, apart from safe backups. Usually I make a `config/database.example.yml` file that serves as a template each developer can customize. Same goes for other things like `application.yml` if you have one. – tadman Jun 05 '14 at 15:20