Symfony: tutorial 9: los entornos, y las configuraciones

Continuando con el repaso de Symfony y Symfony Flex, seguimos con las configuraciones y entornos de ejecución. Como buena estrategia de desarrollo, tenemos que tener presente el establecer varios entornos en los que vamos a trabajar en los proyectos sobre Symony. Es decir, por defecto, Symfony te invita a usar 3 entornos:

• Desarrollo, cuyo nombre en clave es dev, del inglés develop.
• Pruebas, cuyo nombre es test, que podemos correr en local o en un entorno con CI y CD.
• Producción, con nombre en clave prod, que será en el servidor en Internet, aunque podemos simularlo en local también.

La idea es muy sencilla, Symfony nos propone que trabajemos en el entorno de desarrollo inicialmente. Luego tenemos el entorno de pruebas, en donde haciendo tests funcionales y unitarios nos quedaremos seguros de que todo funciona. Finalmente tenemos el entorno de producción, en donde todo debe prepararse para estar de cara al público de Internet, todo bien cacheado, sólo con los módulos necesarios, y demás configuraciones finales..

A saber, tendremos tres elementos para trabajar con los entornos de trabajo:

• Las variables de entorno, configuradas en el fichero .env
• Los paquetes instalados con Composer.
• Las configuraciones por entorno en el directorio config/

Primera vistazo, en qué entorno estamos

Esto viene definido por el fichero .env como indicamos antes. Aquí se definen algunas variables principales de los paquetes que estemos usando. Tenemos la variable que indica en qué entorno estamos, cadena de conexión con la base de datos, o cadena de conexión con el servidor de envío de correo electrónico, por ejemplo.

En versiones anteriores de Symfony teníamos un fichero .env.dist con configuraciones por defecto, y en las últimas versiones sólo nos viene un fichero .env, por ejemplo uno como el siguiente código:

# This file is a "template" of which env vars need to be defined for your application
# Copy this file to .env file for development, create environment variables when deploying to production
# https://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration

###> symfony/framework-bundle ###
APP_ENV=dev
APP_SECRET=13bb5de558715e730e972ab52626ab6a
#TRUSTED_PROXIES=127.0.0.1,127.0.0.2
#TRUSTED_HOSTS=localhost,example.com
###< symfony/framework-bundle ###

###> doctrine/doctrine-bundle ###
# Format described at http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#connecting-using-a-url
# For an SQLite database, use: "sqlite:///%kernel.project_dir%/var/data.db"
# Configure your db driver and server_version in config/packages/doctrine.yaml
DATABASE_URL=mysql://db_user:db_password@127.0.0.1:3306/db_name
###< doctrine/doctrine-bundle ###

###> symfony/swiftmailer-bundle ###
# For Gmail as a transport, use: "gmail://username:password@localhost"
# For a generic SMTP server, use: "smtp://localhost:25?encryption=&auth_mode="
# Delivery is disabled by default via "null://localhost"
MAILER_URL=null://localhost
###< symfony/swiftmailer-bundle ###

Este fichero hay que cambiarlo a un fichero .env.local, .env.dev, .env.test, .env.prod, etcétera.. y así distinguiremos entre las distintas configuraciones. Por seguridad, no debemos de cargarlo en Git para tener uno distinto en cada entorno. Tendremos entonces en producción este fichero distinto al que usamos en local mientras desarrollamos.

Fíjate que marco en negrita la principal variable que define el entorno en que la aplicación web estará corriendo. Como he dicho arriba, los valores posibles por defecto son: dev, test y prod.

Además, se pueden cargar en memoria del servidor estas variables, así cargará más rápido cada petición sin leer del fichero haciendo esto: composer dump-env prod

Los paquetes de Composer en cada entorno

Un proyecto de ejemplo puede ser el siguiente, si nos fijamos en el fichero config/bundles.php:

Podemos ver qué bundle está en qué entornos. Los que tienen el ‘all’ => true es que están en todos los entornos, el resto están sólo en los entornos en donde se usan. Una nueva característica muy buena que tiene Symfony Flex es que ahora mientras que vamos creando el proyecto no instalamos todos los paquetes que existen. Es decir, vamos instalando sólo los que necesitamos. Y además, vamos instalando los paquetes para los entornos en los que los vamos a usar. Esto hace al proyecto más ligero y que corra más rápido.

Por ejemplo, si nos fijamos el TwigBundle, vemos que se ha cargado en todos los entornos habiendo ejecutado lo siguiente:

composer require twig

También por ejemplo, en el generador de código de Symfony, el maker, éste sólo tiene sentido que esté en el entorno de desarrollo, así que por esto que habremos ejecutado lo siguiente para instalarlo:

composer require maker --dev

Así sucesivamente con todos los paquetes.

Qué configuraciones se aplican por entorno

De igual modo que los paquetes de Composer se usan según qué entornos, tenemos las configuraciones por entorno.

Es decir, por ejemplo podemos tener distintas bases de datos configuradas en la misma máquina. Esto tiene mucho sentido para programar en desarrollo contra una base de datos que vamos marraneando mientras que construimos todo lo que queramos. Sin embargo, a la hora de pasar a producción debemos antes de lanzar toda nuestra batería de pruebas. Lo lógico es tener en local una segunda base de datos que regeneramos con cada lanzamiento de las pruebas. Si hemos marraneado mucho la base de datos de desarrollo puede que nos confundan resultados positivos o negativos en las pruebas, y finalmente repercute en errores en el paso a producción.

Otro por ejemplo pueden ser los correos electrónicos. Podemos estar probando funcionalidades con los correos electrónicos en desarrollo local, en test local, y finalmente usar en producción otras configuraciones. Podíamos por ejemplo hacer que tanto desarrollo como test nos envíe a nosotros mismos todos los correos.

Así podríamos hacer lo mismo con cualquier otra configuración. Esto se consigue simplemente siguiendo la estructura que nos presenta Symfony. En el ejemplo de la imagen de arriba tenemos los directorios:

• config/packages/
• config/packages/dev/
• config/packages/prod/
• config/packages/test/

En el primer directorio tendremos todos los ficheros de configuración. Y simplemente haremos «overriding» de las configuraciones poniendo las configuraciones especiales que queramos en los directorios dev, prod y test.

Terminando

Para terminar no me queda más que remitirte a la documentación oficial:
https://symfony.com/doc/current/configuration.html

..y al siguiente tutorial de iniciación a Symfony sobre la inyección de dependencias en Symfony. ¡Un saludo!