Integración continua y avergonzamiento público

Una de las medidas que Mike Clark promovía en el libro de cabecera Pragmatic Project Automation es la de mostrar el resultado de las diferentes build de la manera más visible que se pueda. El objetivo está claro, saber lo más pronto posible cuando y por qué se ha producido un evento que ha roto el proceso de build de la aplicación.

En mi compañía se ha ido un poco más allá, y como aliciente adicional se ha creado una lista de "Top Build Breakers". Además el manager de producto recibe un bonito email semanal con estadísticas tan jugosas como cuantas veces se ha roto el proceso de build, quienes son los que más lo rompe, cuanto se tarda en solucionar un problema, y cosillas así.

Aunque los desarrolladores noveles son los que más han protestado con la medida, por considerarla intimidatoria y como un punto importante de presión, lo cierto es que medidas así aseguran a mantener alto el estado de salud del código, al menos en cuanto a compilación y pruebas unitarias. Pasados ya más de tres meses desde la aplicación de la medida, la productividad ha aumentado enormemente, y sobre todo el tiempo que la base de código permanece en un estado inconsistente ha decrementado radicalmente. Hace meses el código podía estar días en estado inconsistente (valga como defensa que hablo de varios cientos de proyectos), y ahora mismo pasa no más de unos cuantos minutos. La gente es mucho más cuidadosa con el código que se sube al repositorio y con los tests unitarios que se crean.

Por lo tanto, que nadie se asuste por aplicar o por sufrir estas medidas, ya que la experiencia dice que al final es un beneficio para todos. Por cierto. Sí, he roto alguna vez la build. Pero que conste que no salgo en la lista de ganadores :-)