Simplificando las Actualizaciones de Drupal: Un Enfoque Estructurado para un Mantenimiento Sin Preocupaciones

Resumen Ejecutivo: Las actualizaciones regulares de Drupal son críticas para el mantenimiento del sitio, pero muchas organizaciones las encuentran desafiantes. Basándose en casi diez años de experiencia como Gerente de Cuenta Técnica (TAM) en Acquia, este artículo presenta un enfoque estructurado que transforma las actualizaciones de una fuente de estrés en un proceso confiable.

Introducción

En la realidad actual de Drupal, las actualizaciones a veces son temidas y consumen tiempo. Las empresas temen que puedan causar más daño que beneficio, lo que las hace difíciles de ejecutar. Cuanto más tiempo esperan las empresas para hacer actualizaciones, más complicada puede volverse una actualización.

La comunidad de Drupal ha estado trabajando en nuevas iniciativas como el Project Browser (una herramienta de interfaz para descubrir e instalar módulos de Drupal), que puede proporcionar una forma de ejecutar actualizaciones en un sitio de Drupal en la interfaz y potencialmente hacerlas automáticas. Sin embargo, para sitios que incluyen equipos de desarrollo, socios, creadores de contenido y otros interesados, un proceso estructurado sigue siendo importante.

Consideraciones Generales

Antes de sumergirse en las dos fases de gestión de actualizaciones, hay algunas consideraciones generales a tener en cuenta:

Primero, es importante entender que las actualizaciones deben ser planificadas, ejecutadas por una persona, y tratadas como una tarea independiente, lo que significa que no se hacen como parte de una tarea normal de desarrollo de características.

Segundo, las empresas deben tener un procedimiento de lanzamiento, que para algunas actualizaciones incluiría un procedimiento de hotfix, para que las actualizaciones puedan ser lanzadas inmediatamente según sea necesario, especialmente las actualizaciones de seguridad.

Es importante que cuando se ejecuta una actualización, este proceso complete el ciclo completo. Ciclo completo significa iniciar el proceso de actualización, pasar por todos los pasos necesarios, y finalmente lanzar la actualización a producción, donde se convierte en parte del código de producción. Esto debe ser lanzado y luego comunicado al resto del equipo, de esa manera el resto del equipo puede tomar la actualización y ver que funciona con lo que están trabajando.

Las Dos Fases de Gestión de Actualizaciones

Cuando el desarrollo del sitio es más que un drupal hospedado, e incluye un equipo de desarrolladores, socios, creadores de contenido, etc., es importante desarrollar mejores prácticas y procedimientos para su flujo de trabajo, incluyendo las actualizaciones de drupal.

Hay algunas partes específicas de una actualización de Drupal. No olvide que todo esto debe hacerse en un entorno local para poder lanzar esto al control de versiones, o repositorio git.

Fase 1: Configuración Inicial

Lo primero que necesita suceder es tener un archivo composer bien mantenido. Algunos errores potenciales que pueden causar problemas incluyen:

1. No debe haber paquetes de versión bloqueada en las restricciones. Por ejemplo, evite especificar versiones exactas como drupal/module_name: 2.0.0 y en su lugar use restricciones más flexibles como drupal/module_name: ^2.0
2. Si usa parches, es muy importante tener un buen inventario de estos parches, y preferiblemente usar la URL para obtener el parche desde GitLab en Drupal.org.
3. Si usa repositorios personalizados, también es importante mantener un buen inventario de estos. El objetivo es evitar el gran mensaje de conflicto que composer da cuando requiere un módulo o lo actualiza.
4. Si usa una estrategia de gestión de configuración, esta necesita funcionar correctamente.

El problema principal de los conflictos con sus restricciones de composer es que el mensaje nunca es claro, y a veces puede ser confuso. Estos conflictos generalmente son más fáciles de arreglar uno por uno y requieren cierta cantidad de experiencia para navegar los errores y descubrir exactamente qué está causando realmente el problema. Esto es especialmente importante cuando el paquete que causa el conflicto puede ser un paquete cargado como un requisito por otro. La mejor estrategia para resolver conflictos, una vez que se identifica el culpable, es actualizar los paquetes específicos que están causando el error antes de pasar a la actualización más grande.

También es importante notar si hay nuevas versiones de módulos, si los cambios que vienen son versiones menores o versiones mayores, y si hay algún proceso de actualización especial a seguir, ya sea del núcleo o de los módulos.

Si las actualizaciones están atrasadas, es mejor moverlas hacia adelante lentamente. El problema con esto es que requerirá lanzamientos de hotfix en cada paso. Consulte el ejemplo en "Enfoque de Actualizaciones Incrementales"

Una vez que el archivo composer esté bien mantenido, las actualizaciones estén al día, y sepamos lo que tenemos, las actualizaciones pueden convertirse en una tarea repetitiva en su mayor parte.

Antes de comenzar el proceso de actualización, puede haber algunos pasos iniciales para organizar todo para que el 90% de las actualizaciones se conviertan en un simple proceso de composer update, drush updb, y drush cex. Desde limpiar su archivo composer hasta tener un buen proceso de gestión de configuración.

Enfoque de Actualizaciones Incrementales

Si durante la configuración inicial queda claro que algunas actualizaciones están muy atrasadas, el proceso debe ser ir paso a paso. Por ejemplo, si está en Drupal 10.1 y necesita ir a 11, debe pasar por las versiones una por una.

Comience yendo a la última 10.1.x, siga el proceso, despliegue código a producción y después de que esa actualización se lance oficialmente, es entonces cuando puede hacer el siguiente paso, la actualización a 10.2.x y, nuevamente, siga cualquier recomendación de actualización que pueda encontrar, Despliegue y lance. Solo entonces es cuando puede hacer 10.3, y seguir el mismo patrón, hasta que finalmente pueda hacer la versión 11.x.

Este es solo un ejemplo aproximado para explicar la idea.

Fase 2: Proceso de Mantenimiento

Cada proceso de actualización debe ocurrir usando versiones de código y base de datos que coincidan con producción.

El proceso estándar de actualización incluye:

1. Actualizar el código
   • Ejecutar composer update
   • Para que esto funcione sin problemas, requerirá que la fase inicial haya sido completada y composer.json esté limpio.
2. Actualizaciones de Base de Datos
   • Ejecutar drush updb
   • A veces los módulos y el núcleo tienen actualizaciones que se ejecutan a través de hook updates, especialmente cuando hay cambios mayores y de versión intermedia, estos pueden ser una alarma para asegurar que las exportaciones de configuración sucedan.
   • Monitorear los mensajes de actualización le ayudará a entender si ocurrieron cambios importantes de configuración.
3. Gestión de Configuración
   • Ejecutar drush cex
   • Exportar configuración cuando sea necesario, como se mencionó en el paso anterior.
   • Si las actualizaciones del núcleo de Drupal o módulos han ocurrido, hay una alta posibilidad de que necesite exportar configuración. Esto es importante para casos donde el esquema de configuración ha cambiado y podría causar problemas posteriores. Vea las historias "Desde el campo".
   • Recuerde que en términos de gestión de configuración, su código es la fuente de verdad.
4. Gestión de Código Personalizado
   • Cuando ocurren actualizaciones importantes, debe estar listo para actualizar su código personalizado. Es recomendable tener un inventario de las APIs de Drupal y módulos en uso y estar atento y seguir los registros de cambios de Drupal.
   • A veces los módulos y el núcleo de Drupal pueden cambiar la forma en que funciona una API, fallar en actualizar este código obsoleto puede causar problemas en el futuro. Lea la sección "Desde el Campo: Cambios de API" para un ejemplo.
5. Pruebas y QA
   • Idealmente, debe usar herramientas para proporcionar pruebas no solo para su código sino para los comportamientos de su sitio.
   • Es importante también tener un buen inventario de lo que QA puede probar, y probablemente usar una herramienta como Nightwatch.js o cualquiera de las herramientas actuales para pruebas automatizadas.
   • Tanto las pruebas de comportamiento como las pruebas de regresión gráfica podrían ayudar a hacer más rápido el proceso de lanzar actualizaciones.

Desde el Campo: Cambio de Esquema de Configuración

Durante una actualización de Drupal 10.1 a 10.2, se eliminó una clave de la configuración system.performance, llamada 'stale_file_threshold'. Cuando un cliente hizo la actualización pero no exportó configuración, una vez que desplegaron a producción, Drupal no sabía qué hacer con esta clave y produjo un error.

¿Qué pasó? El composer update actualizó el núcleo de Drupal de 10.1 a 10.2. Las actualizaciones de base de datos actualizaron y eliminaron la clave de la configuración activa (base de datos), al no exportar configuración, esta clave permaneció en el código.

Después del despliegue y cuando el proceso de importar configuración se ejecutó, que debería suceder cada vez que despliegue código, trajo la entrada de configuración de vuelta a la configuración activa (llamamos la copia de la configuración en el código configuración staged). Esto causó que todos los sitios en una instalación multisite grande produjeran un error 500 porque el sitio no sabía qué clave era stale_file_threshold - "configuración desconocida" era el mensaje de error en los logs.

Por Qué Esto Importa: Es importante recordar que la fuente de verdad en configuración debe ser su código, no su base de datos. Si no exporta los cambios que la actualización de base de datos hace a su configuración activa, abre la puerta a un potencial WSOD.

Desde el Campo: Cambios de API

El problema surgió de cambios en la API de Formularios en Drupal 10.2 que cambiaron cómo se estructuraban los formularios de configuración de campos. El cliente tenía un módulo que usaba la API de formularios intensivamente, particularmente con formularios de configuración de campos y #states.

El módulo dejó de funcionar porque aunque el código no estaba produciendo errores, la estructura del formulario había cambiado. Aunque esto nunca dio un error, las modificaciones del formulario del módulo no estaban teniendo efecto porque estaban apuntando a la estructura de formulario antigua.

Por Qué Esto Importa: Al tener un inventario del uso de código para módulo personalizado y siguiendo los registros de cambios relevantes para el núcleo en drupal.org, este tipo de problema puede ser prevenido.

Conclusión

Cuando se configura y sigue correctamente, este enfoque estructurado transforma las actualizaciones de una tarea temida en un proceso de mantenimiento rutinario. La inversión inicial en configuración y procesos adecuados se paga con actualizaciones más suaves, más confiables y riesgo reducido de problemas del sitio.