Contexto

La pipeline de compilación y ejecución de los tests puede llegar a alargarse bastante cuando tu proyecto va creciendo, no sólo por el número de tests, sino por la complejidad de los mismos, (levanta una BD, pruébala, levanta el contexto de tu servicio web, lanza peticiones contra él, prueba los timeouts…) y a no ser que tengas infinitos nodos en azure para lanzar pipelines en paralelo, vas a afectar a tus compañeros, tanto de tu proyecto como de otros proyectos, que tendrán que esperar a que termine de ejecutar tu pipeline para que den tiempo a las suyas, pobres proyectos que no tienen ni tests de integración y sólo requieren de un par de minutos para compilar y poder integrar su rama a develop.

Además, se suele dar otro fenómeno, y es que al ser tan largo el proceso de ejecución de todos los tests, los desarrolladores suelen delegar en la pipeline este proceso, haciendo commits sin lanzar los tests y esperando a que sea la pipeline la que les diga si han roto algo, derivando en más de 10 ejecuciones de la pipeline para la misma PR. 

Nuestra solución - 2 pipeline

Para solventar este problema, hemos dividido nuestro pipeline en 2 distintas.  

En la primera, el normal que se ejecuta en las pull requests contra develop hemos excluido los tests de integración y e2e, esto lo hemos hecho vía Maven, ocultándolos tras un perfil, y lo único que hace es compilar y lanzar los tests unitarios.  

Luego hemos creado una nueva pipeline que ejecuta la compilación y todos los tests, esta la hemos planificado para que se ejecute contra develop todos los días a las 2 de la mañana, para ello hemos cogido la pipeline original y le hemos incluido un par de parámetros.  

El primero el Schedule, el cual planifica mediante una expresión cron (sin segundos) la frecuencia de ejecución, en nuestro caso todos los días a las 2 de la madrugada, además, le hemos indicado que sólo se ejecute contra develop.   

schedules: 
  - cron: '0 2 * * *' 
    displayName: Nightly build 
    branches: 
      include: 
      - develop 

El segundo parámetro es para que el CI de Azure no dispare ejecuciones de esta pipeline al detectar cambios en la rama.

trigger: none 

Y con esto ya tendríamos relegados nuestros tests más lentos a la ejecución nocturna, en la que ya no molestamos a nadie.  

Bola extra:  

Hay que tener en cuenta que esto puede llegar a hacer que se cuele algún test fallido en master, cosa que no se debe permitir, para lo cual yo sí que mantendría en los mergeos de la release contra master la pipeline completa activada.  

Aparte, para mantener lo más saneada posible la rama develop, se puede configurar un envío de email cada vez que falle la ejecución del pipeline para rápidamente poder corregir y castigar severamente al culpable. 

Para ello nos vamos a la configuración de azure y añadimos una nueva suscripción a notificación