Production environment configuration in Ruby on Rails - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to set the Rails environment to production.

Ruby on Rails

Rails.env = '[1]'

Drag options to blanks, or click blank then click option'

Astaging

Bdevelopment

Ctest

Dproduction

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'development' instead of 'production'

Capitalizing 'Production' incorrectly

Setting Rails.env to production configures the app to run in production mode.

2fill in blank

medium

Complete the code to enable class caching in production.

Ruby on Rails

config.cache_classes = [1]

Drag options to blanks, or click blank then click option'

Afalse

Btrue

Cnil

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Setting cache_classes to false in production

Using nil instead of true or false

In production, cache_classes should be true to improve performance by not reloading classes.

3fill in blank

hard

Fix the error in the code to serve static files in production.

Ruby on Rails

config.public_file_server.enabled = [1]

Drag options to blanks, or click blank then click option'

Atrue

Bfalse

Cnil

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Setting enabled to false disables static file serving

Using nil or 0 instead of true or false

Setting public_file_server.enabled to true allows Rails to serve static files in production.

4fill in blank

hard

Fill both blanks to configure log level and eager loading in production.

Ruby on Rails

config.log_level = :[1]
config.eager_load = [2]

Drag options to blanks, or click blank then click option'

Adebug

Binfo

Ctrue

Dfalse

Attempts:

3 left

💡 Hint

Common Mistakes

Using :debug log level in production

Setting eager_load to false in production

Production uses :info log level for balanced logging and true for eager loading to load all code on boot.

5fill in blank

hard

Fill all three blanks to configure asset compilation and error reporting in production.

Ruby on Rails

config.assets.compile = [1]
config.consider_all_requests_local = [2]
config.action_controller.perform_caching = [3]

Drag options to blanks, or click blank then click option'

Atrue

Bfalse

Cnil

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Setting assets.compile to true in production

Showing full error reports in production

Disabling caching in production

In production, assets should not compile on the fly (false), error reports should be hidden (false), and caching should be enabled (true) for performance.

Practice

1. What is the main purpose of the production.rb file in a Rails application?

easy

A. To define routes for the application

B. To enable detailed error messages for debugging

C. To configure settings that optimize the app for real users, like caching and security

D. To set up the database schema

Solution

1. Step 1: Understand the role of production.rb

   This file holds configuration settings specifically for the production environment, where the app serves real users.

2. Step 2: Identify key production settings

   It disables detailed error messages and enables caching to improve speed and security.

3. Final Answer:

   To configure settings that optimize the app for real users, like caching and security -> Option C

4. Quick Check:

   Production config = optimize for real users [OK]

Hint: Production config = speed + security settings [OK]

Common Mistakes:

• Confusing production with development environment
• Thinking production shows detailed errors
• Mixing routing or database setup with production config

2. Which line correctly disables full error reports in config/environments/production.rb?

easy

A. config.consider_all_requests_local = false

B. config.show_detailed_errors = true

C. config.consider_all_requests_local = true

D. config.show_detailed_errors = false

Solution

1. Step 1: Identify the setting for error reports

   The setting consider_all_requests_local controls whether detailed error pages show.

2. Step 2: Know production default

   In production, this is set to false to hide detailed errors from users.

3. Final Answer:

   config.consider_all_requests_local = false -> Option A

4. Quick Check:

   Disable detailed errors = false [OK]

Hint: False hides errors in production [OK]

Common Mistakes:

• Setting it to true shows errors in production
• Using wrong config key like show_detailed_errors
• Confusing development and production defaults

3. Given this snippet in production.rb:

config.cache_classes = true
config.action_controller.perform_caching = true
config.assets.compile = false

What happens if you deploy without precompiling assets?

medium

A. The app will crash with a syntax error

B. Rails will compile assets on the fly, slowing down requests

C. Assets will be served normally from the public folder

D. Assets will not be served, causing missing styles and scripts

Solution

1. Step 1: Understand config.assets.compile = false

   This setting disables on-the-fly asset compilation in production.

2. Step 2: Consequence of no precompiled assets

   If assets are not precompiled, Rails cannot serve them, so styles and scripts will be missing.

3. Final Answer:

   Assets will not be served, causing missing styles and scripts -> Option D

4. Quick Check:

   No precompile + compile false = missing assets [OK]

Hint: No precompile + compile false = missing assets [OK]

Common Mistakes:

• Assuming Rails compiles assets automatically in production
• Thinking assets serve normally without precompile
• Confusing compile false with true

4. You see this error in production: ActionController::RoutingError (No route matches [GET] "/assets/application.css"). Which fix is correct?

medium

A. Precompile assets before deploying and keep config.assets.compile = false

B. Set config.assets.compile = true in production.rb

C. Remove caching settings from production.rb

D. Set config.consider_all_requests_local = true

Solution

1. Step 1: Understand the error cause

   The error means the CSS asset is missing in production, likely because assets were not precompiled.

2. Step 2: Correct fix for missing assets

   Best practice is to precompile assets before deployment and keep config.assets.compile = false for performance.

3. Final Answer:

   Precompile assets before deploying and keep config.assets.compile = false -> Option A

4. Quick Check:

   Missing assets fix = precompile + compile false [OK]

Hint: Always precompile assets for production [OK]

Common Mistakes:

• Setting compile true causes slow requests
• Removing caching does not fix missing assets
• Enabling detailed errors leaks info in production

5. You want to securely configure your Rails app for production to use environment variables for secrets and enable caching. Which combination in production.rb is best practice?

hard

A. config.cache_classes = false
config.action_controller.perform_caching = false
config.secret_key_base = ENV['SECRET_KEY_BASE']

B. config.cache_classes = true
config.action_controller.perform_caching = true
config.secret_key_base = ENV['SECRET_KEY_BASE']

C. config.cache_classes = true
config.action_controller.perform_caching = false
config.secret_key_base = 'hardcoded_secret'

D. config.cache_classes = false
config.action_controller.perform_caching = true
config.secret_key_base = 'hardcoded_secret'

Solution

1. Step 1: Identify caching and class loading best practices

   In production, cache_classes and perform_caching should be true for speed and efficiency.

2. Step 2: Use environment variables for secrets

   Secrets like secret_key_base must come from environment variables, not hardcoded strings, for security.

3. Final Answer:

   config.cache_classes = true config.action_controller.perform_caching = true config.secret_key_base = ENV['SECRET_KEY_BASE'] -> Option B

4. Quick Check:

   Caching true + env secrets = secure production [OK]

Hint: Cache true + env secrets = secure production [OK]

Common Mistakes:

• Disabling caching in production
• Hardcoding secret keys in code
• Setting cache_classes false reduces performance