Build de 10 minutos y categorización de tests

Cuando el equipo actual tomó a su cargo el sistema este tenía una alto grado de inestabilidad y prácticamente no tenía tests automatizados. Gradualmente se fueron agregando tests que ayudaron a mejorar a la estabilidad del sistema. En un punto se llegó a tener unos ~2600 tests de componentes/unitarios cuya ejecución excedía los 30 minutos. Todos estos tests eran ejecutados como parte del build de integración continua. A esto se sumaba el hecho de que equipo hacía feature-branches, los cuales también eran buildeados automáticamete, aumentando la carga del build server. Llegado un punto, cada vez que un developer hacía un commit (+push) tenía que esperar, en el mejor de los casos, unos 40 minutos para obtener feedback. Podía llevar a pasar que el build server estuviera ocupado y entonces el build quedaba encolado estirando aún más el tiempo de espera.

Ante esta situación hicimos dos cosas. En primer lugar instalamos un segundo agente del Build Server, para bajar el tiempo tiempo de espera en cola. En segundo lugar categorizamos los tests y ajustamos la configuración del build server. En este segundo punto quiero profundizar.

Es un práctica muy difundida y aceptaba, el tener un build de integración/feedback continua que no exceda los 10 minutos (algunas referencias para profundizar aquí y aquí). En línea con esto decidimos categorizar los ~2600+ tests, identificando aquellos que cubrían las partes críticas de la iteración. Identificamos unos ~600 tests fundamentales cuyo tiempo de ejecución resultó en unos 7 minutos. Categorizamos esos tests como “core”. Al mismo tiempo ajustamos el build server para que se ejecuten en forma continua (ante cada commit+push) los tests “core” y de los “current” (pertenecientes a la iteración actual), de manera de poder tener un feedback “rápido”. Por otro lado, creamos otra tarea que se ejecuta al fin del día para correr el set completo de tests.

 

Anuncios

Banca DevOps, nuevo proyecto

Desde hace un tiempo hay en Argentina un auge de transformación digital en el sector bancario, el cual suele incluir iniciativas Agile + DevOps. En ese contexto, fui contactado hace un par de semanas por un banco para colaborar en la optimización de su flujo de valor (en realidad el pedido vino por otro lado y después de un par de charlas derivó en esto).

Luego de un par de conversaciones con las personas que me convocaron, nos pusimos de acuerdo y accionamos. La idea es comenzar trabajando sobre un equipo en concreto, y luego incorporar gradualmente otros equipos. La intención es poder ir resolviendo problemas reales de los equipos y definir reglas/patrones a partir de generalizaciones de lo realizado en cada equipo.

Una de mis premisas de trabajo cuando participo de este tipo de iniciativas es definir criterios claros y objetivos de éxito. Muchas veces he visto iniciativas fundamentando su éxito en frases tales como “La gente se siente más contenta”, lo cual puede estar bien para “la gente”, pero muchas veces resulta insuficiente para quien paga. Tal vez sea una limitación mía, pero no he tenido éxito convenciendo gerentes con “sensaciones”. Tal vez sea por mi perfil ingenieril: las sensaciones me parecen importantes, pero a la hora de tomar desiciones quiero números concretos. En este sentido, en el contexto de esta nueva iniciativa, hemos definido dos métricas iniciales como referencia: lead time y risk exposure.

Continuará…