Detectar cambios ascendentes: Pruebas semanales de módulos con GitLab CI

Aprovechar las plantillas de GitLab para probar módulos de forma proactiva

Mantener tus módulos de Drupal alineados con el ecosistema de Drupal en constante evolución es crucial para la estabilidad y la mantenibilidad. Pero comprobar manualmente la compatibilidad de los módulos con varias versiones del núcleo de Drupal y otras dependencias puede ser un proceso lento y propenso a errores. Afortunadamente, Drupal ofrece una potente solución: las Plantillas CI de GitLab. Estas plantillas proporcionan un entorno preconfigurado para ejecutar pruebas automatizadas, garantizando que tus módulos estén listos para cualquier actualización o cambio.

Las plantillas CI de GitLab: tu base para las pruebas automatizadas

Las plantillas de GitLab CI son una colección de archivos de configuración preconfigurados diseñados para agilizar el proceso de pruebas de los módulos de Drupal. Proporcionan un marco sólido para ejecutar diversas pruebas, todo ello en un entorno coherente y fiable.

¿Qué pueden hacer las plantillas?

Estas plantillas están diseñadas para cubrir una amplia gama de escenarios de pruebas, incluyendo:

• Pruebas con varias versiones de Drupal: Ésta es la principal ventaja. Las plantillas están configuradas para ejecutar pruebas con la versión actual del núcleo de Drupal, así como con versiones menores y mayores, anteriores y futuras, del núcleo de Drupal. Esto te permite identificar proactivamente los problemas de compatibilidad antes de que afecten a tu proyecto.
  • Pruebas con versiones futuras: Garantiza que tu código funciona con las próximas funciones y está preparado para las obsoletas.
  • Pruebas con versiones anteriores: Ayuda con la compatibilidad con versiones anteriores si necesitas mantener la compatibilidad con versiones anteriores de Drupal.
• Tipos de prueba completos: Las plantillas incluyen soporte para:
  • Linting: Análisis estático para identificar violaciones de estilo del código.
  • Análisis estático del código: Análisis más profundo para detectar posibles errores y vulnerabilidades.
  • Pruebas unitarias: Asegúrate de que los componentes individuales de tu módulo funcionan correctamente.
  • Y más: Puedes ampliar el conjunto de pruebas para incluir pruebas de integración, pruebas funcionales y otras pruebas, según sea necesario.

Configuración sencilla: listo para MR, commits y versiones

¿Y lo mejor? Estas plantillas son increíblemente fáciles de configurar. Están configuradas para ejecutarse automáticamente siempre que

• Se creen o actualicen Solicitudes de Fusión: Se detectan posibles problemas antes de fusionar el código.
• Se realicen confirmaciones en tus ramas de desarrollo: Asegúrate de que tus cambios no rompen la funcionalidad existente.
• Se publiquen nuevas versiones de tu módulo: Valida que la nueva versión se integra perfectamente con el núcleo de Drupal y otros módulos.

Para que esto funcione con tu módulo, sólo tienes que crear un archivo llamado .gitlab-ci.yml en el directorio raíz del código del módulo. Debe contener estas líneas:

include:
  - project: $_GITLAB_TEMPLATES_REPO
    ref: $_GITLAB_TEMPLATES_REF
    file:
      - '/includes/include.drupalci.main.yml'
      - '/includes/include.drupalci.variables.yml'
      - '/includes/include.drupalci.workflows.yml'

Eso es todo lo que necesitas para adoptar todos los valores predeterminados de las plantillas mantenidas por la comunidad. En algunos casos, puede que tengas que ajustar la configuración a tus propias necesidades, y puedes encontrar todas las opciones disponibles en la Documentación de Plantillas de GitLab CI.

Cambios de configuración recomendados

A lo largo de los años, hemos aprendido que las pruebas automatizadas sólo son realmente valiosas con los siguientes ajustes:

• No permitir fallos para PHPStan, PHPCS, CSpell
• Aumentar el nivel de PHPStan a 6

No permitir fallos en las pruebas, lo que significa que se te avisa si algo falla, se puede conseguir modificando las tareas respectivas en tu archivo .gitlab-ci.yml:

cspell:
  allow_failure: false
phpcs:
  allow_failure: false
phpstan:
  allow_failure: false
phpstan (next minor):
  allow_failure: false
phpstan (next major):
  allow_failure: false

Para aumentar el nivel de PHPStan, necesitas un archivo llamado phpstan.neon en la raíz de tu módulo con las siguientes instrucciones:

parameters:
  level: 6

Es posible que haya más instrucciones en ese archivo, dependiendo de la naturaleza de tu módulo y de los tipos de advertencias que puedas ver y que quieras ignorar, probablemente.

Módulos estables y actualizaciones de componentes inadvertidas

Mantener la compatibilidad de tus módulos de Drupal es un esfuerzo continuo. Los módulos que no han visto actualizaciones durante un período significativo -nos referiremos a ellos como estables o maduros- pueden quedarse rápidamente rezagados respecto al ecosistema actual de Drupal. Sin pruebas periódicas, los cambios sutiles en el núcleo de Drupal o en otros módulos pueden dar lugar a actualizaciones inadvertidas de los componentes, problemas que no son evidentes de inmediato pero que pueden causar problemas en el futuro. Este capítulo explora por qué estos módulos necesitan una atención extra y cómo identificar y abordar de forma proactiva estos posibles problemas.

Por qué los módulos estables necesitan atención extra

Los módulos que no han recibido actualizaciones recientes suelen depender de versiones antiguas del núcleo de Drupal o de otros módulos. Esto crea una cadena de dependencias, e incluso pequeños cambios en cualquier parte de la cadena pueden crear problemas de compatibilidad. Cuanto más tiempo permanezca intacto un módulo, más probable es que sus dependencias hayan evolucionado, y mayor es el riesgo de que se produzcan actualizaciones inadvertidas de componentes.

Actualizaciones inadvertidas de componentes: los riesgos

Sin pruebas periódicas, estas actualizaciones pueden manifestarse como:

• Cambios de comportamiento: La funcionalidad de un módulo puede cambiar sutilmente debido a una versión más reciente del núcleo de Drupal.
• Funcionalidad obsoleta: Las llamadas a funciones o las API que antes eran compatibles pueden eliminarse en versiones más recientes.
• Vulnerabilidades de seguridad: Los módulos más antiguos pueden no estar parcheados contra vulnerabilidades de seguridad recién descubiertas.

La prueba proactiva es clave

Para mitigar estos riesgos, es crucial probar regularmente las versiones estables de los módulos con las versiones actuales y futuras del núcleo de Drupal. Aquí es donde entran de nuevo las plantillas CI de GitLab.

Una ventaja adicional de este enfoque se produce cuando hay una nueva fusión en la cola de incidencias que corrige algo en tu módulo, y las canalizaciones muestran de repente fallos que no tienen nada que ver con esa corrección. Si se hubiera probado el módulo y corregido el nuevo fallo de forma proactiva, eso no habría ocurrido.

Pruebas programadas semanalmente

Probar tus módulos de Drupal no debería ser un acontecimiento puntual provocado por un nuevo commit. Para garantizar realmente la estabilidad a largo plazo y evitar actualizaciones inadvertidas de los componentes, necesitas un proceso de pruebas automatizado y coherente. Este capítulo describe cómo configurar pruebas semanales programadas utilizando las plantillas de GitLab CI.

Configuración de pruebas semanales programadas a través de la interfaz de GitLab

La buena noticia es que configurar estas pruebas semanales es increíblemente sencillo. Te explicamos cómo:

1. Navega a la página de GitLab de tu módulo, por ejemplo https://git.drupalcode.org/project/eca (sustituye eca por el nombre corto de tu propio módulo)
2. Busca Pipeline Schedules en la sección "Build" de la barra de herramientas de la izquierda
3. Configura la Programación: Haz clic en el botón "New schedule" para crear una nueva canalización programada. Aquí puedes definir la frecuencia, la hora del día y la rama que debe probarse.

GitLab realizará las mismas pruebas descritas anteriormente utilizando la configuración ya disponible en el archivo .gitlab-ci.yml de la rama configurada.

Aplicación del enfoque a los módulos personalizados privados

El proceso de pruebas automatizadas que hemos descrito hasta ahora está diseñado principalmente para módulos que han sido liberados en Drupal. Sin embargo, los mismos principios -pruebas coherentes y detección proactiva de problemas de compatibilidad- se aplican igualmente a los módulos personalizados privados. Este capítulo demuestra cómo extender este enfoque a tu propio desarrollo de módulos privados. Sólo requiere tu propia instancia de GitLab, donde puedes mantener privados los módulos personalizados, sin dejar de utilizar los mismos componentes de infraestructura para las canalizaciones.

Para que esto funcione, añade un archivo .gitlab-ci.yml a tu módulo personalizado en tu propia instancia de GitLab y copia en él el siguiente contenido:

include:
  - remote: 'https://gitlab.lakedrops.com/gitlab-ci-cd/drupal/-/raw/main/private-modules.yml?ref_type=heads'

Esto utiliza la plantilla de nuestro proyecto Drupal CI. Puedes utilizarlo directamente o clonar ese proyecto en tu propia instancia de GitLab y mantenerlo allí tú mismo.

Además de la configuración del CI, también tienes que proporcionar tus propios ejecutores de GitLab, ya que no podemos utilizar la infraestructura de la Asociación Drupal para ejecutar nuestras pruebas privadas. Para configurar un ejecutor para tu proyecto, ve a la configuración de CI/CD de ese proyecto en tu instancia de GitLab y sigue las instrucciones de la sección "Runners". Simplemente utiliza Docker como ejecutor del runner y cualquier imagen PHP como punto de partida. Las plantillas CI traerán sus propias imágenes Docker necesarias para ejecutar todas las pruebas.

Esta configuración probará tus módulos personalizados privados del mismo modo que los módulos normales de Drupal en drupal.org, y si también configuras canalizaciones programadas semanalmente, te beneficiarás de esas pruebas regulares del mismo modo.

Ventajas de un enfoque unificado

Utilizar la misma plantilla para módulos públicos y privados garantiza un flujo de trabajo de pruebas coherente y sólido, independientemente del alcance y el estado del módulo.

Conclusión

Un enfoque holístico del desarrollo de módulos de Drupal

A lo largo de esta guía, nos hemos centrado en establecer un marco de pruebas sólido para los módulos de Drupal, tanto públicos como privados. Implementando pruebas semanales automatizadas y aprovechando las plantillas CI/CD de GitLab, te habrás equipado con un potente sistema para garantizar la calidad, compatibilidad y estabilidad del código.

Mirando al futuro - Pruebas reales de dependencia de sitios Drupal

Sin embargo, probar tus módulos es sólo una pieza del rompecabezas. Un desarrollo verdaderamente proactivo requiere una comprensión en tiempo real de la salud de tus módulos en un entorno completo. Ahí es donde entra en juego el concepto de sitios de referencia.

Para saber más sobre la configuración y gestión de sitios de referencia para la monitorización en tiempo real y las pruebas de dependencia, consulta nuestro artículo complementario: Pruebas de dependencia de sitios reales de Drupal: un enfoque estratégico

Recursos y lecturas adicionales

• Plantillas de GitLab CI y su documentación
• Plantilla LakeDrops Private Module CI/CD
• Pruebas reales de dependencia de un sitio Drupal - Un enfoque estratégico

¡Gracias por completar esta guía! Esperamos que hayas obtenido información valiosa y técnicas prácticas para mejorar tu flujo de trabajo de desarrollo de módulos de Drupal.

Divulgación: He utilizado el LLM Gemma3 en Ollama para construir la estructura y crear algunas sugerencias de contenido basadas en mi propia comprensión del espacio del problema y las soluciones que hemos implementado. También he utilizado Deepl y LanguageTools para mejorar la ortografía y la gramática. Escribir el artículo en sí lo considero mi propio trabajo, y la IA ha sido simplemente una herramienta de apoyo.