Arquitectura de proyectos en drupal (según ASPgems)

Desde que empezamos a desarrollar en drupal hace ya unos años, hemos ido mejorando poco a poco nuestra arquitectura de proyectos. Los criterios que hemos buscado para ir metiendo nuevas mejoras han sido siempre:

  1. Mejorar la seguridad de nuestras aplicaciones
  2. Aumentar la producitvidad de los desarrolladores
  3. Facilitar la mantenibilidad de los proyectos
  4. Minimizar la aparición de bugs
  5. Que cada nuevo cambio sea retrocompatible con lo anterior en la medida de lo posible

Pues bien, creo que es hora de dar un repaso a cómo es nuestra arquitectura actual

Las características principales que tiene nuestra arquitectura son las siguientes:

  • Solamente se mete mete en el repositorio el código que hayamos escrito para el proyecto.
    Es decir, todo el cógigo contribuido se documenta y declara mediante ficheros de make, de esta manera nos aseguramos de que en un vistazo tenemos controlados los módulos y parches de seguridad aplicados a un proyecto.
  • Cada proyecto actúa sobre una distribución propia.
    En lugar de partir de una distribución precocinada, cada proyecto tiene su propia distribución que se genera automáticamente con una serie de módulos y configuraciones comunes a todos los proyectos. Esto nos ayuda a tener muy controlado que toda la estructura de la aplicación está correctamente versionada y exportada a código versionable.
  • Utilizamos el módulo drush rebuild para controlar las diferencias de configuración entre el entorno de desarrollo y los demás.
    Hay módulos que se necesitan para desarrollar pero nunca deben llegar a producción, variables que deben ser distintas, módulos que deben desactivarse en desarrollo, etc. Para gestionar todo esto usamos ficheros de configuración por entorno.
  • Utilizamos alias de drush para controlar los diferentes entornos.
    Gracias a los alias de drush, podemos controlar los pasos a producción, el estado del proyecto en los diferentes entornos y probar los despliegues antes de hacerlos en real.
  • Utilizamos newton como repositorio de todos nuestros scripts básicos
    Poco a poco estamos construyendo una serie de comandos de drush que nos permiten automatizar tareas, de esta manera no solamente las hacemos más rápido, si no que las hacemos sin errores y sobre todo las hacemos siempre igual. newton puede encontrarse aquí: https://github.com/alvar0hurtad0/newton/tree/7.x.2.x
  • Utilizamos casperjs como herramienta para hacer test automáticos.
    Después de dar muchas vueltas hemos encontrado en casperjs la manera que más encaja en nuestros proyectos para hacer test automáticos. Además hay un módulo de drush que integra muy bien los test con drupal para hacer operaciones como autenticar usuarios para pasar test.
  • Utilizamos features genéricas y features por funcionalidad.
    Este modelo intenta coger lo mejor del modelo «una feature por cada tipo de elementos» y del modelo «separamos las features por funcionalidad» tenemos una feature genérica por cada tipo de elementos con configuraciones generales y features dependientes para cada funcionalidad.

Poco a poco iré escribiendo una serie de post describiendo estos puntos con más profunididad y por supuesto estaremos encantados de que alguien haga críticas constructivas y sugerencias.