TeamBuild 2010 : Gated Check-in et Private Build 2

TeamBuild 2010 : Gated Check-in et Private Build

Ce billet fait parti d’une série sur TeamBuild 2010 :


Qu’est-ce que le « Gated Check-in » ? Il s’agit d’un nouveau type de build se lançant automatiquement lorsqu’un développeur fait un check-in mais à la différence d’un build en intégration continue, le « Gated Check-in » est capable de refuser le check-in si le build est en erreur.

D’un point de vu technique, le « Gated Check-in » utilise les étagères. Lorsqu’un développeur fait un check-in de fichier associé à ce type de build, Visual Studio affiche une fenêtre indiquant que le check-in va faire lancer un « Gate Check-in » et proposera au développeur de sauvegarder son code sur une étagère :

image

Comme on peut le voir sur la capture d’écran, le développeur peut passer outre et forcer le check-in s’il a les droits. S’il ne passe pas outre, son code est mis en étagère et un build est lancé. Lors de ce build :

  • Le build contrôleur va commencer comme n’importe quel autre build en préparant le répertoire de drop et en calculant le numéro de build.
  • Le build agent, après avoir récupéré la dernière version du code, va récupérer le contenu de l’étagère. Par contre il ne créera pas de label et ne fera pas l’association aux changesets et workitems.
  • La compilation sera lancée.
  • Les tests seront exécutés.
  • L’indexation des sources et la publication des symboles se fera.
  • Enfin, si le build n’est pas en erreur, le contrôleur terminera le « Gated Check-in » en faisant un check-in des sources (et en ajoutant aux commentaires « ***NO_CI*** » afin de ne pas lancer de nouveau build) et en associant les changesets et workitems au build :

image

Si, par contre, une erreur de build a lieu, le développeur il pourra dans l’explorateur de build choisir de sortir de l’étagère son code afin de récupérer sa version pour la corriger :

image

Il est bien entendu possible de lancer manuellement un build de type « Gated Check-in ». Dans ce cas le fenêtre propose de nouvelles options :

image

L’utilisateur pourra soit lancer le build sur la dernière version comme pour tout autre type de build en sélection « Latest sources » dans « What do you want to build? » soit lancer un build sur la dernière version du code en y incorporant une étagère spécifique. Dans ce dernier cas, l’utilisateur peu décider s’il faudra ou non faire un check-in de l’étagère en cas de succès du build (cela revient à un « Gated Check-in » normal).

Le fait de pouvoir spécifier, en mode manuel, si l’étagère doit être check-in nous amène au deuxième type de build de ce billet : le « Private Build ». Le « Private Build » est un build lancé uniquement manuellement par un développeur ou celui-ci précisera l’étagère à utiliser (étagère qu’il aura créé auparavant). Ce build se passera comme un « Gated Check-in » avec les restrictions suivantes :

  • Aucun numéro de build ne sera généré.
  • Il n’y aura pas d’indexation des sources ni de publication des symboles.
  • Le build ne sera pas associé à un changeset ou des workitems.
  • Le résultat du build ne sera pas copier dans la DropLocation.

Les « Private Build » peuvent être utilisés quelque soit le type de build (manuel, intégration continue, …) et servent aux développeurs à valider leurs modifications en utilisant le processus de build qui est mis en place au niveau du serveur de build et en utilisant la machine de build. Cela permet par exemple de vérifier que des composants tiers que l’on vient d’ajouter au projet son bien présent aussi sur le serveur de build.

On peut comparer les « Private Builds » avec l’utilisation de script de build en local avec TeamBuild 2008 et l’utilisation la propriété « IsDesktopBuild » mais en beaucoup, beaucoup mieux :)

Pour conclure, le « Gated Check-in » est très puissant et permet de forcer les développeurs à check-in uniquement du code qui marche mais peut s’avérer un peu trop intrusif à mon gout. Par contre les « Private Builds » sont une bonne alternative en permettant aux développeur de vérifier eux même leur code.

Carpe Diem

2 thoughts on “TeamBuild 2010 : Gated Check-in et Private Build

  1. Pingback: TFS 2010 by Drook Technology | TFS 2010 Gated Check-in and merging

  2. Pingback: TeamBuild 2010 : Activités pour Workflow Foundation 4.0 ← Guillaume Rouchon's Blog

Comments are closed.