[Teched 2007] Code it and ship it with Team Build 2008
Brian Randell - Senior Consultant MCW Technologies
Martin Woodward - Lead architect Teamprise
Une des seules sessions que j'avais repérées dans mes flux RSS avant de venir au Teched. La semaine commence à être difficile, je me suis fait violence, je me suis levé, j'y suis allé et je n'ai vraiment, mais alors vraiment pas regretté!
Cette session est donc axée autour de Team Build / MSBuild et plus particulièrement les nombreuses évolutions apportées par la version 2008.
L'automatisation de Build n'est pas:
• Une utilisation massive de la touche F5
L'automatisation de Build c'est:
• L'extraction d'éléments dans un dépôt de sources
• L'assemblage de ceux-ci
• La validation de celui-ci
• L'audit du résultat
L'automatisation aide à se poser les questions:
• Nos sources créent-elle un produit?
• Sommes-nous dans les temps?
• Notre produit est il de bonne qualité?
Team Build 2008 est la réponse de Microsoft au besoin d'automatisation de build, le nom officiel du produit permettant de faire ceci est Visual Studio 2008 Team Foundation Server Build, celui-ci fait partit de la gamme Team System et vient complémenter Team Foundation Server (qui est requis).
Nouveautés apportées par la version 2008:
• Dans la définition d'une Build, il est maintenant possible de spécifier, via une interface graphique, au niveau du source control, un Workspace spécifiantl'ensemble des sources devant être prises en compte dans le process de Build (dans la version 2005, tout le team project était automatiquement extrait). Ceci permet d'optimiser le volume de sources extrait par le service de build lors de l'assemblage en ciblant uniquement celle utiles.
• Il est maintenant possible de prendre en compte plusieurs solutions (au sens visual studio du terme) dans une définition de Build
• Sur la partie test à exécuter, il n'est plus nécessaire de spécifier une liste de test (test list) pour définir les tests devant être joués après la Build: il est maintenant possible de demander directement au service de build de détecter et d'exécuter tout les tests présents dans une assembly sélectionnée
• Apparition de la notion de "Retention Policy": que faire des builds qui échouent, sont stoppées, sont réussit partiellement ou ont réussit: il est maintenant possible de spécifier que l'on souhaite garder la dernière, les supprimer, garder les n dernières.... Pratique pour garder un serveur de Build propre (surtout dans un contexte d'intégration continue ou chaque check-in génère une release et que l'espace disque du serveur est réduit). Il est aussi possible de spécifier explicitement (via un système de lock) sur un résultat de build que celui-ci doit être conservé et que les règles de nettoyage ne doivent pas le prendre en compte.
• Trigger et scheduled Build: possibilité de déclencher automatiquement le service de build: au checkin, des qu'il y'a eut un ou plusieurs checkin et que le serveur est prêt (avec la possibilité de dire de build au maximum 1 fois dans un intervalle de temps - 1 fois toutes les 10min par exemple) ou encore des jours spécifiques a une heure particulière
• Build Queuing: Les builds se mettent automatiquement en attente jusqu'a ce que le service de build ait terminé les traitements en court. Il est ainsi possible de prioriser certains types de Build (pour une release urgente qui ne peut attendre par exemple)
Compatibilité TFS 2005 / TFS 2008 vs Team explorer (client) 2005 / 2008: Team Explorer 2008 permet de gérer des Builds sur un serveur 2008 sans accès aux nouveautés de la même manière que Team Exporer 2005 offre la possibilité de se connecter a un serveur de Build 2005.
Les différentes étapes exécutées durant le processus de Build sont:
• Initialisation de la build depuis TFS
• Préparation de l'agent de build et génération d'un numéro de Build
• Synchronisation (récupération) des sources
• Compilation et analyse
• Exécution des tests (test list ou DLL)
• Mise à jour des Work Items impliqués par les sources compilées
• Calcul de la couverture de code
• Calcul du "code churn"
• Génération du rapport de build
• Copie de résultat dans le répertoire de livraison
• Publication des résultats dans TFS
• Levé d'un événement (service de notification) pour notifier que la Build est terminée
Fonctionnement de l'intégration continue dans TFS 2008:
• Un développeur fait un check in et créé un changeset
• Le service de gestion de sources lève un événement pour remonter le checkin au service de notification
• Le service de build est abonné à l'événement, analyse le changeset, et recherche la définition de Build y étant associé pour faire une demande d'exécution (mise en attente)
• L'agent de build reçoit un événement car une demande de build est en attente, récupère la définition, compile, et lève un événement au niveau du service de notification pour prévenir que le livrable est généré
• il est aussi possible de s'abonner aux événements de démarrage / fin de build dans une application interne: après la RTM de TFS 2008, un powertool sera disponible pour permettre, depuis Windows, d'obtenir en tray icone l'état d'un type de build (en court, réussit, échoué...)
Agents de build: Team Build 2008 peut être configuré pour plusieurs agents de Build (local, distant...) et il est donc possible lors de la définition de sélectionner celui souhaité. La communication avec l'agent de Build se fait maintenant en HTTP(s).
Personnalisation de définition de Build:
• Nécessite de check-out et de modifier le fichier de définition de la Build
• Possibilité d'écrire ses propres Tasks (action devant être exécutée avant / pendant / après le Build) en .NET en utilisant l'interface ITask
En conclusion, Team Build reste de loin la partie de TFS ayant subit le plus d'améliorations durant le passage de TFS 2005 vers TFS 2008. A lui seule une bonne raison de migrer vers la version 2008!
