Blog

Desarrollando una web con Drupal 8. La arquitectura

23/10/2015

La decisión de la arquitectura para proyectos de drupal 8 ha sido bastante complicada. Tenemos claro que queremos trabajar con profiles igual que hacíamos en drupal 7.

Ahora viene la decisión complicada:

En drupal 7 teníamos esta estructura de directorios para un proyecto:

  • httpdocs: que era la parte que se exponía al servidor web como document_root
  • makefiles: donde teníamos archivos de drush make para construir el código contribuido.
  • drush: con los alias de drush y algunas variables y operaciones propias de cada proyecto.
  • rebuild_info: con la información relativa a los módulos a activar y variables a asignar en el entorno de desarrollo.
  • profile: donde guardamos todo el código custom, los test y la configuración del proyecto, enlazado mediante un enlace simbólico al proyecto.
  • README donde colocamos la documentación relevante.

Esta estructura tiene como ventaja que se puede sacar del control de versiones todo el código contribuido, porque se contiene dentro de una única carpeta (httpdocs o docroot según el proyecto), de manera que para probar que todos los parches y módulos necesarios para que el proyecto funcione solo hay que tener a salvo el directorio sites para no perder los ficheros ni la configuración del settings.php. A partir de aquí se debería poder destruir el directorio httpdocs, volver a contruirlo con los makes, enlazar de nuevo el profile y los sites y todo debería quedar como antes.

El hecho de que esto funcione así da mucha tranquilidad a la hora de tener claro que todos los módulos contribuidos y los parches están documentados. Además da un gran control a la hora de aplicar actualizaciones.

Ahora bien, en drupal 8 surge la duda:

¿Mantenemos esta arquitectura?

Después de darle muchas vueltas hemos decidido mantenerla pero poniéndola en cuarentena. Se puede desarrollar perfectamente un portal en drupal 8 con esta arquitectura pero cuando descargamos drupal 8 vemos que viene ya preparado para que todo se haga de una manera muy parecida…. pero desde dentro del mismo código que te descargas.

Tiene un directorio core en el que están todos los ficheros del core.

Idealmente se podría hacer algo muy parecido si se pusieran todos los módulos y temas contribuidos dentro de modules, themes y se ignoraran a nivel de git:

  • modules
  • themes
  • core

La ventaja que tendría esto es que se podría utilizar el fichero de composer que hay en la raiz de drupal y que se seguiría la arquitectura que trae drupal 8 preparada para el desarrollo.

La desventaja es que al tocar ese fichero de composer ya estaríamos tocando código contribuido y podría suponer un problema a la hora de hacer una reconstrucción completa.

Debo confesar que la decisión ha estado casi completamente equilibrada y que no estoy seguro de que sea la acertada, por lo que agradecería mucho aportes en los comentarios.

También te puede gustar…

Caso de éxito: Binfluencer

Caso de éxito: Binfluencer

Binfluencer es otra de las empresas que ha confiado en ASPgems. En este caso de éxito te contamos nuestra colaboración con ellos.

ASPgems icon
C/ Sextante, 9
28023 Madrid,
España

Hablemos.

A %d blogueros les gusta esto: