4.6. Entornos

Una aplicación puede funcionar en diversos entornos. Los diferentes entornos comparten el mismo código PHP (solo es diferente el controlador frontal), pero usan una configuración diferente. Por ejemplo, un entorno de desarrollo dev guarda las advertencias y errores, mientras que un entorno de producción prod sólo registra los errores. Algunos archivos se vuelven a generar en cada petición en el entorno dev (para mayor comodidad de los desarrolladores), pero se cachean en el entorno prod. Todos los entornos se encuentran en la misma máquina y ejecutan la misma aplicación.

Un proyecto Symfony2 normalmente comienza con tres entornos (dev, test y prod), aunque resulta sencillo crear nuevos entornos. Puedes ver tu aplicación en diferentes entornos con sólo cambiar el controlador frontal en tu navegador. Para ver la aplicación en el entorno dev, accede a la aplicación a través del controlador frontal de desarrollo:

http://localhost/app_dev.php/hello/Ryan

Si deseas ver cómo se comportará tu aplicación en el entorno de producción, utiliza en su lugar el controlador frontal prod:

http://localhost/app.php/hello/Ryan

Como el entorno prod está optimizado para ser muy rápido, la configuración, el enrutamiento y las plantillas Twig se compilan en clases PHP simples y se guardan en caché.

Si haces cualquier cambio en las plantillas, no lo verás en el entorno prod a menos que borres la cache de la aplicación y así fuerces a Symfony a volver a compilar las plantillas. Para borrar la cache del entorno de producción, ejecuta el siguiente comando de consola:

php app/console cache:clear --env=prod --no-debug

$kernel = new AppKernel('prod', false);

4.6.1. Configurando entornos

La clase AppKernel es realmente la responsable de cargar el archivo de configuración según el controlador que utilices:

// app/AppKernel.php
public function registerContainerConfiguration(LoaderInterface $loader)
{
    $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');
}

Ya sabes que la extensión .yml se puede cambiar a .xml o .php si prefieres usar XML o PHP para escribir tu configuración. Además, observa que cada entorno carga su propio archivo de configuración. Considera el archivo de configuración para el entorno dev.

# app/config/config_dev.yml
imports:
    - { resource: config.yml }

framework:
    router:   { resource: "%kernel.root_dir%/config/routing_dev.yml" }
    profiler: { only_exceptions: false }

# ...

<!-- app/config/config_dev.xml -->
<imports>
    <import resource="config.xml" />
</imports>

<framework:config>
    <framework:router
        resource="%kernel.root_dir%/config/routing_dev.xml"
    />
    <framework:profiler only-exceptions="false" />
</framework:config>

<!-- ... -->

// app/config/config_dev.php
$loader->import('config.php');

$container->loadFromExtension('framework', array(
    'router'   => array(
        'resource' => '%kernel.root_dir%/config/routing_dev.php'
    ),
    'profiler' => array('only-exceptions' => false),
));

// ...

La clave imports es similar a una declaración include de PHP y garantiza que en primer lugar se carga el archivo de configuración principal (config.yml). El resto del archivo de configuración predeterminado simplemente aumenta el número de eventos que se registran en el log y realiza otros ajustes útiles para un entorno de desarrollo.

Ambos entornos (prod y test) siguen el mismo modelo: cada uno importa el archivo de configuración básico y luego modifica sus valores de configuración para adaptarlos a las necesidades específicas del entorno. Esto es sólo una convención, pero te permite reutilizar la mayor parte de tu configuración y personalizar sólo algunas opciones específicas.