Metodología de trabajo para proyectos php

Un usuario de Linkedin me hacía las siguientes preguntas hace unos días.

To manage Drupal Core changes and sites development

To orchestra all The tools to build, provision, test and deploy Drupal Core and sites changes.

To deploy on testing/staging enviroments for validation by qa team and owner.

Es el propietario de un un servicio de integración continua de proyectos escritos en PHP, esta claro que su intención no es tanto aprender de mi como picarme para enseñarme su producto e intentar venderlo.

Aprovechando esas preguntas, me puse a pensar y darle vueltas a la cabe y he terminado escribiendo este artículo, no busco que todos copiéis y uséis la misma metodología, ni mucho menos, pero puede que haya cosas interesante que podáis incorporar al día a dia vuestro.

Como suele comentar Carles, uno de los grandes problemas de Drupal es que tiene la configuración en la base de datos. Pero a pesar de que la configuración final y que se consulta está en base de datos se puede tener esa misma configuración en código, aunque solo sirva a modo de mensajero. Las opciones para tener la configuración en código son las siguientes:

  • Usar la API de Drupal para escribir todo aquello que necesita el proyecto y no viene por defecto en Drupal o en módulos (Tipos de contenidos/entidades, campos, vocabularios, permisos, etc…) Esta forma de trabajar a veces es algo más lenta que otras opciones.
  • Features y Ctools.
  • Features permite exportar a código configuraciones que se han realizado en Drupal, es la forma estándar de trabajar hoy día.
  • Ctools permite exportar a código algunas de las configuraciones de Drupal, no es tan potente como features porque no soporta tantas opciones. Cuando utilizo Views prefiero exportar las configuraciones con Ctools y montar un módulo custom y dejar las vistas exportadas en /sites/all/librareis/Views/ y que el módulo las lea desde esa localización.
  • La tercera opción es usar Hook_updateN, este Hook permite realizar actualizaciones en nuestro site. Esta opción, como la primera, requiere que conozcas la API de Drupal.
  • Es necesario usar un software de control de versiones que permite tener controlado nuestro código. Existen varios softwares de control de versiones yo recomiendo Git, además existen empresas como github y bitbucket que te permiten tener proyectos gratuitos y de pago.
  • Existen dos herramientas de consola que hay que conocer, Drush y DrupalConsole (sólo en D8). Un buen profesional tiene que conocer ambas herramienta
  • Drush es la consola por defecto, nos permite interactuar plenamente con Drupal desde la consola, soporta muchas funcionalidades y se le pueden desarrollar nuevas funcionalidades. Existe un libro de Drush en Pack Publish.
  • DrupalConsole, la parte más “fuerte” de este proyecto es la capa de scafolding que tiene, y que permite crear módulos, o el esqueleto de módulos en minutos desde la consola sin picar código. DrupalConsole tiene más opciones similares a Drush.
  • A nivel de IDE consideró que cada profesional tiene que usar la herramienta que mejor utilice, imponer herramientas es un error.
  • A nivel de entornos de trabajo, para trabajar en local recomiendo usar Vagrant, con Vagrant montas máquinas virtuales sin necesidad de UI con una configuración lo más cercana a los servidores de desarrollo y producción. Para provisional estas máquinas virtuales se pueden usar muchos sistemas, yo suelo utilizar Ansible para las máquinas locales, pero existen otras opciones. La más sencilla de todas ellas es usar la UI https://puphpet.com/.

Para orquestar todo esto trabajo con Git, un gestor de proyectos (redimen en mi caso, existen otros), capistrano, y metodología ágil para planificar los sprints incluso en proyectos en los que yo estoy.

Si quieres probar Redmine puede usar el servicio gratuito https://www.hostedredmine.com/

La forma de organizar el trabajo en  Git es mediante el uso de ramas locales y ramas remotas. La metodología es la siguiente.

  • Existe la rama master que es la que se despliega en producción.
  • Existe la rama dev que se utiliza en el entorno de desarrollo. En esta rama configuró un Hook precomit para que revisen el código (Coding standard) nuevo, en caso de no estar bien no deja hacer el commit a la rama. Tengo pendiente de ver si se puede usar Los Hooks pre commit para lanzar test locales, en mi caso los test montados en Casperjs.
  • Existe la rama testing que se utiliza en el entorno de QA.
  • Existen ramas locales para ir desarrollando funcionalidades, estas ramas se sacan de maste.
  • Una vez se ha desarrollado la funcionalidad/tickect/bug en la rama local se hace un merge con el entorno de dev, si en el entorno de dev no se rompe nada se mergea en testing y se lanzan los test.
  • Las ramas locales son una por cada ticket/bug/etc, mi recomendación poner el id del ticket-nombre del ticket: 45324-Add_options_to_news.

Recomiendo la lectura de estos dos artículos donde se explican muy bien como usar Git con ramas y con tags.

La gestión de tareas las realizamos mediante Redmine, pero se pueden usar otro software para este fin, el que mejor se amolde a la forma de trabajar el equipo.

Capistrano es la aplicación que se encarga de ejecutar las tareas de despliegue de código, existen otras aplicaciones como Deployer, RocketeerRobo, etc, escritas en Php que sirven para realizar lo mismo. En nuestro caso usamos Capistrano porque TCE lleva más tiempo trabajando con Ruby y es una App de cabecera para desplegar Rails. Tiene sus inconvenientes, hay que hacer en Drupal cosas que se salen de la norma y son más propias de Rails.

Utilizamos una metodología Ágil para definir sprints de una semana de duración.

Testing, se utilizan Hooks post commit que se lanzan cuando se ha desplegado en la rama de test y ejecutan los test, luego escriben en un log, mejor implementar Jenkins.

Algunas pinceladas para autónomos.

Para los trabajadores autónomos cuyos clientes no tienen grandes presupuestos y no pueden implementar un sistema tan complejo como Capistrano o similares recomiendo  Git-ftp , que permite desplegar vía ftp lo que tienes en el repositorio de git.

También para proyectos en los que se quiere tener repo privado y no se quiere pagar lo que cuesta github (10€/mes) Bitbucket ofrece repositorios privados, con límite de 5 usuarios. Pero siempre hay que usar un control de versiones.

Para la gestión de tiempos recomiendo la herramienta toggl, existen otras, pero esta es la que más me gusta.