Metodología de despliegue, flujo de trabajo y buenas prácticas

The challenge in deploying Drupal sites.

Hablemos de un flujo de trabajo de implementación óptimo para Drupal, para eso hay algunos supuestos:

• Trabajamos con un Drupal 8 basado en Composer.
• Al menos se disponen de dos entornos para el sitio (Integración continua y producción).
• Conocimiento en Docker u otra herramienta de virtualización.

Drupal basado en Composer, ¿qué es Composer?

Composer es un administrador de dependencias para PHP (como npm para Node o pip para Python). El núcleo de Drupal usa Composer para administrar las dependencias del núcleo como los componentes de Symfony y Guzzle. Composer nos permite gestionar de forma sistemática una lista de dependencias y sus dependencias subsidiarias. Composer instala estas dependencias a través de un archivo llamado composer.json.

¿A qué debemos hacer commit?

Fichero composer.json: aquí es donde se definen las dependencias que se van a instalar en Drupal.
Fichero composer.lock: esto es importante ya que le permitirá reconstruir todo el código base en el mismo estado que tenía en un momento cuando se ejecutaron las dependencias de composer.json.
Los vendor generalmente se dejan fuera del repositorio. Pero esto también significa que debe encontrar una forma de reconstruir e implementar el código base de forma segura.

¿Podemos ejecutar composer en nuestros entornos de producción?

Respuesta rápida, NO, esto es una mala práctica, Composer por defecto utiliza una cantidad de memoria bastante grande, de modo que esto puede afectar al rendimiento del servidor. Si quieres estar seguro de que implementará el mismo código en el que has estado desarrollando nunca se debe de ejecutar composer update.

Se considera que es suficiente tener Composer instalado en el servidor, en la imagen de Docker u otra herramienta de virtualización y ejecutar composer install para obtener las dependencias del archivo composer.lock (committed).

El proceso no es robusto. Un error de red o un tiempo de espera puede resultar en una compilación fallida, lo que introduce factores de incertidumbre en los scripts de implementación. Fácil de manejar, pero aún no es buena idea como parte de un paso delicado como el despliegue.

El proceso inevitablemente llevará mucho tiempo. Si ejecuta composer install en webroot directamente, el código base puede ser inestable durante unos minutos. Este es un orden de magnitud más largo que un proceso de actualización estándar (es decir, ejecutar drush updb y drush cim) y puede afectar la disponibilidad del sitio. Esto puede evitarse creando diferentes imágenes de virtualización e intercambiando entre la imagen antigua y la nueva cuando la última esté lista.

Incluso la instalación de Composer puede ser impredecible, especialmente en servidores con restricciones o que ejecutan diferentes versiones de Composer o PHP; en raras circunstancias, una compilación puede tener éxito pero producir una base de código diferente. Esto se puede mitigar imponiendo (por ejemplo, a través de Docker o la virtualización) un entorno de desarrollo / preparación que coincida con el entorno de producción, pero aún se podría estar perdiendo el control en un proceso relativamente largo.

Composer simplemente no es para un servidor de producción. Es una herramienta de diferente alcance, ajena a las principales tareas de un servidor de producción.

Después de descartar el servidor de producción, ¿dónde se debería de construir la base de código?

Localmente (usando el entorno de desarrollo) no sería buena idea: además de las diferencias entre el desarrollo y la configuración de producción (--no-dev), existe el riesgo de perder posibles pequeños parches aplicados al código base local. Y una construcción totalmente limpia siempre es necesaria de todos modos.

Terminaremos usando Integración continua para esta tarea. Además del trabajo de CI estándar, que se ejecuta después de cualquier cambio de código del desarrollo activo, este realiza una instalación limpia y ejecuta tests ya sean de integración, unitarios, e2e, etc. Otro trabajo de CI es que crea la base de código completa basada en la rama master y el archivo composer.lock. Esto permite compartirlo entre desarrolladores, una implementación rápida en producción a través de un tarball o rsync, y permite probar la actualización (con un proceso como: importar automáticamente la base de datos de producción, ejecutar actualizaciones de la base de datos, importar la nueva configuración, ejecutar un subconjunto de tests automáticos para garantizar que la funcionalidad básica del sitio no tenga regresiones) para una máxima seguridad.

¿Por qué Docker u otras herramientas de virtualización?

Esta es una respuesta fácil, trabajando en un Docker con las mismas características que los demás entornos, te permitirá estar seguro de que todo funcionará bien y que no hay ninguna característica nueva incompatible con el entorno de producción.

El uso de Docker en este caso permite realizar una implementación rápida.

Los desarrolladores de Drupal utilizan una variedad de herramientas diferentes y API de Drupal para facilitar la sincronización del código y la configuración entre entornos. El proceso completo se conoce como flujo de trabajo de implementación. En un nivel muy alto, esto incluye los siguientes pasos:

• Realizar un cambio en la configuración o el código en un entorno de desarrollo.
• Exportar cualquier cambio de configuración a un(os) archivo(s) que se puedan llevar al control de versiones.
• Commit de cambios de código y configuración al control de versiones.
• Sincronizar ficheros bajo el control de versiones con el servidor en producción.
• Ejecutar actualizaciones de la base de datos (update.php) e importar cualquier cambio de configuración.
• Limpiar la caché.

Herramienta de desarrollo DDEV

Los desarrolladores de Drupal también utilizan una herramienta conocida llamada DDEV que permite configurar completamente un entorno de desarrollo en cuestión de minutos.

DDEV es una herramienta de código abierto que simplifica enormemente la puesta en funcionamiento de entornos de desarrollo PHP locales en cuestión de minutos. Es potente y flexible como resultado de sus configuraciones de entorno por proyecto, que se pueden ampliar, controlar la versión y compartir. En resumen, DDEV tiene como objetivo permitir que los equipos de desarrollo utilicen Docker en su flujo de trabajo sin las complejidades de la configuración a medida.

Con esta herramienta podrás adaptar la configuración de imágenes Docker, extensiones PHP y muchos más servicios, dependiendo del entorno LIVE. También podrás depurar código y realizar pruebas de compatibilidad de forma rápida.

Por otro lado, DDEV te da la posibilidad de desarrollar código para otras aplicaciones como Laravel, Wordpress, diferentes versiones de Drupal, etc.

Integración de DDEV con proveedores de hosting

DDEV proporciona el comando pull con cualquier fichero de configuración que haya establecido. Por ejemplo, DDEV pull acquia si se ha creado .ddev / proveedores / acquia.yaml.

Esto significa que DDEV tiene total compatibilidad con la plataforma CI / DEV donde los equipos construyen, alojan y administran sus sitios web como Pantheon.io, Platform.sh, DDEV Live y Acquia.