Drupal para Managers y Product Owners: seis anotaciones

solucionex_davidjguru_drupal_logo.png
Solucionex
06
Nov 20

Drupal 9 (la última versión disponible) lleva ya cinco meses en la calle. Suena el teléfono o entra un nuevo correo en la bandeja de entrada: se escucha la palabra clave. Drupal se mueve y genera nuevas oportunidades de negocio. En la administración pública se sigue implantando y se acometen desarrollos importantes con esta tecnología, empresas privadas, entidades públicas y organismos mixtos elaboran propuestas, licitaciones y ofertas relacionadas con esta tecnología que en su propio nicho específico, no deja de tener movimiento.

A partir de estas observaciones, en muchas organizaciones se abre el melón de la duda sobre la oportunidad: ¿Desarrollar proyectos basados en Drupal? ¿Entrar o no entrar? ¿Cuáles son los retos que implica? ¿Qué cambios habría que asumir? ¿En qué consiste Drupal en realidad?...Bien, hoy me planteo reunir los principales puntos conversacionales que he tenido últimamente sobre este gran asunto en seis anotaciones desarrolladas, con la idea de articular una pequeña guía interpretativa rápida y ágil (en la medida de lo posible) para ayudar a managers, jefaturas de proyecto, product owners, agentes del cambio y aquellas personas que estén en las regiones donde se toman decisiones al respecto.

Otro punto importante a tener en cuenta es que además le prometí hace unos meses a un viejo conocido de la comunidad tecnológica que publicaría algo que pudiese ser útil al respecto y aunque no es específicamente el tema del que hablamos entonces (control de versiones para Drupal) siento la necesidad de unificar ideas e intentar aportar algo de valor. Espero que estas líneas puedan resultar útiles.

¿Por dónde empezar? bien comencemos por las bases más teóricas....

 

1- Primera anotación: Ten en cuenta sus características generales

El primer apartado que quiero significar es el más general, el que suele aparecer primero en la llamada: “En la oficina se está hablando mucho últimamente de Drupal, ¿de qué va?” Bueno, al margen de lo que uno podría buscar vía Google y que existe suficiente información totalmente disponible al respecto, yo normalmente señalo una serie de características, por ser realmente las que son susceptibles de generar mayor impacto en una organización y su cultura. Por partes.
 

Para empezar, hay que identificar que Drupal es software de fuentes abiertas (Open Source: https://www.redhat.com/en/topics/open-source/what-is-open-source). Esto es, que cumple las cuatro libertades del software libre:

  • Libertad 0 - Libertad para usar el programa con cualquier propósito.

  • Libertad 1 - Libertad de estudiar como funciona el programa, modificarlo y adaptarlo a nuestras necesidades.

  • Libertad 2 - Libertad de distribuir copias del programa con lo cual puedes ayudar a tu prójimo.

  • Libertad 3 - Libertad de mejorar el programa y hacer públicas esas mejoras a los demas, de modo que toda la comunidad se beneficie.

 

Esto quiere decir, principalmente, que Drupal es un asunto de comunidad, de personas que se relacionan en torno a este interés común para compartir avances sobre esta tecnología. Sobre esta base se asienta toda una estructura de desarrolladores y desarrolladoras, testers, mantenedores de módulos, líderes técnicos, empresas y hasta una asociación internacional de Drupal. También está relacionado con el hecho de que no hay modelo premium, no hay versión enterprise, no hay una licencia de uso que mediante pago de cuota alguna te permita un soporte directo. No hay ni siquiera módulos de pago. Todo lo que vale la pena en Drupal está en abierto de acceso abierto y es gratis

En 2020 / 2021 ya no podemos seguir sosteniendo el viejo debate de si es viable un modelo de negocio basado en software libre, así que mejor dar la duda por materialmente resuelta (el estado de la industria lo puede confirmar fácilmente) y seguir avanzando. Además quisiera añadir tres puntos más:

 

  • Drupal tiene una licencia de uso: El software de fuentes abiertas, aunque pueda ser libre e incluso gratis, tiene unas reglas juego normalmente articuladas en forma de licencias de uso, que desglosan que se puede y no se puede hacer con ello, incluida la relación con trabajos derivativos o la inclusión de recursos de pago con licencia privada. Aquí puedes consultar información útil sobre licencias en Open Source: https://opensource.org/licenses 

  • Drupal tiene una fuerte centralidad: Al contrario que en el caso de otros CMS populares bajo los que puedes encontrar cualquier recurso por cualquier sitio web bajo licencia y pago, en Drupal, todo lo que tiene la suficiente solvencia tecnológica se encuentra fuertemente centralizado; no instalarás nada de terceros que no hayas encontrado aquí: https://www.drupal.org/  (y si encuentras algo por algún otro sitio ten cuidado).

 

La mecánica es simple:

Ejemplo de módulo contribuido Drupal

 

1- Encuentras un módulo que te resulte útil para tu proyecto: https://www.drupal.org/project/better_exposed_filters  

2- Pruebas ese módulo en tu instalación Drupal.

3- Revisa su documentación disponible

4- Si detectas un fallo, miras su Issue queue por si ya está registrada: https://www.drupal.org/project/issues/better_exposed_filters?categories=All 

5- Si ya lo está, busca un parche que esté subido y probado: https://www.drupal.org/project/better_exposed_filters/issues/3178558 

6- Si no lo está, crea una Issue explicando el problema y ponte a elaborar una solución.

 

  • Drupal se comunica en inglés: Como habrás podido apreciar en los enlaces anteriores, Drupal, como casi toda la tecnología, habla inglés. Es el idioma vehicular para que muchas personas de distintas partes del mundo bajo diferentes culturas que viven en diversos husos horarios puedan comunicarse (e incluso alcanzar acuerdos). ¿Sabe tu equipo algo de inglés? ¿Se sienten cómodos con el inglés? es importante, toda la “Issue Queue” o cola de tareas de Drupal se escribe en ese idioma: https://www.drupal.org/project/issues .Tal vez incluso debas aportarle al equipo algo de formación al respecto ;-) 

 

2- Segunda anotación: Conoce su estructura interna

Drupal puede verse desde diversos puntos de vista, pero tal vez el más intuitivo y el más útil a la hora de trasladar como se organiza en el plano interno y a un alto nivel, puede ser el que propongo a continuación. Personalmente es lo que mejor resultados me ha dado a la hora de explicarlo. Piensa siempre en Drupal como un elemento de dos dimensiones básicas:

  • Contenidos: Es lo que generamos, los datos: los artículos, las cifras, la información, las noticias, las imágenes, nuestras recetas, nuestras fichas de artículos y en definitiva aquel material que guardamos para procesar y ser mostrado en nuestra plataforma. 

  • Configuración: Es la relación que establecemos entre los contenidos y la estructura. Como organizamos los menús, que idiomas tenemos habilitados, que módulos de Drupal tenemos instalados y como los hemos parametrizado. Es una cuestión relacional entre contenido  y continente, podríamos decir, y en Drupal ambas dimensiones tienen la misma importancia: un snapshot de nuestro proyecto siempre podrá ser (básicamente) la fotografía conjunta que tomamos de contenido y configuración. 

Además no olvides esta tercera clave:

  • Base de datos: Drupal establece un modelo de datos estable e inicial preparado para su estructura propia, que siempre podremos ampliar con nuevas tablas, pero respetando su estructura y características. Si tocamos eso, rompemos el invento. Es en la base de datos dónde se almacenan las dos partes anteriores: contenidos y configuración. Es un error pensar que la configuración son simplemente ficheros .yaml. Estos son solo la representación “pasiva” de la misma. La activa es la que está almacenada en la base de datos y mediante procesos de importación / exportación de dichos ficheros intentaremos alinear. 

 

3- Tercera anotación: Prepara las skills de programación del equipo

Es una obviedad, pero no por ello deja de ser fundamental: debes hacer crecer las skills de tu equipo en cuanto a habilidades de programación para poder afrontar un proyecto basado en Drupal. El lenguaje de programación es PHP, pero además también realizarás cambios sobre sistemas de plantillas TWIG con su propia sintaxis o implementarás funcionalidades JavaScript para Drupal usando el modelo Drupal Behaviors (si no sabes como relacionar Drupal con JavaScript puedes seguir este tutorial:  https://medium.com/@davidjguru/javascript-drupal-101-tutorial-handbook-total-max-power-2000-a137326fea6a).

Además, la depuración del código fuente se realiza principalmente con xdebug (https://xdebug.org) desde algún IDE (PHPStorm o VSCode habitualmente), el testing se puede hacer con Behat o con PHPUnit (aquí tienes un ejemplo de testing con PHPUnit en Drupal: https://www.therussianlullaby.com/blog/functional-testing-for-browser-in-drupal-using-phpunit/) pero además, hay algunas cuestiones estructurales que tendrás que tu equipo deberá saber para moverse con soltura dentro de Drupal. Atentos.

En Drupal todavía conviven dos mundos: el de la programación orientada a objetos, formada por clases, atributos y métodos agrupados por APIs específicas (Form API https://www.drupal.org/docs/drupal-apis/form-api , Migrate API https://www.drupal.org/docs/drupal-apis/migrate-api/migrate-api-overview ,y muchas más) y el de la programación procedural en forma de funciones_hook que modifican el funcionamiento habitual de Drupal. 

Es fundamental conocer diversos Hooks (https://api.drupal.org/api/drupal/core!core.api.php/group/hooks/8.4.x) de uso cotidiano, así como todos los cambios que aparecieron en la transición entre Drupal 7 y Drupal 8, cuando Drupal se alineó con los estándares PHP, incluidos los conceptos de “plugin” (https://www.drupal.org/docs/8/api/plugin-api/plugin-api-overview) y de “servicio”(https://www.drupal.org/docs/drupal-apis/services-and-dependency-injection/services-and-dependency-injection-in-drupal-8) , ya que actualmente, en Drupal hay muchas clases con funcionalidades específicas que ya puedes usar y ahorrarte trabajo de desarrollo. ¿Conoces los servicios disponibles a nivel interno en Drupal? echa un vistazo aquí y toma contexto: https://api.drupal.org/api/drupal/core!core.services.yml/8.2.x es posible que necesites una funcionalidad y ya haya una clase que la resuelva.

Igualmente, debes saber que a partir de Drupal 8 se incorporaron diversos componentes provenientes de Symfony, como el motor de gestión de rutas. Tal vez pensar en perfiles de desarrollo PHP con experiencia en Symfony sea buena idea.

Aquí puedes ver una review de los componentes Symfony integrados en Drupal: https://x-team.com/blog/drupal-symfony-components/

 

4- Cuarta anotación: ponte al día en control de versiones

¿Puedo hacer proyectos Drupal usando subversion? Sí (es posible) y no (no, no es recomendable), pero lo importante que debes saber aquí es que si optas por svn, estarás creando una línea temporal alternativa donde tu equipo se irá alejando progresivamente del estándar de facto de trabajo de Drupal y del stack de herramientas, con lo cual cada vez será más difícil encontrar soluciones estándar a problemas cada vez más particulares. Este asunto es recurrente en ciertos entornos, al igual que otras cuestiones complementarias como si es posible “programar en Drupal” con Notepad++ y otras dudas funcionales, pero creeme: aunque pueda parecer algo traumático al principio, nada será más eficiente que aproximar al equipo al contexto de Drupal y no al revés.

A pesar de todos los cambios que impliquen sobre las herramientas y tareas habituales, se ganará una inmensa calidad diferencial, donde el control de versiones basado en Git será la verdadera piedra angular de todo

¿Por qué? porque te encontrarás dos problemas claves: como desplegar entornos locales y como realizar despliegues en los entornos de producción (cada organización debe resolver estas dos cuestiones operativa) y por el camino tendrás que aplicar parches con soluciones para tu Drupal, que también se hace usando Git como base. Y todo ello está interconectado y comienza con la necesidad de conocer bien como funcionar con el sistema de control de versiones adecuado.

De hecho, suele ser una cuestión inicial muy recurrente: ¿Cómo pongo Drupal bajo control de versiones? aquí entra en juego un recurso táctico muy importante: el fichero .gitignore, donde declaramos lo que excluimos del trackeo de Git.

¿Sabes que solemos excluir? el propio core de Drupal y los módulos contribuidos, es decir, los que descargamos de internet y son realizados por otras personas. E igual hacemos con los themes visuales o con las dependencias alojadas en la carpeta /vendor. Nada de eso ponemos bajo control de versiones. ¿Por qué? clave importante: para nosotras, todo eso no son más que "dependencias", así que cuando instalamos, hacemos git clone del proyecto e inmediatamente le decimos a Composer que resuelva todas esas dependencias que necesitamos.

Composer coteja dos ficheros que registran dependencias: composer.json, resuelve todo lo que dice ahí, lo descarga y lo anota explícitamente en el otro fichero complementario: composer.lock. Así tendrás todo instalado en local y el repositorio git manteniendo solo lo esencial. Recuerda la combinación: Git (con un adecuado .gitignore) + Composer. Claves fundamentales.

¿Necesitas un modelo de fichero .gitignore para usar? Puedes visitar nuestro repositorio abierto de Github y acceder a una pequeña carpeta de recursos generales que tenemos, con varios ejemplos de ficheros que puedes descargar, renombrarlos como .gitignore y luego ponerlos en el directorio raiz de tu proyecto Drupal: https://github.com/Solucionex/resources/tree/main/gitignores.

 

Aquí te dejo además varios enlaces a varios recursos relacionados con Git.


 

5- Quinta anotación: Identifica el stack Habitual

Ejecutar proyectos Drupal es unir Drupal con más cosas que tendrás que conocer. Habitualmente, se requiere usar una serie de herramientas y tecnologías para implementar proyectos, elementos que van desde herramientas de línea de comandos hasta motores de plantillas.  Sin avanzar demasiado hacia herramientas DevOps (Jenkins, OpenShift, Kubernetes, Kibana, Grafana, etc), podríamos hablar a un nivel básico de una lista fundamental de herramientas. Veamos el stack habitual de un proyecto basado en Drupal; ¿Qué usamos?

 

  1. Composer (cómo gestor de dependencias): ya no nos descargamos una carpeta comprimida de Drupal desde su página principal, lo abrimos y pasamos a instalarlo. En su lugar, usamos Composer (https://getcomposer.org/) como gestor de dependencias para que nos construya el proyecto que necesitamos en la versión que queremos usar. Además también lo usamos para declarar parches sobre módulos específicos y hacer que los aplique (usando Git por debajo). 

         Aquí puedes encontrar más información sobre como usar Composer para Drupal: 

  1. Drush (herramienta de línea de comandos, la navaja suiza de Drupal): no siempre estamos haciendo clicks a botones entre interfaces. Lo normal es que lancemos comandos e instrucciones por consola para resolver muchas cosas, así que instalamos y usamos esta mítica herramienta para trabajar en el día a día con Drupal: 

         Aquí puedes encontrar más información sobre como usar Drush y combinarlo con Composer en tu proyecto Drupal: 

  1. Docker / DDEV (Contenedores para desplegar instalaciones de Drupal): hace ya tiempo que no instalamos Drupal sobre nuestro sistema operativo. Ni siquiera el servidor web (Apache o Nginx). De un tiempo a esta parte instalamos herramientas de containerización para tener compartimentados nuestros proyectos en local y los desplegamos en contenedores. Para eso usamos Docker y sobre Docker, usamos una herramienta llamada DDEV que simplifica sobremanera la instalación y despliegue de proyectos Drupal en entornos de desarrollo (DDEV-Local). Para nosotros DDEV se ha convertido en una herramienta estratégica dentro de nuestro stack habitual. Una herramienta para facilitar el día a día que realmente lo consigue. 

         Aquí puedes encontrar más información sobre la instalación y manejo de Docker y DDEV:

De igual manera, DDEV tiene un espacio contribuido en sus propios repositorios con enlaces a artículos y contenidos:  https://github.com/drud/awesome-ddev

Si quieres instalar DDEV en tu equipo local, puedes descargar y usar este script instalador que tenemos compartido en nuestro repositorio de scripting en Github: https://github.com/Solucionex/scripting_for_drupal/blob/main/installers/tools_and_environment/installing_docker_dockercompose_ddev

Solo tendrás que descargarlo bien mediante git clone del repositorio o bien el propio fichero mediante wget https://raw.githubusercontent.com/Solucionex/scripting_for_drupal/main/installers/tools_and_environment/installing_docker_dockercompose_ddev

Luego le das permisos de ejecución al script y lo lanzas y voilá! instalación de DDEV en local dentro de Debian / Ubuntu. También puedes seguir este tutorial paso a paso que publiqué en Digital Ocean:  https://www.digitalocean.com/community/tutorials/how-to-develop-a-drupal-9-website-on-your-local-machine-using-docker-and-ddev

 

6- Sexta anotación: Evita los lugares comunes

Hay una serie de expresiones, ideas y opiniones habituales en un equipo que solo aparecerán si no tiene el conocimiento suficiente sobre Drupal y la cultura interna de la organización no permite que estos déficits se expresen con la suficiente honestidad. Así, conviene tenerlos mapeados convenientemente para una traducción lo más inmediata posible y poder identificar necesidades. Estas ideas y expresiones suelen ser recurrentes en distintos contextos y es importante saber darle la debida interpretación. Veamos algunos de los más habituales.

    1- "Es que Drupal no está preparado para $necesidad": Suele traducirse mejor como “yo no sé como afrontar esta $necesidad desde Drupal”, y en la mayoría de los casos requiere material formativo. Expresa una laguna, una duda, un desconocimiento. Drupal está preparado para muchas cosas y sería bastante extraño que en el contexto del desarrollo web, hubiese algo que haya quedado al margen de Drupal.

    2- "En Liferay esto se podía hacer pero aquí no": Traducir por “he cambiado mi zona de confort habitual y siento confusión”. Esta idea suele aparecer en equipos que han transicionado desde otras tecnologías.

    3- "Drupal es muy inseguro, mira todos los parches que salen": Los parches en realidad solo indican movimiento, no debilidad. Hay equipos de personas dedicados a testear vulnerabilidades de manera pública (https://www.drupal.org/drupal-security-team) y en cuanto detectan algo, crean una solución y la pública. Tu software privativo favorito también es vulnerable, solo que no tú no te estás enterando.

    4- "El software privativo que usábamos antes no tenía tantas limitaciones": O bien no conocías tu software anterior o bien todavía no conoces los límites de este. Con Drupal pueden hacerse muchas, muchas cosas y extendiéndolo todavía más. Adaptándolo a otros enfoques (headless con un frontend externo, por ejemplo) puedes hacer cosas infinitamente más avanzadas. Puedes usar Drupal solo como motor de contenidos en Backend, y servirlos a diversos dispositivos.

Y el gran clásico atemporal, que dejo de propina, para loor y gloria de la posteridad

    5- “Estas teniendo esos problemas en Drupal porque usas Linux” ...pensad que todo lo que se ha anotado en este artículo discurre entre consolas, línea de comandos, software libre y principalmente en entornos Unix (Debian / Ubuntu) o basados en el (MacOs). Cae por su propio peso. No hay mucho más que refutar. 

-----------------------------------------------------

Si has llegado hasta el final de esta guía rápida en forma de artículo, enhorabuena (ha tenido que ser arduo). Ya estás más cerca de comprender bien el universo Drupal...¿Crees que ahora puedes conocer mejor Drupal y su contexto? ¿Qué te has aproximado mejor? Recuerda que puedes escribirnos a info@solucionex.com para consultarnos cualquier duda y desde aquí podemos ofrecerte consultoría y formación.

Saludos,

@davidjguru

 

¡Hasta la próxima!