I'm curious as to why when I build my project using CruiseControl.rb, it runs it in production mode? Even though my application should not be in production mode. I even tried to specify: ENV['RAILS_ENV'] ||= 'development' in my app's environment.rb
That environment.rb line will only set your environment to development if the environment is not already set.
For information about how they suggest configuring your build environments, see:
Their Manual Entry on the subject
Related
ootb rails has the 3 environments
development
test
production
How do you handle your other environments for example staging ?
When I think about what I want from a staging environment I want most of the production settings, but typically server names and other specific values are different from production.
Do you create 1:N environment/*.rb for each custom environment you have? Or do you treat the environments more as like a profile and then use something like application.yml or secrets.yml for running the application with different server configurations?
What has worked well for you in the past and what has not?
It depends if your "staging" environment is a different thing or is actually a variation on the "production" environment as is usually the case.
Normally you just deploy in full production mode, using the production.rb file and everything, to a non-production server. This distinction is irrelevant to rails, and matters only to your deployment script. For example Capistrano would be concerned about this.
The only time you need another environment is if you need a different group of settings for Rails.
In my opinion, when I run the app in an staging environment I want it to have exactly the same settings as in production, because it's when I check if everything is alright before releasing the new code. So I create a environments/staging.rb that actually is a symbolic link to environments/production.rb. To deploy, I use Capistrano, which lets you define the server settings for every environment you want to. I really encourage you to take a look at it if you don't know it, as it makes deploying as easy as running a simple command, and it takes care of uploading the new code, precompiling the assets, restarting the server, etc.
Appropriate any way described above.
In some cases I am using 1:N way because it easy when you have fixed count of deployment environments (for example when I am deploying own pet-project to remote server).
But in other cases I am using default set of environments (for example when I am deploying project to different customers).
Just choose any way appropriate for you and your project.
I use require_relative to create a staging environment that is identical to production, and then override the parts that are different. Typically the only difference is hostnames.
Here's what my environments/staging.rb looks like:
# Staging configuration is identical to production, with some overrides
# for hostname, etc.
require_relative "./production"
Rails.application.configure do
config.action_mailer.default_url_options = {
:host => "staging.example.com",
:protocol => "https"
}
config.action_mailer.asset_host = "https://staging.example.com"
end
I'm relatively new to Ruby on Rails and occasionally I find this convention-over-configuration stuff a little confusing as a lot of things seemed to be hidden from the developer, as in this case.
I'm using rails 2.3.8 and when I run my app locally through NetBeans 6.9/Mongrel on my system it runs using the development environment parameters.. when I deploy it to a Fedora box and run it there in Apache HTTPD it automatically runs using the production environment parameters.
How does my app know which environment to use? I haven't changed anything in my app to set the environment.. both versions locally and on my Fedora box are identical. I can't find anywhere in the code where it is setting the environment.. so how is this working?
Thanks.
In httpd.conf file, write the following in VirtualHost:-
## Specify Rails Environment here,
default value is "production"
RailsEnv development
Thanks...
The primary way to specify rails mode is RAILS_ENV environment variable (I assume development is default, when nothing is specified). You can check its value in bash, echo $RAILS_ENV.
You can also modify ENV['RAILS_ENV'] in your config file to change the mode:
ENV['RAILS_ENV'] = 'production'
edit
I've never used rails with apache, but I think passenger mod can also specify this variable somewhere, checking apache configs might help.
I have an action which causes an exception in my staging environment, but instead of sending the notification to hoptoad (which it should, the hoptoad test rake task works...), it shows me the standard rails stacktrace page like it does in development.
My staging environment is essentially a copy of my production environment with the only difference being the rails environment being set through passenger.
What could be the cause of this? Where should I be looking? I haven't confirmed that production does the same thing as we don't yet have a proper production environment set up, but I assume it would also act the same way.
Are you sure that your staging instance is running in the correct environment? Have you tried outputting Rails.env somewhere in your views just to make sure?
I only ask because you mentioned seeing a stack trace page, which shouldn't happen in a production environment unless you're making the requests locally, or you have config.action_controller.consider_all_requests_local set to true in your environment config.
After upgrading to rails 2.3.5 I got things working again and the tests were passing. Then all of a sudden when I run the script/server command it now always runs in Test mode which is seen by a simple > puts RAILS_ENV
I have restarted my machine as well as run the script/server command manually setting the environment via -e, but still have no luck.
Does anyone have any idea what the cause of this would be?
** I should note that even when the RAILS_ENV constant is shows up as "test", the database config that is used is the development.
update
by adding puts RAILS_ENV statements throughout the code I can see that when I add a puts outside the Rails::Initializer.run do |config| block within the environment.rb class that at that point the RAILS_ENV becomes set to "test". Right before the end of the block it is still set to development.
The reason for the environment change was that, without thinking, I loaded the rspec gem in the development.rb file.
I have a app that I'm deploying to a development server using Capistrano. I'd like to force this deployment to use the development database. So far the only way I've managed to do it is to make my production database info in database.yml equal to the development info. But this is a complete hack.
I've tried setting rails_env to development in deploy.rb but that hasn't worked.
Thoughts?
I ended up using the solution over here. Basically a recipe to replace a line in environment.rb after deploy but before restart.
The problems seems to be with DreamHost's Passenger config. It assumes you're running in production mode.
I'd use Capistrano Ext in order to define multiple deployment environments. I have used this in the past to deply staging and production installations of my apps, so I think it'd work well for you.
Jamis Buck has a writeup if you'd like an overview on how to use it.