views:

58

answers:

3

Currently, I am using the Development mode for my application, but I don't know if I should use the Production mode. If it is the case, how do i transfer all my data to the Production mode?

Will there be a risk of introducing bugs in this process?

+4  A: 

The difference is between 2 environments. In Rails, there are several environment. Each has his own database configuration and Rails options.

You can use the Rails.env variable to made some different change with particular environment.

By default, the development environment is without all cache and activate the auto-reloading. The production environment is with all cache.

But if you want you can make a production environment like development or development environment like production.

You can add some new specific environment too.

shingara
+1  A: 

Fundamentally, there is no difference between Rails environments. The environment is simply a constant that is set when a Rails application is started and referenced often throughout the boot process and available to the application code.

For instance, the constant defines which database configuration to use for connection and which environment initializer to execute (e.g. config/environments/development.rb) at boot time.

The default environments that exist in a rails application are:

  • development
  • test
  • production

Some configuration options differ between the default Rails environments, but the environments would be identical if the configuration options in the corresponding config/environments/#{environment} files were identical. This is evidenced by the fact that additional environments can be created by adding connection configuration to config/database.yml and a new environment file to config/environments

Patrick Klingemann
+2  A: 

Excerpt from the Agile Development using Rails book

Making Development Easier

You might have noticed something about the development we’ve been doing so far. As we’ve been adding code to our application, we haven’t had to restart the running application. It has been happily chugging away in the background. And yet each change wemake is available whenever we access the application through a browser. What gives?

It turns out that the Rails dispatcher is pretty clever. In development mode (as opposed to testing or production), it automatically reloads application source files when a new request comes along. That way, when we edit our application, the dispatcher makes sure it’s running the most recent changes. This is great for development.

However, this flexibility comes at a cost—it causes a short pause after you enter a URL before the application responds. That’s caused by the dispatcher reloading stuff. For development it’s a price worth paying, but in production it would be unacceptable. Because of this, this feature is disabled for production deployment.

Bragboy