Calidad e Integración Continua

Buenas a todos.

A raiz de otro hilo sobre uso de herramientas de edición, surgió la propuesta de abrir un nuevo hilo sobre staging. Me pareción interesante, pero he decidido finalmente abrir uno sobre calidad e integración continua con un objetivo doble: orientar a las compañías o equipos de desarrollo que quieran implementar técnicas de calidad y reunir consejos de otros que hayan seguido caminos distintos, otras herramientas y otras metodologías.

Mi empresa, que tuvo una rápida expansión (de uno a doce programadores en poco más de un año), empezó a acumular problemas de integración de las partes desarrolladas por cada uno de los programadores. El escenario era el siguiente:

Los programadores commiteaban el código a medida que se iba desarrollando en el repositorio. No había control de calidad, más allá de las pruebas realizadas por el propio desarrollador. No había tests automáticos, ni estándares, ni separación de entornos. Desde la máquina local se vertía código a un servidor de pruebas, y de allí se desplegaba al entorno de producción. La comunicación era intermitente. No había control sobre lo que hacían tus compañeros, más allá del historial de subversion. No se puede negar que el desarrollo era realmente ágil, pero los bugs, incoherencias y problemas de integración eran constantes.

Cuando el departamento se hizo lo suficientemente grande, mejorar en este aspecto se convirtió en una prioridad. Se constituyó un equipo de QA (al principio formado por una sola persona), que se encargaría de investigar, implantar sistemas de integración contínua, establecer metodologías y abrir brecha en la disciplina de los programadores. Estos fueron los pasos seguidos en dos meses, más o menos en orden de instauración:

Coding Standards
Se instaló la herramienta PHPCodeSniffer con el estándar de Drupal. Tuve que realizar algunos ajustes sobre el script y eliminar algunos warnings y errores demasiado estrictos. Se incrustó la herramienta en el hook pre-commit de subversion, de modo que actualmente es imposible commitear código que no cumpla con los estándares.

Doxygen
Instalamos Doxygen. Configuramos cron para que generase una documentación actualizada periódicamente en un website interno. El sniffer de coding standards se asegura de que toda función venga documentada.

SimpleTest. Script de vigilancia.
Hicimos una charla de formación interna sobre simpletest y se hizo mandatorio que todo el mundo desarrollase tests en sus módulos. Desarrollé un script que se invocaba desde el hook pre-commit y que hacía imposible commitear código si no se habían añadido un porcentaje suficiente de funciones al simpletest correspondiente. Establecimos el porcentaje al 70%, excluyendo hooks, preprocess y funciones de formularios (forms, submits y validates). Aunque esta imposición disciplinó a los programadores, con el paso del tiempo fue perdiendo utilidad. Ahora, con el desarrollo de pruebas unitarias y de integración asimilado por los desarrolladores, el script está desactivado.

Creación de una rama STABLE en el repositorio.
Dividimos el código en subversion en dos ramas; trunk y stable. Los desarrolladores iban depositando el código en trunk, y sólo en los despliegues (que ya eran planificados) se movía el código a la rama stable y se sincronizaba al entorno de producción.

Protocolo de despliegues.
El equipo se reunió y consensuó un protocolo de despliegues. Decidimos empezar a versionar y planificar las releases. Utilizando una herramienta de etiquetado (nosotros utilizamos jira, pero cualquiera vale), los desarrolladores asignan tareas realizadas a la versión a desplegar. Llegado el día del despliegue (semanal), QA se encarga de revisar cada uno de los bugs/desarrollos y comprobar el funcionamiento del sistema completo. Sólo QA está autorizado a desplegar código, y tiene autoridad para rechazar código que considere incorrecto.

Automatización de Simpletest con Hudson.
Instalamos Hudson en el entorno de pruebas. Dividimos los tests en dos grupos: integración (DrupalWebTestCase) y unitarios (DrupalUnitTestCase). Hudson ejecuta constantemente tests tanto sobre la rama trunk como sobre stable. La rama stable recibe, también periódicamente, copias la base de datos de producción. Cuando Hudson descubre un error, envía un mail al equipo de desarrollo, y resolverlo se convierte en la primera prioridad del equipo.

Herramientas de medición de la calidad.
Instalamos PHPMD. Creamos un ruleset que se encargaba de medir tanto la complejidad ciclomática como la longitud de las funciones. Establecimos que el máximo de complejidad ciclomática era 15. Ninguna función podía superar ese umbral y ser desplegada. Instalamos también PHPCPD, una herramienta que permite detectar código duplicado.

Code refactoring.
Tenemos todavía miles de líneas de código antiguo por refactorizar. El code refactoring se organiza en ciclos. Se analiza una funcionalidad, se elabora un informe con los puntos oscuros o mejorables y se proponen mejoras. Posteriormente se realiza una cobertura completa de tests de integración a través de la interfaz (drupalGet y drupalPost) que sirva de anclaje seguro para futuras modificaciones. Una vez terminada la cobertura, se refactoriza el código y paralelamente se construyen los test unitarios. Esto permite una refactorización casi al 100% segura.

Tests de Selenium
Con el protocolo de despliegue elaboramos una checklist de pruebas de sistema que debíamos realizar manualmente para comprobar que todo estaba en orden. Funcionamiento de los foros, navegación de usuarios anónimos y registrados, interfaces de administración propias, etc... Como era una pesadez hacer todo esto a mano cada despliegue, utilizamos scripts de Selenium para automatizar la tarea.

Estas son las medidas que ahora mismo han sido adoptadas, hay otras todavía pendientes:

Code reviews.
Aunque actualmente QA se encarga de las code reviews para refactorizar el código, queremos instaurar cr como parte necesaria en el proceso de desarrollo. También queremos que sea algo participativo y responsabilidad del conjunto de desarrolladores, y no tarea de un organismo de inspección como ahora mismo.

Medición del rendimiento.
Del mismo modo que hudson se encarga de lanzar SimpleTest periódicamente, queremos elaborar un set de herramientas (o instalar ya existentes) que nos permitan controlar el rendimiento del site y encontrar problemas en la base de datos.

Con estas medidas hemos llegado a algo similar a esto:

El objetivo final es que QA desaparezca y los desarrolladores asuman de manera individual su parte proporcional en el control de la calidad.

Bueno, pues estas son las experiencias que hemos tenido en Aureka Internet. Espero que os sirvan y me gustaría recibir consejos, críticas y experiencias similares sobre este tema.

Un saludo,

Carles Climent.