5.3. Environments

During the course of application development, you will probably need to keep several sets of configuration in parallel. For instance, you will need to have the connection settings for your tests database available during development, and the ones for your real data available for production. To answer the need of concurrent configurations, symfony offers different environments.

5.3.1. What Is an Environment?

An application can run in various environments. The different environments share the same PHP code (apart from the front controller), but can have completely different configurations. For each application, symfony provides three default environments: production (prod), test (test), and development (dev). You're also free to add as many custom environments as you wish.

So basically, environments and configuration are synonyms. For instance, a test environment will log alerts and errors, while a prod environment will only log errors. Cache acceleration is often deactivated in the dev environment, but activated in the test and prod environments. The dev and test environments may need test data, stored in a database distinct from the one used in the production environment. So the database configuration will be different between the two environments. All environments can live together on the same machine, although a production server generally contains only the prod environment.

In the dev environment, the logging and debugging settings are all enabled, since maintenance is more important than performance. On the contrary, the prod environment has settings optimized for performance by default, so the production configuration turns off many features. A good rule of thumb is to navigate in the development environment until you are satisfied with the feature you are working on, and then switch to the production environment to check its speed.

The test environment differs from the dev and prod environment in other ways. You interact with this environment solely through the command line for the purpose of functional testing and batch scripting. Consequently, the test environment is close to the production one, but it is not accessed through a web browser. It simulates the use of cookies and other HTTP specific components.

To change the environment in which you're browsing your application, just change the front controller. Until now, you have seen only the development environment, since the URLs used in the example called the development front controller:

http://localhost/frontend_dev.php/mymodule/index

However, if you want to see how the application reacts in production, call the production front controller instead:

http://localhost/index.php/mymodule/index

If your web server has mod_rewrite enabled, you can even use the custom symfony rewriting rules, written in web/.htaccess. They define the production front controller as the default execution script and allow for URLs like this:

http://localhost/mymodule/index

http://localhost/frontend_dev.php/mymodule/index
            _________ _______________
             server     environment

5.3.2. Configuration Cascade

The same setting can be defined more than once, in different places. For instance, you may want to set the mime-type of your pages to text/html for all of the application, except for the pages of an rss module, which will need a text/xml mime-type. Symfony gives you the ability to write the first setting in frontend/config/view.yml and the second in frontend/modules/rss/config/view.yml. The configuration system knows that a setting defined at the module level must override a setting defined at the application level.

In fact, there are several configuration levels in symfony:

• Granularity levels:
  • The default configuration located in the framework
  • The global configuration for the whole project (in myproject/config/)
  • The local configuration for an application of the project (in myproject/apps/frontend/config/)
  • The local configuration restricted to a module (in myproject/apps/frontend/modules/mymodule/config/)
• Environment levels:
  • Specific to one environment
  • For all environments

Of all the properties that can be customized, many are environment-dependent. Consequently, many YAML configuration files are divided by environment, plus a tail section for all environments. The result is that typical symfony configuration looks like Listing 5-12.

Listing 5-12 - The Structure of Symfony Configuration Files

# Production environment settings
prod:
  ...

# Development environment settings
dev:
  ...

# Test environment settings
test:
  ...

# Custom environment settings
myenv:
  ...

# Settings for all environments
all:
  ...

In addition, the framework itself defines default values in files that are not located in the project tree structure, but in the $sf_symfony_lib_dir/config/config/ directory of your symfony installation. The default configuration is set in these files as shown in Listing 5-13. These settings are inherited by all applications.

Listing 5-13 - The Default Configuration, in $sf_symfony_lib_dir/config/config/settings.yml

# Default settings:
 default:
   default_module:         default
   default_action:         index
   ...

These default definitions are repeated in the project, application, and module configuration files as comments, as shown in Listing 5-14, so that you know that some parameters are defined by default and that they can be modified.

Listing 5-14 - The Default Configuration, Repeated for Information, in frontend/config/settings.yml

#all:
#  default_module:         default
#  default_action:         index
#...

This means that a property can be defined several times, and the actual value results from a definition cascade. A parameter definition in a named environment has precedence over the same parameter definition for all environments, which has precedence over a definition in the default configuration. A parameter definition at the module level has precedence over the same parameter definition at the application level, which has precedence over a definition at the project level. This can be wrapped up in the following priority list:

1. Module
2. Application
3. Project
4. Specific environment
5. All environments
6. Default