Hace un tiempo leí que una de las medidas que Mike Clark promovía en el libro Pragmatic Project Automation es la de mostrar el resultado de las diferentes build de la manera más visible que se pueda.

El objetivo de la medida 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.

Les cuento que nosotros estamos trabajando con Integración Contínua hace ya tres años, y hemos avanzado en muchos sentidos en los diferentes aspectos (reportes) que nos genera la  Integración Contínua y en otros que no tienen que ver con ella.

Entonces ya que hemos sorteado varios problemas que se nos han presentado el último año, como por ejemplo:

• Cambiamos la arquitectura para que los diseños puedan ser testeables.
  
• Implementamos como práctica TDD.
• Hacemos revisiones de código formales, para contrarestar el refactor constante que propone TDD.
  
• Tenemos SLA's internos de Cobertura (80% total, 100% en la implementación de BO y DAO), errores de Checkstyle (cero o justificados), errores de PMD (cero o justificados).
• Implemtamos Scrum.
• Pusimos en claro la Definición de Terminado que propone Scrum.
  

Ahora, viendo los proyectos que llevamos adelante y viendo que muchas veces puede pasar mas de una semana en estado inconsistente y pensando en mejorar contínuamente, se me ocurre algo que leí hace tiempo que sería bueno quizás implementar (solo quizás no se asusten todavía) y es crear una lista de "Los que mas Build rompieron x mes".

Además de esto, estaría bueno que el grupo de Arquitectura reciba un reporte semanal con estadísticas que podríamos definir, como cuantas veces se rompe un build por cada proyecto, quien lo rompe, cuanto se tarda en solucionarlo, bueno etc.

Si, es claro, los desarrolladores por lo general van a protestar mucho por la adopción de algo así, aunque esto ayude asegurando el estado correcto del código en todo momento, al menos en lo que respecta a compilación y las pruebas unitarias.

Luego de la aplicación, se podrá revisar si la adopción de esta medida beneficia la productividad y cuanto tiempo permanece el código en un estado inconsistente, intentando incluir una métrica, como puede ser que no pase mas de un día en estado inconsistente (lo óptimo serían minutos).

Así las personas serán mas cuidadosas con el código que suben al repositorio y con las pruebas que crean.

Por lo tanto, que nadie se asuste por aplicar o por sufrir estas medidas, ya que son en beneficio de todos.

Ahh, y otra cosa,  nunca he roto un build. Pero que conste que no programo