Como abordar grandes proyectos con Joomla

Escrito por | 02 Julio 2013 | Publicado en Julio 2013
Cuando abordamos un proyecto de desarrollo basado en el CMS Joomla, debemos hacerlo igual que si de cualquier otro proyecto de desarrollo se tratara. Un error muy común es el de comparar los desarrollos realizados con Software Libre por un freelance (en nuestro caso Joomla) con otros proyectos donde intervienen equipos completos de desarrollo.  

Es decir, si necesitamos un equipo de profesionales formado por analistas y programadores, maquetadores, diseñadores, etc... Todos ellos coordinados por uno o varios jefes de proyecto, y deseamos además poder tener un control tanto de la calidad del producto resultante como de la evolución del mismo a lo largo del tiempo para dar respuesta a las futuras necesidades de nuestros procesos de negocio, necesitamos sin duda utilizar alguna de las metodologías existentes para el desarrollo del software, apoyada sobre una estructura hardware que va algo más allá del típico "hosting gratuito".

Software y Herramientas

En la actualidad la tendencia para crear o mantener grandes proyectos es basarse en el Desarrollo Rápido de Aplicaciones, esta es una metodología de desarrollo de software, que implica el desarrollo interactivo y la construcción de prototipos trabajando sobre los siguientes principios básicos:

El objetivo clave para un desarrollo rápido y entrega de un producto de alta calidad es alcanzar un sistema de relativamente bajo coste de inversión.

En el que intentaremos reducir los riesgos inherentes del proyecto partiéndolo en segmentos más pequeños y proporcionanando así más facilidad de cambio durante el proceso de desarrollo.

Y en el que nos orientaremos a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo), promoviendo la participación de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI), herrmientas tipo Computer Aided Software Engineering (CASE), o los sistemas de gestión de bases de datos (DBMS), así como lenguajes de programación de cuarta generación, generadores de código, y técnicas orientada a objetos.

Haremos especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o la excelencia tendrá una menor importancia y se supedita a la primera. Si, todos sabemos que nos gustaría hacerlo al reves, pero ¿no nos debemos a nuestros clientes?

Así mismo el control del proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto empezara a aplazarse, se hará hincapié en la reducción de requisitos para el ajuste, no en el aumento de la fecha límite.

En general usaremos tecnicas de Joint application development (JAD), donde los usuarios estarán participando intensamente en el diseño del sistema, ya sea a través del consenso estructurado en talleres, o por vía electrónica.

Recuerda que la participación activa de los usuarios es imprescindible.

Y por supuesto generaremos la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.

Alguno de los proyectos en los que he participado basados en Joomla han adecuado estas metodologías a las necesidades de los desarrollos, tanto del Framework como del portal de nuestro CMS o sus extensiones, facilitando enormente el éxito de los mismos.

Estructura hardware y servidores

Uno de los primeros pasos para poder comenzar a desarrollar es el disponer de una infraestructura hardware y de servidores bien definida que facilite los siguientes aspectos:

  • Control de versiones
  • Prototipados operativos
  • Despliegues automatizados
  • Pruebas unitarias automatizadas
  • Pruebas funcionales automatizadas
  • Integración Continua

 Para ello configuraremos para nuestros clientes un entorno similar el mostrado en el siguiente gráfico:

estructura

Veamos ahora cada una de las partes con cierto detalle.

El núcleo:

El corazón de todo es un servidor web Nginx. ¿Porqué este y no un servidor Apache? La respuesta es sencilla sobre Nginx podemos configurar un sistema de alta disponibilidad, con balanceo de carga, separando los servidores de contenidos dinámicos de los que únicamente entreguen contenidos estáticos. De manera que, además el sistema quede preparado para una  migración sostenida a la nube. Si necesitaramos Apache por compatibilidad, los montaremos por debajo de los Nginx, o en paralelo para aquellas tareas donde la compatibilidad sea imprescindible.

Es también parte de este corazón es el servidor de MySQL. O más específicamente la granja de servidores que sincronizados entre ellos, que cuando es necesario, dan servicio a los diferentes entornos donde se despliega el portal del cliente.

Un intérprete de PHP, se encargará de la ejecución de las páginas que deba servir Nginx. Con los módulos necesarios para que Joomla pueda desplegar toda la potencia que necesite el cliente, pero eliminando todos aquellos que sin aportar ninguna valor añadido signifiquen un aumento de carga del sistema o el más mínimo riesgo en cuanto a la seguridad se refiere.

Completa, por último este "core", el servidor NFS responsable del intercambio de ficheros entre el resto de los aplicativos que componen el gráfico anterior. La comunicación del "core" con líneas dedicadas de alta velocidad, facilitará la composición de la página solicitada por el internauta en el menor tiempo posible.

La zona de desarrolladores:

Cada desarrollador dispone de un entorno IDE donde se encuentran integradas las herramientas de gestión del control de versiones, así como diversas utilidades que facilitan el desarrollo de las extensiones para Joomla.

Todos ellos centralizados en un servidor GIT que se conecta al servidor de NFS del núcleo para volcar las versiones validadas por cada miembro del equipo .

La zona de Integración Continua:

Se configura una herramienta de despliegue, así como un gestor de Integración Continua responsables de los lanzamientos de las pruebas unitarias (PHPUnit y JUnit) y de las funcionales (Selenium), así como de los despliegues programados entre los diferentes entornos.

De esta manera simplificamos la fase de pruebas unitarias de los equipos de desarrollo en una primera integración entre los diferente desarrolladores, así como las futuras pruebas de usuario al automatizar aquellas pruebas funcionales que son de obligado cumplimiento todas y cada una de las veces que se modifique el proyecto Joomla.

Por último la zona de entornos:

Disponemos de cuatro entornos diferenciados y aislados entre ellos. Al ser Joomla un gestor de contenidos, se produce una situación particular en la retroalimentación desde el entorno de Producción hacia los demás. Es necesario , para la reproducción de determinadas circunstancias que periódicamente se realice una copia con los datos falseados hacia el entorno de Preproducción. Estos facilita la reproducción de las situaciones no deseadas que por el uso se puedan producir por parte de los gestores de contenidos sobre el sistema en explotación.

Un entorno imprescindible el de I+D+I posibilita enormente la evaluación previa de extensiones y soluciones funcionales. Una vez identificadas estas se procede a la repetición de las mismas en el entorno de desarrollo integrándose estas en el ciclo habitual del equipo desde ese momento. Este entorno suele tener un nivel de contaminación alto por residuos resultantes de las constantes pruebas, por lo que existen procedimientos de restauración del mismo desde el entorno de desarrollo, refrescando únicamente aquellos cambios que tras las pruebas de integración ya se encuentra en su fase beta (entorno de preproducción).

Pero centrémonos en el entorno que más estrés recibe por parte de nuestro equipo: El de desarrollo. Un entorno en constante evolución donde se incorporan los cambios tras las pruebas unitarias, y sobre el que se ejecutan de forma automatizada pruebas de integración y funcionales. Un entorno desde el que los desarrolladores reciben información de "debug" exactamente igual que lo hacen de su entorno privado de desarrollo pero con la interacción de sus cambios con el resto de los realizados por todo el equipo.

Un último entorno, el de Preproducción (o beta) facilita que le usuario pueda realizar pruebas exactamente igual que lo haría en su sistema productivo pero sin el riesgo de parar el mismo.

Todos estos entornos se configuran de manera que utilicen bases de datos diferentes (falseando información si así se requiere para ajustarse a la legislación del país del cliente (p.e. LOPD o LSSI en España), servidores de correo (reales o simulados) diferentes para evitar los envío de correos  a usuarios reales durante las pruebas, pero que permitan medir la carga que estos envíos generan, sistemas de copias de seguridad independientes, etc...

Solo de esta manera podemos abordár un proyecto de larga duración y/o latencia bajo Joomla con la misma calidad y seguridad que si lo realizáramos con productos privativos en los que se exigiera este mismo tipo de arquitectura.

No seamos menos exigentes con nosotros mismos por trabajar con licencias abiertas.

Visto 17545 veces Etiquetado como Spanish, Negocio
Pedro F. Vidal Lopez

Pedro F. Vidal Lopez

Simply... I love Open Source... I love Joomla!

I'm collaborating on projects Open Source since 1988 and with the Joomla community since 2005...

Learning English now;-)