Comparte en Facebook Twitter Google+

symfony-ambientes-de-desarrollo

Continuando con nuestra serie introductoria, en el post anterior explicamos la estructura de archivos de una aplicación hecha en la distribución estándar, y usamos como ejemplo la app demo de Symfony (esta es una app demo que sirve para aprender como funcionan las cosas en el framework, ademas sirve de ejemplo para las mejores prácticas de desarrollo en Symfony), ahora explicaremos a detalle que son los ambientes de despliegue.

Todos los frameworks de desarrollo web modernos manejan estos ambientes, si ya has usado uno seguro estás familiarizado con ellos, aunque muchas veces dejamos que la herramienta nos ayude mágicamente, por decirlo de alguna manera, y no nos detenemos a ver en detalle cómo funciona esto de los ambientes en los frameworks. Como todo en Symfony, la configuración de los ambientes es muy flexible y fácil de lograr, porque primero que nada un ambiente en Symfony es el set de configuraciones requeridas para desplegar los recursos necesarios para correr la aplicación bajo determinados requerimientos, y todo esto opera sobre el principio de convención sobre configuración que vamos a explicar a continuación.

Symfony viene con dos ambientes de desarrollo por defecto, dev y prod, Symfony detecta estos ambientes en su núcleo, pero los detecta porque el programador pasa como parámetro el ambiente en el que va a trabajar el núcleo, esta instalación se hace en el controlador frontal de nuestra app, que es sólo un script de PHP que levanta los recursos del framework y que está configurado para ser el que reciba todas las peticiones al servidor, esta configuración ya escapa de Symfony y es algo que se tiene que configurar en el servidor que se esté usando para desplegar nuestra aplicación, ya en próximas entregas de la serie tocaremos este tema. Por ahora, veamos los dos controladores frontales que vienen por defecto en la distribución estándar de Symfony.

Primero veamos al archivo app_demo/web/app.php

En la línea 21, podemos ver que se esta instanciando a la clase AppKernel y que el primer parámetro que pasamos al constructor es una cadena de texto mas específicamente ‘prod’ ¿Cómo sé esto? Fácil, revisa el código de la declaración de la clase AppKernel.

¿Ves que extiende o hereda de la clase Kernel?, entonces revisemos el constructor de la clase Kernel, del componente HttpKernel de Symfony.

El primer parámetro que acepta es el ambiente y el segundo es el debug, al que se le hace un cast a booleano, revisen de nuevo la línea 21 del controlador frontal de producción al app.php, ¿Ven que el segundo parámetro es false? Es obvio que en producción no queremos que estén activas esas funciones de debug que nos ayudan en el desarrollo, las cuales muestran información delicada y además consumen recursos valiosos de cómputo. Ahora revisemos de nuevo a la clase AppKernel.

Fíjate en la implementación del método registerContainerConfiguration, el parámetro $loader, que es un objeto de tipo LoaderInterface, carga los archivos config_’.$this->getEnvironment().’.yml, obviamente el método getEnvironment devuelve el valor seteado a la variable environment en el constructor de la clase Kernel, entonces el framework estaría leyendo al archivo config_’prod’.yml, y ahí tienes la convención que tienes que seguir, revisa la carpeta app/config de tu proyecto, seguro tienes un archivo config_dev.yml y otro config_prod.yml, donde tienes los llamados a los recursos que fueron considerados necesarios por los programadores.

Por otro lado, fíjate que se hacen llamados a los archivos app/config/routing_dev.yml en config_dev.yml y a app/config/routing_prod.yml en config_prod.yml, cada archivo de configuración llama a sus respectivos archivos de rutas y pudiera importar otros recursos, los que se consideren necesarios, como puedes observar la convención es archivo_ambiente.yml. Solo es obligatoria para el archivo de configuración, el que es cargado en la línea 35 de la clase AppKernel, osea config_ambiente.yml, los otros recursos pudieran no seguir la convención y aún así tu app funcionaría.

Pero si haces eso, el próximo programador que haga mantenimiento a tu código te perseguirá hasta el fin del mundo para llevarte a la justicia, y cuando eso suceda no digas entonces que no se te advirtió.

Symfony también trabaja la caché de manera distinta según el ambiente, esto se debe a que como cada ambiente carga recursos distintos, el framework los maneja de manera distinta, examinemos al método getCacheDir de la clase Kernel del componente HttpKernel que es la clase de padre de la clase AppKernel.

El componente que escribe la caché le pregunta al kernel: Oye y a todas estas, ¿Dónde escribo la caché? Y el kernel responde: pues como estamos en ‘dev’ escríbela en app/cache/dev; y así según el ambiente que configuremos.

Entonces tenemos claro que cada ambiente es un set de configuraciones, para satisfacer ciertas necesidades de despliegue, estas necesidades pudieran ser cargar o no ciertos bundles o módulos de tu app, revisa de nuevo la clase AppKernel en la línea 22, nota que la sentencia if está preguntando si la propiedad environment de la clase contiene el valor dev o el valor test, para así cargar los bundles que nos ayudan a desarrollar, los necesarios para depuracion etc …,  veamos ahora la instanciación del kernel en el controlador frontal app_dev.php

¿Ves que ahora pasamos como parámetro el ambiente dev? y que además le decimos al kernel (pasando el segundo parámetro como true) que active el debug. Así que ¿Ya tienes la idea, no?, es simplemente un set de configuraciones como ya mencioné, de hecho pudieras crear tu propio ambiente, supongamos benchmark, para pruebas de desempeño, también pudieras tener un ambiente stable, o bug_free, donde solo cargues los bundles que ya se encuentren estables, en cada uno de los casos sigue las convenciones:

  • Obligatorias, es decir: config_benchmark.yml o config_stable.yml
  • No obligatorias pero recomendadas: si necesitas otros recursos de configuración que son solo pertinentes a tu ambiente, nombrarlos siguiendo la convención:
    • routing_benchmark.yml, services_benchmark.yml.

Regístrate hoy en Styde y continua mejorando tus habilidades: ver planes.

Lección anterior Introducción a Symfony II, Estructura de directorios Lección siguiente Introducción a Symfony IV, Controladores