Buildez dans le cloud avec Team Foundation Services

Brian Harry l’a annoncé il y a quelques jours, il est maintenant possible d’utiliser Azure pour l’intégration continue de vos projets. Fini la création de Build Controller, Build Agent, VMs et la maintenance de tout ceci. Le moins qu’on puisse dire est que l’intégration continue devient de plus en plus accessible avec la prochaine génération de logiciels et de services Microsoft. Comment ca marche Pour faire bref, vous avez maintenant la possibilité de cibler un nouveau Build Controller (le “Hosted Build Controller”) dans vos définitions de Build. Lorsque celui-ci est spécifié, toute Build démarrée sera compilée sur le Cloud. En interne, Microsoft possède un pool de VM sur Azure et dès que vous déclenché une Build, une VM est prise dans ce pool et la mécanique d’intégration continue s’effectue “normalement” (création de workspace, récupération des sources, compilations, exécution des tests, indexation des sources, etc.). Une fois la Build terminée la VM est restaurée dans son état “clean” et réintègre le Pool. Vous avez la possibilité d’utiliser un Build Template Custom, comme On-Premise (i.e. “à la maison”). Un seul détail différencie les Build sur le Cloud de leur version On-Premise: la “Drop Location” des binaires compilés. Ce paramètre est historiquement une […]

Team Build 2010: Comment débugger simplement avec l’indexation des sources!

Team Build 2010 résout fort simplement une problématique que l’on a depuis des lustres: comment débugger facilement une release ancienne ou compilée par une chaine d’intégration continue. Ceux qui savent de quoi je parle l’auront déjà compris: avoir les fichiers sources qui correspondent à ce que vous débuggez peut s’avérer être une tâche difficile voire impossible. La théorie (grosse maille) Pourquoi? Revenons rapidement sur le mécanisme du debugging (mais alors très rapidement): Tout commence par l’Exe que vous débuggez, ainsi que les DLL qu’il utilise: c’est le programme qui est exécuté pas à pas par le débuggeur. Seulement, si vous n’avez pas les sources, vous n’aurez qu’une vue code assembleur de votre programme et même si vous avez passé plusieurs années à faire de l’assembleur, ca ne vous donnera pas pour autant le courage de faire avec! L’utilisateur veut débugger avec les sources qui ont étés utilisées pour compiler le programme. Un type de fichiers existe pour faire le lien entre un fichier binaire (.exe, .dll): c’est le .pdb. Grossièrement le .pdb stocke pour chaque statement de votre langage le fichier source (un .cs par exemple) dans lequel il se trouvait et à quelle ligne. Lors du debugging, lorsqu’un fichier […]