Cómo desplegar una aplicación Symfony 4 en tu servidor

En otros artículos hemos hablado de los motivos por los que utilizar Symfony como nuestra herramienta de desarrollo, buenas prácticas o cómo crear nuestro primer proyecto con Symfony 4.

Una vez nos hemos decidido a desarrollar nuestra aplicación con Symfony y la tenemos lista para desplegar en producción debemos tener en cuenta una serie de cosas tanto cuando se trata de un primer despliegue como cuando se trata de una actualización.

¿Qué opciones tenemos para desplegar los cambios en una aplicación?

Actualmente hay 2 alternativas principales, por un lado podemos ver la aplicación como un conjunto de ficheros de código, configuración, base de datos, dependencias y demás artefactos. En ese caso necesitaremos tener una estrategia clara para que los nuevos cambios en el conjunto de nuestra aplicación que se suele describir mediante build scripts.

docker

Otra aproximación que se está extendiendo rápidamente son las aplicaciones empaquetadas en contenedores.

Actualmente es docker la herramienta que se ha posicionado como estándar de facto y que nos permite, en lugar de utilizar scripts que manejan los cambios en la aplicación, empaquetar la aplicación en una imagen que contiene todas las dependencias y aísla la ejecución de otras aplicaciones que se estén ejecutando en el servidor.

La ventaja es que para cada versión de nuestro software podemos construir la imagen necesaria en nuestro servidor de CI/CD y publicarla en el registro correspondiente para que la actualización sea tan sencilla como levantar otro contenedor que sirva la aplicación en base a la imagen nueva y detener la ejecución del contenedor con la versión antigua.

Normalmente durante el desarrollo se debe tener en cuenta si el objetivo será usar docker ya que puede condicionar algunas decisiones que tomemos para facilitar después el uso de contenedores. Por ejemplo cuando usamos contenedores las aplicaciones deben ser stateless (no deben mantener estado, es decir, debe poder destruirse el contenedor de un nodo del clúster y levantarse otro usando la misma imagen sin que el servicio se vea afectado).

¿Qué vamos tratar nosotros en este artículo?

Vamos a seguir la aproximación clásica, tenemos un servidor en el que reside la aplicación, con un estado actual y queremos poder desplegar nuestras nuevas versiones de la manera más sencilla y automatizada posible.

Para ello, como ya hemos anticipado, no vamos a entrar en las posibilidades del mundo de los contenedores porque se trata de un tema algo más avanzando, tampoco en los zero downtime deployments en los que el servicio no se interrumpe.

Lo que sí pretendemos es sentar las bases de qué cambios son los más comunes que sufre una aplicación cuando está en desarrollo o mantenimiento y necesita ser actualizada para que a partir de ahí cada equipo profundice en las técnicas avanzadas relacionadas con sus necesidades.

¿Qué piezas componen una aplicación cuando afrontamos su despliegue?

Código de la aplicación

Es el código que nosotros escribimos y por tanto del que nos responsabilizamos, en nuestro caso se trata fundamentalmente del contenido de las carpetas assets, config, src y templates.

Cuando queremos desplegar una nueva funcionalidad por lo general tendremos nuevo código o modificaciones en el código de nuestra aplicación y transmitir estos cambios desde nuestro entorno de trabajo al servidor de producción puede ser tan sencillo como subir mediante FTP los ficheros correspondientes. Esto es un proceso manual y como todo proceso manual es propenso a errores, es por ello que si ponemos en una balanza simplicidad, comodidad y calidad del proceso (que sea repetible, fiable, la posibilidad de rollback) una opción sólida que equilibra las cualidades que queremos maximizar es el uso de git.

Ya deberíamos estar utilizando git como pieza central en nuestro flujo de desarrollo y como sistema de control de versiones distribuido nos va a permitir tener otro repositorio en producción que utilizaremos únicamente para desplegar cambios.

Esto puede hacerse de manera más o menos automatizada según queramos complicar el proceso. Si usamos un servicio de CI/CD podemos automatizar el envío a nuestro servidor de producción de los cambios, pero si no queremos dar el paso podemos trabajar con 2 remotes en nuestro proyecto, uno para nuestro repositorio central (github, gitlab, etc) y otro para el servidor de producción..

Para cambiar la versión del código de producción lo único que tendremos que hacer es pushear los nuevos commits al remote que tengamos configurado.

Configuración

Los parámetros que configuramos en una aplicación Symfony deberían encontrarse en los ficheros .env*, es cierto que al desplegar los cambios en el código habremos actualizado nuestro fichero .env pero tendremos que realizar manualmente cualquier cambio en .env.local.

A pesar de ser un paso manual en entornos en los que queremos tener un flujo sencillo no debería ser un problema ya que es una de las zonas de la aplicación que menos cambia. Además por la propia naturaleza de la información almacenada muchas veces no podemos incluirla en nuestros repositorios por lo que las opciones disponibles no son muchas, prácticamente nos quedan los gestores de secretos como vault o la configuración manual.

Si a esto le sumamos un esfuerzo por nuestra parte en tener valores por defecto sensatos nos encontraremos muchas veces sin la necesidad de sobrescribir el valor por defecto de .env y por tanto no tendremos que realizar ninguna acción manual. En otras ocasiones tendremos que configurar los valores de manera obligatoria, por ejemplo cuando tenemos que añadir un token de autenticación de un sistema de terceros.

Bases de datos

En una aplicación basada en Symfony es muy común que cuando estemos trabajando en nuevas funcionalidades nos encontremos trabajando con nuevas entidades o cambios en las ya existentes. Para ese caso de uso hay una opción muy potente, se trata del paquete doctrine/doctrine-migrations-bundle.

Una vez empecemos a utilizar migraciones nuestro flujo de trabajo durante el desarrollo contará con un paso más, cada vez que modificamos la persistencia de las entidades generaremos una migración. Esto se traducirá en un nuevo fichero php con la habilidad de ejecutar el SQL necesario para hacer el cambio en la entidad y el SQL necesario para deshacer el cambio.

Por tanto tendremos en nuestro sistema de control de versiones un sistema de control de versiones de la estructura de la base de datos. Podemos dejar que sea el paquete quien se encargue de generar el SQL necesario pero también podemos modificarlo para reflejar otro tipo de cambios o generar migraciones vacías en las que seremos nosotros quien defina el cuerpo de los métodos up y down.

Cuando esas nuevas migraciones se encuentren en el servidor de producción tendremos que ejecutarlas para que realice los cambios necesarios a en la base de datos.

piezas-aplicacion

Dependencias

Si estamos usando Symfony y Webpack Encore contaremos con 2 gestores de paquetes, por un lado Composer para las dependencias php y por otro Yarn para las correspondientes al front.

Cada vez que realicemos cambios en los ficheros que describen las dependencias que maneja Composer tendremos que ejecutar en nuestro servidor composer install –no-dev –optimize-autoloader para que la herramienta descargue las versiones correctas de nuestras dependencias y las instale teniendo en cuenta las optimizaciones que se pueden llevar a cabo en producción.

De igual manera, cada vez que realicemos cambios en los ficheros correspondientes a Yarn tendremos que ejecutar yarn install en nuestro servidor.

Artefactos

En el caso que planteamos, y siguiendo la misma filosofía que con las dependencias, si hay cualquier cambio en nuestros assets éste debería reflejarse en los artefactos construidos con Webpack.

Para ello tenemos 2 opciones, construir esos artefactos en otra máquina y enviarlos al servidor de producción o construirlos en el propio servidor de producción. La decisión aquí implica cambios en cómo instalamos nuestras dependencias con Yarn en el servidor de producción, si queremos utilizar Webpack en el servidor de manera que lancemos yarn encore production en producción para generar nuestros artefactos no podremos utilizar el flag –production con valor true, de lo contrario no tendremos instalados los paquetes necesarios

Caché

Por último cuando tenemos una aplicación Symfony configurada para ejecutarse en modo producción tanto el framework como algunos paquetes almacenan información en caché, cuando hacemos cambios es posible que tengamos que purgar la caché de Symfony para que realmente se ejecute nuestro nuevo código.

Desde cambios en las entidades a los cambios en las plantillas que se almacenan en caché precompiladas pasando por las traducciones forman parte de la lista de elementos que hacen uso intensivo de la caché del proyecto. Para esto solo tendremos que ejecutar php bin/console cache:clear en el entorno de producción, la caché quedará purgada y a partir de ese momento empezará a cachearse información en base a nuestro nuevo código.

Conclusión

Como hemos visto el proceso de manera global puede ser todo lo sencillo o todo lo complejo que queramos optando por diferentes técnicas y herramientas. Además cada paso del proceso de manera individual puede a su vez automatizarse en mayor o menor medida dependiendo del tipo de herramientas que usemos.

Con el planteamiento que realizamos debería ser suficiente escribir un script para que todas las partes automatizables se realicen de manera autónoma, a partir de ahí podemos saltar hacia el uso de herramientas especializadas como deployer, a servidores de CI/CD que orquesten el proceso y a flujos de trabajo basados en contenedores que es la dirección que está tomando la industria.

Dependiendo del tamaño de nuestros proyectos y de la cantidad de recursos que tengan asignados tendremos que tomar las decisiones que consideremos, nuestro consejo es que analicéis siempre en qué estado se encuentra vuestro proyecto en cuanto a proceso y defináis cuales son los puntos críticos para automatizarlos e ir avanzando.

Crea tu primer proyecto con Symfony 4, Webpack Encore y Bootstrap Sass

Cuando nos enfrentamos al inicio de un proyecto a medida siempre tenemos que tomar la difícil decisión de qué herramientas utilizar para ponernos manos a la obra con el desarrollarlo. Desde acceseo afrontamos muchos tipos de proyectos desarrollados a medida y una de nuestras herramientas preferidas para tener una base que nos permita acortar los plazos de entrega es Symfony, que con su reciente versión 4 y la llegada de Symfony Flex posibilita más si cabe que se adapte a proyectos de cualquier tamaño, desde integraciones de ERPs o creación de pequeñas APIs hasta aplicaciones web completas. Si quieres convencerte de usar Symfony, te recomendamos que leas nuestro anterior post «Por qué desarrollar tu proyecto con Symfony«.

Una vez decidimos el framework sobre el que vamos desarrollar la aplicación necesitamos saber qué herramientas vamos a utilizar en el frontend y sin duda alguna uno de los pilares fundamentales en este área para cualquier proyecto que no cuente con un diseño elaborado (una pequeña intranet por ejemplo) es Bootstrap, desde su llegada de la mano de los ingenieros de Twitter redujo la complejidad de la tarea de maquetación de interfaces sencillas y agradables al mínimo.

¿Y para qué necesitamos Webpack entonces? Webpack + Webpack Encore será la herramienta que nos ayudará a procesar y simplificar el flujo de trabajo con nuestros recursos estáticos (en este ejemplo css/js).

Por tanto el ejemplo que vamos a desgranar a continuación utiliza Symfony4 para el backend, Bootstrap para el frontend y Webpack para la gestión de estáticos.

Prerequisitos

Una vez tengamos todo esto instalado en nuestra máquina podemos empezar.

Creación de una aplicación con Symfony 4

Una de las formas aconsejadas por Sensio Labs para crear una aplicación web Symfony 4 con necesidades estándar es utilizar el skeleton que ponen a nuestra disposición, para ello solo tenemos que crear un proyecto con Composer basado en la plantilla website-skeleton, en este ejemplo llamaremos webpack-sf4 al proyecto.

Una vez ejecutado este comando tendremos un proyecto nuevo en la carpeta webpack-sf4. No vamos a necesitar un servidor HTTP ya que durante el proceso de desarrollo podemos utilizar el servidor que incorpora PHP para servir la aplicación, además para simplificar la tarea existe un bundle específico de Symfony que podremos instalar de la siguiente forma.

Llegados a este punto ya podemos ejecutar nuestra aplicación lanzando el siguiente comando desde dentro de la carpeta webpack-sf4 y accediendo a la url localhost:8000

Lo único que veremos en nuestro navegador es un error, que nos indicará que la aplicación está funcionando pero no ha podido servir la petición que hemos hecho, esto es porque no hay lógica definida para ninguna ruta en la aplicación, para ello vamos a crear un controlador muy simple que sirva una plantilla muy sencilla también.

Crearemos el fichero src/Controller/DefaultController.php con el siguiente contenido.

Y el fichero templates/default/index.html.twig con el siguiente contenido.

Si recargamos la página ya podemos ver nuestro mensaje en pantalla sin estilo ni interacción.

Instalación Webpack Encore

Para integrar Bootstrap en nuestro proyecto vamos a hacer uso de Webpack Encore que tendremos que instalar y configurar.
Vamos a instalar el paquete a través de Yarn con el siguiente comando.

Ahora todo lo que necesitamos es configurar correctamente la integración con Webpack y cuando lo tengamos todo funcionando instalaremos nuestras dependencias, en este caso Bootstrap Saas. Para ello vamos a crear el fichero SASS que albergará nuestro CSS y el fichero JS que nos servirá de punto de entrada a la aplicación.

Crearemos el assets/css/app.scss con el siguiente contenido.

Y el fichero assets/js/app.js con el siguiente contenido.

Ahora debemos configurar el proceso de build en Webpack y modificar la plantilla base para que el sistema reconozca la salida del proceso de build de los ficheros estáticos.

Para lo primero debemos añadir las dependencias que vamos a necesitar al utilizar SASS con el siguiente comando.

Ahora configuraremos el fichero webpack.config.js con las siguientes directivas.

Y añadiremos al fichero templates/base.html.twig los enlaces a nuestros ficheros.

Ahora sí podemos acceder de nuevo a localhost:8000 esperando ver nuestros flamantes colores corporativos en el mensaje que hemos escrito, pero nos encontraremos con dos errores 404 correspondientes a los ficheros app.css y app.js que acabamos de incluir en nuestra plantilla base.

Para corregir los errores debemos lanzar el siguiente comando que hará que se generen los ficheros a partir de los que hemos creado en la carpeta assets.

Nota: Si lanzamos yarn run encore dev –watch el sistema estará pendiente de los cambios que hagamos en los ficheros e irá regenerando los ficheros que enlazamos en nuestra plantilla para tener los cambios disponibles.

Ahora sí, podemos observar los cambios pero algo falla, nos falta Bootstrap para que todo se vea bien y el tooltip se muestre al hacer hover sobre el texto.

Bootstrap

Hasta ahora el proceso de setup puede que haya sido un poco complejo para tener una página con un simple H1 y apenas unas líneas de CSS pero la verdadera potencia de la tupla Webpack Encore / Yarn se hace patente cuando empezamos a utilizar dependencias en nuestros proyectos. Del mismo modo que usamos Composer para gestionar nuestras dependencias del proyecto PHP podemos utilizar Yarn para gestionar los paquetes necesarios CSS/JS.

Para importar Bootstrap en nuestro proyecto solo tendremos que ejecutar.

Con la primera línea importamos las dependencias de Bootstrap y posteriormente la librería como tal. Ahora tendremos que descomentar la siguiente línea del fichero webpack.config.js

Con esta línea Webpack Encore se encarga de facilitar jQuery a Bootstrap, ahora importaremos la parte CSS de Bootstrap desde nuestro fichero assets/css/app.scss cargándola al principio del mismo.

Modificaremos nuestro fichero assets/js/app.js para importar la parte JS de Bootstrap y ejecutar nuestro tooltip con el siguiente contenido.

Una vez hecho esto podemos generar de nuevo nuestros ficheros utilizando los mismos comandos que antes o esperamos a que se regeneren automáticamente si hemos utilizado el flag –watch, ahora sí podemos recargar la web y ver en funcionamiento tanto el CSS como el JS de Bootstrap, todo ello en nuestro proyecto con la última versión de Symfony y gestionando los recursos de la mejor manera posible.

Conclusión

Si queremos poder ofrecer la mayor calidad en el menor tiempo de desarrollo nos tenemos que apoyar en las herramientas que nos ofrece la comunidad, es posible que los procedimientos que hemos descrito en el artículo puedan ser un poco complejos al principio pero una vez interiorizado su uso vamos a poder utilizar en nuestros proyectos infinidad de paquetes que dotarán nuestro trabajo de la calidad y velocidad de desarrollo necesaria en cada caso.

Por qué desarrollar tu proyecto con Symfony

A la hora de desarrollar un proyecto es muy común preguntarse qué tecnología utilizar así como el hecho de utilizar un CMS (Content Management System) o un plataforma de e-commerce. Ambos se han hecho muy populares en los últimos años debido a que contienen una serie de funcionalidades estándar que luego se pueden adaptar a cada sitio web que se vaya a desarrollar. Como definición, un CMS es un gestor de contenidos, una aplicación ya desarrollada, que está lista para utilizarse y que permite cierto nivel de personalización y modificación.

Por ejemplo, encontramos como principales CMS para desarrollar una web a Worpdress, Joomla o Drupal y como principales sistemas para crear un e-commerce a Prestashop, Magento o WooCommerce. Cuando el proyecto es de un tamaño pequeño-mediano son plataformas ideales, ya que permiten desarrollar el sitio web de una forma muy rápida, ya que viene ya montado prácticamente todo lo necesario para empezar. Un panel de administración, un editor de texto enriquecido, un gestor de imágenes y hasta un gestor de productos, pedidos e incluso CRM dentro de las plataformas e-commerce. En ocasiones, incluso para proyectos más grandes un CMS puede hacer un gran papel.

No obstante, cuando lo que se quiere desarrollar es algo más potente, que sea muy escalable y a medida pero sin tener que reinventar la rueda, la opción adecuada suele ser la utilización de un framework.

¿Qué es un framework?

Un framework es un conjunto de herramientas y librerías ya desarrolladas y estudiadas que permiten realizar las tareas más comunes dentro del proyecto. Es decir, un framework incluye todas aquellas funcionalidades que suelen tener la mayoría de proyectos ya desarrolladas para que no se tengan que desarrollar de nuevo para cada proyecto. Con esto, el desarrollador gana mucho tiempo, pues mucha parte del desarrollo viene ya preparado. Sin embargo, no hay que confundirlo con los CMS, ya que el framework contiene las funcionalidades, aunque es el desarrollador el que tiene que darle la forma deseada y aplicar y utilizar lo que necesite, de forma totalmente a medida.

Los frameworks, en muchos casos llegan a ser incluso una forma de trabajar y de estructurar el código, esto es, una jerarquía y organización para el proyecto ya predefinida. Algunos de los frameworks para PHP más conocidos son Symfony, Zend Framework, Laravel, CakePHP o CodeIgniter.

¿Por qué Symfony?

Symfony es uno de los frameworks más populares y tiene mucho recorrido, lo cual permite que haya una comunidad importante de desarrolladores. Esto facilita el hecho de que cuando hay que realizar un desarrollo con symfony haya mucha documentación y mucha gente a la que poder preguntarle y compartir.

Este framework funciona sobre PHP y permite con su gran potencia algunas de las siguientes cuestiones:

  • Tener un proyecto bien estructurado y donde pueden trabajar / aportar muchos desarrolladores a la vez. Es decir, el hecho de trabajar con Symfony hace que una vez que una persona ha aprendido symfony luego pueda trabajar en un proyecto nuevo de forma sencilla, ya que conoce perfectamente la estructura y dónde encontrar cada funcionalidad. Incluso y por el mismo motivo, permite que un desarrollador pueda ayudar en un proyecto que ya está en desarrollo.
  • Tener un orden en el proyecto. Es fundamental, ya que cada desarrollador podría trabajar de una forma, y al utilizar un framework todos siguen un mismo orden.
  • Escalabilidad. Trabajar de una forma tan estructurada pero a la vez pudiendo desarrollar a medida, permite una gran escalabilidad. Es una de las principales diferencias a la hora de crear un proyecto con un CMS o con un framework, con este último generalmente se puede crecer todo lo necesario sin necesidad de estar cambiando constantemente todo el motor de la web.
  • No reinventar la rueda. En symfony como en el resto de frameworks es lo que se pretende. No tener que desarrollar cada vez un login de usuarios o un buscador, sino utilizar los que ya vienen, que además son mejorados constantemente por la comunidad, lo que permite tener siempre unas funcionalidades potentes y actualizadas con un esfuerzo menor. Si cada vez se tuviera que desarrollar cada funcionalidad supondría mucho tiempo y dinero, y seguramente el resultado no sería tan bueno.
  • MVC (Modelo-Vista-Controlador). Una forma de trabajar que facilita la vida a los desarrolladores y permite diferenciar entre la parte más de programación y aquella que es más de maquetación, de forma que un equipo de desarrolladores puedan trabajar mejor según su perfil y sin interferir en el trabajo de los demás.
  • Es software libre. El código de symfony es libre y está abierto a todo el mundo. Cualquiera pueda utilizarlo para su proyecto, del mismo modo que puede utilizar PHP. Esto es un gran punto a favor, ya que es algo abierto, en continuo desarrollo y avance y hace que una persona con conocimientos pueda utilizarlo a su servicio e incluso ayudar a los demás desarrolladores a mejorar.

¿Cuándo escoger Symfony?

Se ha hablado de CMS y de frameworks, pero es importante saber cuando elegir cada uno. Elegiremos el framework Symfony generalmente en los siguientes casos:

  • Cuando se necesita flexibilidad. Si en un proyecto se necesita hacer las cosas de una determinada manera y no de otra. Al contrario que los CMS donde las modificaciones están más limitadas en Symfony la programación se puede adaptar de forma total a las necesidades o requisitos del proyecto.
  • Cuando los CMS se quedan cortos. En muchos casos la utilización de un CMS puede limitar las posibilidades del proyecto, por la forma en la que están desarrollados. En symfony se puede complicar el proyecto todo lo deseado, pues permite crecer mucho más.
  • Seguridad. Utilizar symfony frente a un CMS es también un punto a favor de la seguridad, pues la mayoría de los CMS siguen los mismos patrones, mismas URLs para hacer un login y mismos bugs. Esto facilita que cuando hay un error, ese error forme parte de todos los CMS del mercado y haya que estar rápidamente con actualizaciones. En symfony, en cambio, al estar todo desarrollado a medida sobre una base, es más complicado que se puedan difundir este tipo de errores, que serían más concretos para cada proyecto y no tan genéricos.
  • Mejor gestión de recursos. Aunque los frameworks suelen necesitar bastantes recursos, es posible «jugar» con ello, al contrario de lo que ocurre con los CMS, donde la propia estructura de los mismos hace en ocasiones que no se puedan optimizar de todo.
  • Utilización de plantillas y layouts. Pese a que symfony tiene una curva de aprendizaje mayor a la de los CMS, tiene un sistema de plantillas y layouts que permiten que diseñadores o maquetadores HTML puedan aportar al proyecto sin tener demasiada idea del mismo.

 

Agencia desarrollo Symfony

Por todos estos motivos es importante plantearse antes de desarrollar un proyecto qué es lo que más conviene y en el caso de optar por un framework como symfony, rodearse de un equipo de profesionales para poder llevar el proyecto a cabo. Es indispensable trabajar con un desarrollador o agencia de desarrollo Symfony para conseguir desarrollar un sitio web más ambicioso o una aplicación web.

En resumen, se utilizará un CMS cuando sea un sitio web más o menos sencillo o se pueda cubrir de forma rápida por las funcionalidades con las que estos cuentan. Como por ejemplo una web o una tienda online al uso. Y se utilizará el framework symfony cuando desarrollo sea más complejo o se necesite un sitio web más potente y escalable.

¿Tienes alguna incidencia?

Cuéntanos qué ocurre
y nos pondremos con ello lo antes posible.

Este sitio está protegido por reCAPTCHA, y la Política de privacidad y Términos de servicio de Google.
Sucríbete a
nuestra newsletter

para estar al día en el mundo online

¡Cuéntanos tus ideas!
+34 96 653 19 14
+info@acceseo.com
He leído y acepto la política de privacidad

Este sitio está protegido por reCAPTCHA, y la Política de privacidad y Términos de servicio de Google.