Drupal development workflows: To yield returns, you need invest early

(Este post fue originalmente escrito en español)

Since the agile dev manifesto of 2001, it took force prioritizing functional software over extensive documentation. Under this priority, we got used to install a Drupal, download some modules, activate them and within hours have a working prototype from which would continue the development of our site.

But, how to keep the code in the future?

Eventually we will have many dozens of modules, it is not uncommon to have a hundred of them in a Drupal installation, especially in a commerce.

The issue about having unstructured code, is in the future, because implement changes will become complex and slow without breaking what is already done. This goes against one of the values ​​of the manifesto; The ability to respond to change.

But fear not, there are solutions.

In this article I will explain how to implement some techniques in your development workflow that although they are a little more initial work, in the long run it will save much time and hassle.

drush make: From many megas a few kilos

Drush is a Drupal tool that allows us to run multiple tasks through the command line interface (CLI), it is “the Swiss Army knife of Drupal.” One of its many features is the command drush make , it can create a code base “ready to use” downloading the Drupal core and modules from drupal.org or git repositories, and even apply patches downloaded or local. In practical terms it is a way to distribute or store a complicated package of Drupal in a single text file.

For instance:

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

A make file like this, will download the core drupal 7.38, the views module 7.x-3.11 and bootstrap theme 7.x-3.0. Please notice the ability to add comments, allows us to explain to use each module or set of modules, when we have dozens of these, we can humanly navigate this file.

Features: From SQL php

The features module along with features_extra and Strongarm and allow us to “download” the settings from database to code.

Through drupal admin at /admin/structure/features, you can export individual components (views, contexts, CCK fields, rules, etc) to file set (feature), which practically acts as a standard drupal module, which you can use in any other Drupal, brand new or in operation, with the ability not only enable it, but also to update it or even reverse it.

The idea is to save functionality that you create through modules and configurations into features, thus making them truly independent of the database, relegating db to the role of mere content store and not functionality. Thus those features that you created, you can use them in different environments (local, dev, test, ops) and even in other projects, or other clients.

Do you begin to visualize how long can you win?

If it’s about agility, git gives you wings:

If you’re not using git yet at your development, pause all you developments, study it –I hear there are excellent tutorials at piratebay–, and implement git over you projects, in a week and you’ll thank me, really. If already git is you co-pilot, you can skip to next point.

Git is an application for version control, basically you set it up to monitor a directory that contains your source code that is called repository (in the simplest case would be your public_html). And on this directory, as you go making changes, run a commit command that kind of save of each revision.

The commit have a space for a title and a description, and although at first it may seem tedious and even a waste of time to write them, in time, when your project becomes complex –and especially when you have to do roll backs ( restore previous revisions)–, it will be extremely useful and will save a lot more work than it costed originally to write them.

Pro Tip:
Even if English is not you native language, in some projects is worth keeping the git comments, internal code and documentation in English, so you could integrate developers overseas to you proyect.

Another marvel of git is its branching function, which allows you to work in several parallel branches of the same project, allowing you to work parallel and independently in different functions or corrections to your code. When you’re satisfied with your work in branch, you perform a merge operation, which will integrate all changes from your side branch, your main branch.

The third key feature is git push, allows you to send your repository to a git server, which together with the pull command, which brings new changes to your computer from server, enable multiple developers to work in parallel in the same project. Bitbucket is my favorite free provider, Github is popular too but you must pay to have a private repository.

Finally, if you are someone who are intimidated the command interface, or simply does not suit you, I invite you to try graphical alternatives to git.

If you a mac user, let me recommend you Tower , in my case I use it because having a friendly graphical interface, I tend to write more and better messages on my commits.

Putting all together: Adapt to your hosting

In the simplest scenario, assuming you are in a classic hosting, using git is completely at your discretion and you have to discipline you self to run periodically git commits in your local environment. You should organize your work in at least two directories, one for the source and the other for the build. In the first you keep your project.make and you custom modules, themes and patches; the second will be “compile” your final drupal.

This task could be done manually, but is absurdly tedious. So at least I recommend you do a batch file that do for you each time, cleaning the build directory first, then running the drush make, and finally copying or creating symbolic links to your own modules and themes.

If you’re a friend of grunt, I recommend drupal-tasks; It is a plug-in to automate the build and testing of drupal, it even comes with a Yeoman generator that can do the initial project scaffolding for your.

Pantheon.io is a hosting platform that allows direct access via git and manage “up there” the commits and banching, generating independent copies of environments for each branching. If you already work in Pantheon, but you are not using these capabilities, my advice it checkout the Saul Willers slides on the topic exposed at June 2015 drupal Chile meet up.

In my current view Platform.sh has better rates and features than Pantheon, making it is my current favorite. In this scenario, once you have created your project through the web interface, you must download the Platform CLI (command line interface). Then executing a platform get, it will download the project and organize it into four directories:

  • builds: Stores the different builds that you generate.
  • repository: Stores your original source only.
  • shared: Stores drupal’s files directory and your settings.local.php
  • www: It’s a symbolic link to the latest build (for the convenience of your local web server).

Assuming you want to develop local you should create a settings.local.php file in your shared directory with at least your SQL credentials, like this:

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

And finally you need to configure your local web server to use www as the web root of your site, in this way it’ll always be on your latest build.

Now that you have everything set up, you must create a file project.make at you repocitory root directory. Platform will do the work for you then, either when making a local build trough platform build command at the project directory. Or when the build to run on their servers, which occurs every time you do a git push, Platform receives your source code and generates a build, deploying it in a unique environment.

If you like complications, you can highly customize the build in Platform to even compiling your sass or less on their servers to automatically when run a git push.

Pro Tip:
You can place a php.ini file in the root directory of your repository, to override Platform’s default.

In conclusion:

With a little more work in the initial setup of your workflow, you can get great savings of time in the future for a project, increasing your efficiency, speed and quality of response to you customer’s requirements.

Now you get this ideas, ask you self following questions:

  • Which of your Drupal projects could from experiencing these forms of work?
  • Which of your projects would benefit more if you implement these methods?
  • What will you do with the time that you win? Seriously, I invest it wisely. Time is the most valuable asset we have in finite human experience.

I invite you to share this post with your team or collaborators. And if you implement these methods, I would like to hear how it turn out, do not hesitate to contact me when you are 2 or 3 months using this methods.

Advertisements

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.