Azure DevOps – Timeout pour un build

Depuis plusieurs années, j’utilise les définitions de builds dans TFS / VSTS (maintenant appelé Azure DevOps) afin de compiler et/ou déployer mes applications.

Il m’est arrivé dernièrement de travailler sur un projet où il n’y avait qu’un seul agent de build (certaines raisons ont fait en sorte qu’on s’est retrouvé dans cette situation temporaire).

Nul besoin de dire que cela peut impacter négativement l’expérience développeur, surtout si on a une définition de build en mode « Gated Check-in ».

L’expérience développeur a été impacté d’autant plus négativement que certains builds pouvaient planter et rester bloqués sur une tâche indéfiniment, bloquant ainsi tous les autres demandes de builds qui sont en file d’attente.

Certes, par défaut, TFS / Azure DevOps définit un timeout de 60 minutes mais force est d’avouer que c’est bien trop long !

C’est pourquoi, il est important de définir une durée de timeout plus adéquate.

Comment configurer un timeout pour ma définition de build ?

Depuis ta définition de build, va dans l’onglet « Options ». Personnellement, j’ai configuré les deux options suivantes :

• Build job timeout in minutes: la durée maximale (en minutes) d’exécution du build. Après cette durée, le build est annulé;
• Build job cancel timeout in minutes: la durée maximale (en minutes) d’annulation du build. Après cette durée, le serveur met fin au build de manière forcée.

Quelle est la durée de timeout appropriée à appliquer ?

Il n’y a pas, à mon humble avis, de bonne réponse à cela. Chacun ira de son feeling. Personnellement, je me rajoute une contingence de 50% sur la durée normale de mes builds. Ainsi, si mon build dure 10 minutes, je mettrai un timeout de 15 minutes.

En conclusion…

Lorsque tu configures tes définitions de builds, il est important de tenir compte de ces petits détails qui font en sorte que les développeurs de ton projet ou d’autres projets dans l’organisation ne soient pas en maudit contre toi 🙂

À la prochaine !