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 UNC, on se doutera que sur le Cloud, ca ne marche pas! Microsoft emploie une solution qui a le mérite d’être simple: la drop location est un emplacement dans votre Source Control. Les puristes du SCM vont sauter au plafond, mais bon, ca marche et comme Brian l’explique vous avez la possibilité de mettre en cache le contenu de la Drop Location en utilisant le TFSC Proxy et lorsque vous supprimez une Build le contenu est bien effacé du SCM (heureusement!).
Mise en place A partir de l’onglet “Builds” du Team Explorer de Visual Studio 11beta, cliquez sur “New Build Definition” pour faire apparaitre la fenêtre de configuration d’un type de Build.
La configuration de la Build ne diffère pas de la version On-Premise, pour sélectionner la compilation sur Azure, il suffit de se rendre dans l’onglet “Build Defaults” et de choisir le controlleur de Build nommé “Hosted Build Controller”.
En sélectionnant ce choix le paramètre “Staging Location” passe automatiquement à “Copy build outputs to the following Source Control folder” afin de déposer les binaires produits sur le Source Control. Le reste de la configuration ne change pas.
Démarrer une Build Place une Build sur la file d’attente se fait de la même manière que pour la version On-Premise, clique droit sur le type de Build concerné, puis “Queue New Build…”
Peu de temps après la Build démarre. Le délais de réaction est clairement bon quand on imagine tout ce qui est effectué en coulisse (une Build met moins d’une minute à démarrer dans mon cas) A la fin de la Build on retrouve le rapport: Et voilà, en tout est pour tout moins de 10 min pour création un nouveau Type de Build, Sauver, lancer une Build.
Limitations On termine par une petite note que l’on ne peut pas considérer comme négative, mais bon, il faut avoir conscience que compiler sur le Cloud vous demandera d’être irréprochable au niveau des vos dépendances tierces-parties. Forcément, vu que l’on compile sur une VM totalement vierge sur laquelle il est impossible de prendre la main, on doit recourir à une des deux solutions suivantes:
- Les dépendancess ont stockées sur le Source Control (normalement à éviter, mais cela se fait de plus en plus, vu que le Source Control en question supporte bien la charge).
- Recourir à Nuget pour la gestion des dépendances tierces-parties. Bien sûr le 2ème point est recommandé. A ce sujet il ne faut pas oublier d’activer la fonctionnalité “Nuget Package Restore” afin de s’assurer que tout fonctionnera sans encombre.
Plus d’information sur cette fonctionnalité et l’utilisation de Nuget en général avec un SCM sur un de mes anciens billets. A l’heure actuelle il n’est pas possible de compiler tous les types de projets, forcément le service étant encore en phase beta. Vous trouverez la liste sur le post de Brian.