Arquitectura Drupal ~ Backup Principal 2010

Las primeras veces que te acercas a Drupal, no consideras su estructura como un enclave importantísimo para poder gestionar múltiples portales.

Los propios creadores de Drupal incluso empiezan a orientarnos de las posibilidades y de la importancia de una buena arquitectura de ficheros.

El ver que es un grave error meter todo en "modules". La oportunidad de clasificar en "sites/all/modules" distintos enfoques y distintas agrupaciones de módulos.

Esa capacidad para discernir las necesidades comunes de las opciones específicas para uno u otro portal es arquitectura.

Es importante hacer un enfoque adecuado de los portales que queremos desplegar y es trascendente entender el enfoque libre y recomendado por Drupal, donde en vez de buscar una guerra individual, se apuesta por una compartición de conocimientos y responsabilidades en el desarrollo.

Lo que hemos denominado Metodologías Ágiles Colaborativas, donde tu éxito depende del éxito de otras empresas y retunda en el completo éxito del producto.

Siguiendo esta filosofía, la gestión de portales no debería ser un control de versiones, pues ya el propio producto dispone de su propio control de versiones.

Los cambios o mejoras deberían hacerse en consonancia y acuerdo con los propios responsables de esos módulos o temas. Es esta idea la que nos infunde Drupal, y además es la más adecuada para asegurar los criterios de calidad del software.

Por tanto podemos ver como estructura ideal una gestión de portales que no tiene por qué ser gestión de versiones.

En esta estructura tenemos una parte relacionada directamente con el producto como son las carpetas :

-"includes"

-"scripts"

-"profiles"

-"modules"

-"misc"

-"themes"

La misma podría ser una serie de "links simbólicos" que apuntan a la versión más moderna y estable del producto.

Por tanto delegamos parcialmente en files y de manera más general en sites la personalización del producto.

Dentro de files podemos plantear una estructura común con personalizaciones para documentos como iconos, logos e imágenes :

/files/

Esta ruta se puede parametrizar para conseguir un acoplamiento más optimo de componentes comunes.

En la otra linea, en sites tenemos la siguiente estructura ya aportada por Drupal

/sites/all/ --> Para todos los portales

/sites/default/ --> Configuración por defecto

Como bien dije esta estructura incrementa la complejidad del portal y no nos permite hacer un enfoque de simplicidad.

En dicha estructura tendríamos, por ejemplo tres sites :

sites/site1

sites/site2

sites/site2

sites/all

sites/default

Como se puede comprobar todo está dentro del mismo sites.

Nosotros preferimos ver el producto de forma más sencilla, donde toda la estructura siempre sea similar sea cual sea el site y donde los cambios de entorno sean totalmente transparentes a la estructura interna:

En nuestra visión tendremos :

sites/default --> Sólo configuración

sites/all --> Componentes comunes y personalizados

Esta estructura será común en todos los portales.

Hemos hablado de las relaciones entre componentes, pero también hay que señalar la organización de los mismos.

Conseguir un sistema que permita una sencilla localización de los componentes y una sencilla incorporación a un entorno de desarrollo de dicho componente o funcionalidad que agrupe un abanico de componentes es mérito de una buena arquitectura.

Sin duda a nivel estructural un sistema de vínculos simbólicos facilitan dicha labor.

Comentaremos a continuación la estructura recomendada a Vector SF y otros colaboradores para Red.es y la que se está siendo usada en los servidores Brqx.

La estructura tiene un carácter de encaje inequívoco en cualquier sistema. El vocablo inicial "brqx" independientemente que sea identificativo, cumple con dos propósitos :

1.- Nunca se confundirá con un directorio de cualesquiera sistemas donde se instale ( Unix, Mac, Windows ).

2.- Nunca se confundirá con ningún proyecto definido, pues nunca se realizará ningún proyecto que se llame brqx.

El segundo vocablo de la cadena define el nivel :

- Base : Nivel de productos ( Products level )

- Lnk : Nivel de enlaces (Link level )

- Proy : Nivel de proyectos (aquí el inglés es distinto : Project Level)

- Pers : Personalizaciones

- www : Nivel final de los sites ( Web level )

El tercer vocablo de la cadena define el producto. Partimos de Drupal, pero la estructura está pensada para adaptarse a cualquier producto.

/brqx/base/drupal

El cuarto vocablo define la versión del producto. Se antepone una letra debido a que muchos sistemas tienen problemas si una carpeta comienza por número.

- v50

- v60

- v70

Una vez seleccionada la versión se han definido tres niveles:

- core ' Core invariable de Drupal

- modules ' Módulos de Drupal

- themes ' Temas de Drupal

De momento no vamos a ahondar más en la estructura. Simplemente vamos a indicar un ejemplo de la misma:

/core

/core/v612

/core/v615

…

/modules/abc/c/captcha/captcha_2_1

Hablamos ahora del nivel 2.

En este nivel indicaremos los componentes que están certificados y/o las versiones finales que se están usando.

La ruta inicial es similar:

/brqx/lnk/drupal/v60/modules/abc/c/captcha

Aquí se indicarán los núcleos funcionales, formados con enlaces (versiones ya certificadas).

Podemos ver el núcleo bas (base de módulos) que define la funcionalidad básica exigida para todos los portales de la arquitectura.

La ruta de esta funcionalidad común es:

/brqx/proy/drupal/v60/base

Los módulos que lo forman:

a/ajax ' /brqx/lnk/drupal/v60/modules/abc/a/ajax

c/cck ' /brqx/lnk/drupal/v60/modules/abc/c/cck

...

Esta información actualmente está obsoleta, pero sin duda enseña un camino a la hora de organizar un completo y complejo enfoque arquitectónico válido para un sistema de desarrollo multi site con una filosofía de simplicidad.

La ventaja de usar una estructura homogénea es que los procesos se pueden automatizar, por tanto tanto aplicaciones como Drush como nuestra arquitectura de scripting nos permite una agilidad en la elaboración de sites fuera de lo común.Aunque no está totalmente actualizada, dicha arquitectura es descargable desde internet :

Scripting Unix Brqx

Las políticas de scripts permiten dar una agilidad que no se pueden obtener en un proceso web. Drupal lo sabe. Los drupaleros lo saben.

Le invito a aprender a crear shell scripts, a automatizar procesos, a personalizar entornos.

Es tanto lo que hay que aprender que engrandece el producto final.

Hemos sido todos participes de una documentación inadecuada en la mayoría de los proyectos. Excesiva, nada práctica, demasiado completa.

El objetivo es preparar una documentación más cercana a las necesidades del cliente, una documentación que se abstraiga de detalles innecesarios y se acerque a los objetivos reales de cada proyecto.

Contamos con un sistema que permite representar con sencillez casi cualquier proyecto web. Esta metodología está parcialmente detallada en nuestra web de Metodologías Ágiles.

Queremos minimizar todos los documentos que se involucran en un proyecto y transformar el sistema de documentación tradicional en un sistema mucho más ágil compuesto de documentos totalmente operativos y un sistema documental que aporte toda la información totalmente categorizada y que soporte los aspectos documentales de cada proyecto.

Es hora de olvidarse de documentos Pdf, Word de innumerables páginas. Es el momento para enfocar adecuadamente las dudas y desplegar un sistema que permita agilizar las consultas, evitar redundancia y apostar por la filosofía de "documentos vivos".

Este papel es vital para una buena arquitectura. Debemos analizar las necesidades de cada rol y preparar una documentación acorde a los mismos y envuelta en un sistema ágil, intuitivo y muy bien categorizado.

Por tanto la definición de las abstracciones necesarias para lograr este objetivo tanto a nivel de contenidos como a nivel de documentación final será otro de los parámetros a considerar en una arquitectura de Portales.

Es una norma universal en la programación, el intentar identificar la funcionalidad de las variables, las funciones, las aplicaciones,etc.

Esta identificación implica un nombramiento buscando la simplicidad y la caracterización máxima de los componentes.

El objetivo es luchar por un sistema mantenible que implique el menor esfuerzo para conocer las funcionalidades implementadas.

Por tanto, aparte de apostar por una gestión documental, también debemos considerar el nombramiento adecuado de los componentes como otro punto importante para mantener una arquitectura adecuada.

Por ejemplo, en una vista deberíamos sólo con el nombre de la misma conocer :

- Que tipo de vista es, enfocando el tipo al formato de la misma.

- Qué contenidos va a mostrar

- Si va a recibir parámetros y cuántos serían

- Si va a pertenecer a un tipo de datos o es una vista general

Toda esta información debería dárnosla el nombre de la vista.

¿ por qué es importante seguir sistemas de codificación completa ?

Porque nuestro objetivo es poder reutilizar esas mismas vistas y poder ser capaces de diagnosticar si su funcionalidad nos es válida o no sin tener que llegar al momento de edición.

Sin duda éste y muchos otros parámetros arquitectónicos empiezan a vislumbrar su sentido cuando el número de vistas y el número de portales se incrementa notoriamente.

No es nada nuevo, estas técnicas están ya contrastadas en metodologías de sistemas, en buenas prácticas de programación, en enfoques metódicos tan actuales como CMMI e Itil, son características comunes de cualesquiera arquitecturas.

El producto en cuestión es bastante complejo, pero esa complejidad es un desafío continuo y una base constante de la capacidad del mismo.

Sin duda un producto sencillo, difícilmente puede ser un producto de calidad, pues a medida que se va incrementando el abanico de funcionalidades, va creciendo en igual medida su complejidad.

Es por ello que debemos considerar una buena elección de módulos, de componentes.

Es transcendental analizar las necesidades hardware para los portales, la memoria y la configuración de los sistemas. Los mecanismos de caché. Los módulos que puedan incrementar esa eficiencia.

Y por supuesto hacer un enfoque global considerando las necesidades actuales y el estado del arte del producto.

Si usamos una versión 5.x sabemos que no podemos usar una versión de php 5.3. Se ha comprobado inestabilidad con módulos como Content Templates. As su vez hay módulos que únicamente están para otra versión, otros que no mantienen continuidad.

Es importante hacer estudio continuo de todos los módulos y opcodes que requiere el producto.

A su vez es trascendente considerar que un sistema no es sólo Drupal.

Hay grandes avances para conseguir un sistema más eficiente tanto por parte de Acquia como por otras empresas como Chapter 3 que invitan a apostar por un sistema con Mercury.

Pero en ese sistema es muy complejo unirlo a un panel de control . De momento no hay instrucciones precisas para instalar Mercury con Whm/Cpanel, por tanto debemos considerar las necesidades del portal para plantearnos si realmente podemos usar Mercury entero o bien sólo Varnish, Memcached, Pressflow, etc. Es una prueba de que el estado del arte de estas tecnologías está continuamente cambiando, por tanto es muy importante tenerlo en cuanta para ajustar las necesidades del sistema a las configuraciones más adecuadas para el mismo.