Flujos de desarrollo en Drupal: Para ganar, primero hay que invertir!

(This post is also available in English)

Desde el manifiesto ágil del 2001, tomó fuerza el priorizar el software funcional sobre la documentación extensiva. Bajo esta priorización nos acostumbramos a instalar un Drupal, descargar módulos, activarlos y en pocas horas tener un prototipo funcional desde el que seguiríamos el desarrollo de nuestro sitio.

¿Cómo mantendremos ese código en el futuro?

Eventualmente nos encontraremos con varias docenas de módulos, no es extraño tener un centenar de ellos funcionando en una instalación de Drupal, especialmente un commerce.

El problema es que al tener tanto código desestructurado, en el futuro será complejo implementar cambios. Eso atenta contra otro de los valores del manifiesto; que es nuestra capacidad responder al cambio.

Pero hay soluciones.

En este articulo te explicaré como implementar algunas técnicas en tu flujo de desarrollo, que si bien nos costarán un poco más de trabajo inicial, en el largo plazo nos ahorrarán mucho tiempo y complicaciones.

drush make: De muchos de megas a pocos kilos

Drush es un complemento a Drupal que nos permite ejecutar múltiples tareas a través de la interfaz de comandos, es “la navaja Suiza de Drupal”. Una de sus multiples funcionalidades es el commando drush make, que puede crear una base de código “lista para usar” descargando el Drupal core y módulos desde drupal.org o repositorios git, e incluso aplicarle patches descargados o locales. En términos prácticos es una forma de distribuir o almacenar un paquete complicado de Drupal en un solo archivo de texto.

Por ejemplo:

api = 2
core = 7.x
projects[drupal][version] = 7.38
; módulo views
projects[views][version] = 3.11
; theme bootstrap
projects[bootstrap][version] = 3.0

Un archivo make como este, descargará el drupal core 7.38, el módulo views 7.x-3.11 y el theme bootstrap 7.x-3.0, y la posibilidad de añadir comentarios nos permite explicar para que utilizamos cada módulo o conjunto de módulos, así cuando tengamos docenas de éstos, podremos navegar este archivo con facilidad.

Features: De SQL a php

Features2El módulo features junto strongarm y features_extra nos permiten “bajar” las configuraciones que están la base de datos, a código.

A través de una interfaz gráfica bajo /admin/structure/features podrás exportar distintos componentes (views, contextos, CCK fields, rules, etc) a conjunto de archivos (feature), él que prácticamente se comporta como un módulo más de drupal, que puedes usar en cualquier otro Drupal nuevo o en operaciones, con la posibilidad de no solo activarlo, sino también de actualizarlo o incluso revertirlo.

La idea es entonces ir guardando las funcionalidad que logras a través de módulos y configuraciones en features, haciéndolas así verdaderamente independientes de la base de datos, relegando el rol de ésta a un mero almacén de contenidos y no funcionalidades. De esta forma aquellas features que crées, las podrás usar en distintos entornos (local, dev, test, ops) e incluso en otros proyectos, hasta otros clientes.

¿Empiezas a visualizar cuánto tiempo puedes ganar?

Si se trata de agilidad, git te da alas:

Si aun no estas utilizando git en tu proceso de desarrollo, pausa todos los desarrollos que estés realizando, estudialo –dicen que en piratebay hay tutoriales excelentes– y luego retoma tus proyectos con git, a la semana ya me lo agradecerás, en serio. Si git ya es tu copiloto, te puedes saltar saltar este punto.

Git es una aplicación para realizar control de versiones, básicamente se configura para monitorear un directorio que contiene tu código fuente al que se le llama repositorio (en el caso más simple sería tu public_html). Y sobre este directorio, a medida que vas implementando cambios, ejecutas un commit que una especie de guardado de cada revisión.

Los commit tienen un espacio para un titulo y una descripción, y pese a que al principio te puede parecer tedioso e incluso una pérdida de tiempo completarlos, en el tiempo, cuando tu proyecto se vuelva complejo –y especialmente cuando tengas que hacer roll backs (restaurar revisiones previas)–, te será extremadamente útil y te ahorrará mucho más trabajo del que te cuesta escribir los títulos y eventuales descripciones de tus commit.

Tip Pro:
En algunos proyectos vale la pena llevar el git, los comentarios en código y documentación interna inglés, así podrás integrar desarrolladores overseas.

Otra de las maravilla de git, es su función de branching, que te permite trabajar varias ramas paralelas de tu mismo proyecto llamadas banches, permitiendo trabajar paralela e independientemente en distintas funcionalidades o correcciones a tu código. Cuando estés satisfecho con el trabajo en tu branch, realizás una operación llamada merge, que integrará todas las modificaciones de tu branch, a tu rama principal.

La tercera función clave de git es push, te permite enviar tu repositorio a un servidor de git, lo que en conjunto con el comando pull –que trae los cambios nuevos del servidor a tu computador–, hace posible el trabajo en paralelo de varios desarrolladores en un mismo proyecto. Bitbucket es mi proveedor gratuito favorito, Github es popular también pero debes pagar para tener un repositorio privado.

Por último, si eres de los que les intimida la interfaz de comandos, o simplemente no te acomoda, te invito a revisar las alternativas gráficas para git.

En mac específicamente te recomiendo Tower, en mi caso lo uso porque al tener una interfaz gráfica amistosa, tiendo a escribir más y mejores mensajes en mis commits.

Ensamblando todas las piezas: adaptate a tu hosting

En el escenario más simple, suponiendo que estas en un hosting clásico, el uso de git queda totalmente a tu discreción y tienes que ordenarte tu mismo en ejecutar commits periódicamente en tu entorno local. Deberías organizar tu trabajo en al menos dos directorios, un source y un build. En el primero mantendrás tu project.make y los módulos, themes y patches propios; en el segundo se “compilará” tu drupal operativo.

Esta tarea la podrías hacer manualmente, pero es absurdamente tedioso. Por lo que al menos te recomiendo hacer un archivo batch que la haga por ti, limpiando el directorio build primero, luego ejecutando el drush make, y finalmente copiando o creado vínculos simbólicos a tus módulos y themes propios.

Si eres amigo de grunt, te recomiendo drupal-tasks; es un plug-in para automatizar el build y testing de drupal, incluso viene tiene un generador Yeoman que puede hacer el scaffolding inicial del proyecto por ti.

Pantheon.io es una plataforma de hospedaje que te permite acceder directamente a través de git y gestionar “arriba” los banching y commits, generando copias independientes de cada entorno para cada branching. Si ya operas en Pantheon, pero no estas utilizando estas capacidades te recomiendo darle una miradas a las slides de Saul Willers en la junta de drupal Chile Junio 2015.

Para mi gusto Platform.sh tiene mejores tarifas y características que Pantheon, por lo que es mi favorito actual. En este caso, una vez hayas creado tu proyecto a través de la interfaz web, deberás bajarte el cli de Platform (interfaz por comandos). Luego ejecutando un platform get, éste descargará el proyecto y lo organizará en cuatro directorios:

  • builds: Almacena los distintos builds que generes.
  • repository: Almacena solo tu código fuente original.
  • shared: Almacena el directorio files de drupal y tu settings.local.php
  • www: Es un link simbólico al último build (para la comodidad de tu servidor web local).

Asumiendo que deseas desarrollar local, deberás crear un archivo settings.local.php en tu directorio shared con al menos los datos de tu SQL, algo así:

<?php // Database configuration.
$databases['default']['default'] = array(
  'driver' = 'mysql',
  'host' =  'localhost',
  'username' =  'user',
  'password' =  'pass',
  'database' =  'db-name',
  'prefix' =  '',
);

Y por último deberás configurar tu servidor web local para utilizar www como la raíz de tu sitio, de esta forma siempre estará trabajando sobre tu ultimo build.

Ahora que tienes todo configurado, debes crear un archivo project.make en la raíz de directorio repocitory. Platform hará el trabajo por ti, ya sea cuando hagas un build local a travéz del comando platform build desde el directorio del proyecto. O cuando se ejecute el build en sus servidores, lo que ocurre cada vez que realizas un git push; Platform recibe tu código fuente y genera un build, desplegandolo a un entorno único.

Si te gustan las complicaciones, puedes personalizar muchísimo el procedo de build en Platform, al punto de compilar tus less o sass en sus servidores automáticamente al realizar un git push.

Tip Pro:
Puedes poner un archivo php.ini en la raiz de tu directorio repocitory, para sobrescribir los valores por defecto de Platform.

Conclueyendo:

Con un poco más de trabajo inicial en el setup de tu flujo de trabajo para un proyecto, puedes conseguir grandes ahorros de tiempo a futuro, incrementando tu eficiencia, velocidad y calidad en la respuesta a los requerimientos de tus clientes.

Ahora que entiendes como , te planteo las siguiente preguntas:

  • ¿Con cuál de tus proyectos Drupal podrías partir experimentando estas formas de trabajo?
  • ¿Cual de tus proyectos se beneficiaría más si implementas estas metodologías?
  • ¿Que harás con el tiempo que ganes? En serio, inviertelo con sabiduría. El tiempo es el activo finito más valioso que tenemos en la experiencia humana.

Te invito a compartir este post con tu equipo de trabajo o colaboradores. Y si implementas estas metodologías, me gustaría mucho oír como te resulto, no dudes en contactarme cuando lleves 2 o 3 meses utilizandolas y me cuentas.

Advertisements