Introduction au nouveau système de build
Microsoft a récemment rendu disponible un nouveau modèle de définitions de build avec la version 2015 de Visual studio (les binaires tfs 2015 ne sont pas encore disponibles mais le service est déjà présent dans Visual Studio Online).
Pour rappel, les « anciens » modèles de build étaient basés sur deux éléments :
- Le build process template : en XAML, qui définit les étapes que va suivre la séquence de build
- Le build défintion : qui va servir de liant entre le template, les sources et un ensemble de paramètres.
Cette méthodologie fournit de nombreuses possibilités pour automatiser votre compilation, packaging, tests unitaires et même dans certains cas les déploiements.
Les inconvénients principaux restant les suivants :
- Processus uniquement personnalisable avec Visual Studio/.NET, ce qui ne suit pas l’ouverture récente de Microsoft
- Difficile à débugger
- Courbe d’apprentissage assez importante
De ce fait Microsoft a renommé cette méthodologie « XAML builds » et a livré une nouvelle façon de faire. (actuellement nommée « build definitions » dans l’interface).
Cette nouvelle méthodologie apporte de nombreux avantages :
- Plus facile à prendre en main
- Plus facilement débuggable
- Editable depuis le portail web (plus besoin de visual studio donc)
- Fournit de nombreuses intégrations avec d’autres outils (gulp, ant, maven…)
Le fonctionnement principal étant d’enchainer des étapes enfichables (plus de structure complexe de workflow comme avant), c’est assez bien décrit par ici https://msdn.microsoft.com/en-us/Library/vs/alm/Build/overview
Rappels sur les cloud services
Parmi les nombreux services fournis par Microsoft Azure on trouve les cloud services (PaaS). Pour faire court, et du point de vue d’un développeur, ce sont des services qui peuvent être modélisés dans Visual Studio et qui se constituent deux types de composants :
- Worker Role : composant servant à faire du traitement lourd, un peu comme un service windows dans son fonctionnement.
- Web Role : composant permettant de développer des applications web. Cependant à moins de contraintes de déploiement/configuration/flexibilité assez particulières, les azure web sites (ou azure web apps) répondent maintenant à 98% du besoin et sont plus simples à déployer.
Si vous voulez plus d’informations sur le sujet je vous invite à consulter https://msdn.microsoft.com/en-us/library/azure/jj155995.aspx
Déployer un cloud service dans votre release pipeline
Maintenant en tant que développeur consciencieux vous souhaitez déployer ce cloud service de manière automatisé en mettant en place un release pipeline. Pour éviter que cet article soit trop long je ne m’étendrai pas sur les nombreux avantages que cela procure par rapport à un build et déploiement à la main.
Vous avez présentement plusieurs options pour configurer le déploiement automatique :
- Depuis le cloud service sur le portail courant (manage.windowsazure.com) demander à azure de faire la configuration à votre place.
- Le faire à la main.
Le « problème » avec le premier cas de figure c’est qu’en ce moment Azure va configurer une build « XAML ». C’est amplement suffisant si vous souhaitez uniquement déployer votre cloud service tout seul. Mais admettons que vous ayez d’autres éléments à builder/déployer dans votre solution et/ou que vous souhaitez bénéficier d’intégration avec d’autres outils/services ? Dans ce cas il va être très difficile de concilier build XAML et ces autres éléments (voir impossible dans certains cas de figure).
Je vais donc vous expliquer comment déployer ce cloud service avec les nouvelles builds de visual studio online. Cet article va être basé sur des éléments puisés dans un article qui explique comment déployer un azure web site avec les nouvelles builds, sur un article qui explique comment déployer des cloud services avec les builds XAML ainsi qu’un peu de recherche de ma part.
https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/index
https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-continuous-delivery/
Je vais présumer que vous avez déjà créé le service de cloud sur azure ainsi qu’un service de stockage. (il est possible d’automatiser cette partie aussi si vous le souhaitez).
Vous devez aussi être administrateur de votre projet d’équipe et administrateur de la souscription Azure (ou demander à l’admin azure les publishsettings)
Configuration de la connexion à Azure
La première étape consiste à dire à visual studio online « hey j’ai une souscription azure sur laquelle tu peux faire des trucs ». Pour cela rendez-vous sur la page de votre projet d’équipe dans visual studio online cliquez sur la roue dentée en haut à droite.
Puis cliquer sur l’onglet services.
Add new service connection.
Ajouter le subscription id, le subscription name, et le subscription certificate que vous pouvez trouver depuis le fichier publish settings. Vous pouvez obtenir ce fichier de plusieurs manières :
- En cliquant sur le lien bleu en bas à droite
- Depuis la console azure powershell
- En allant voir votre admin azure si vous en avez un
Une vidéo explique comment bien ajouter ces paramètres
Note : je n’ai pas eu de problèmes avec cette étape avec mon compte personnel (live) pour des projets personnels mais il semblerait qu’il y ait un bug si votre souscription Azure est un Enterprise agreement et que vous vous identifiez sur azure avec un compte d’entreprise. Pour contourner ce problème chez Negotium nous avons configuré un déploiement depuis azure ce qui a eu pour effet de créer service automatiquement.
Ajout de l’étape de publication
Rendez-vous dans l’onglet « build ». Normalement vous avez déjà créer une nouvelle définition de biuld de type « Visual Studio ». Par défaut 4 étapes sont présentes :
- Visual Studio Build : compilation
- Visual Studio Test : mstest
- Index Sources and Publish symbols : création des symboles de débug
- Publish Build artifacts : rapatrie le produit du processus pour l’archiver avec la build
Nous allons commencer par éditer la première étape pour ajouter « /t:Publish /p:TargetProfile=Cloud » aux arguments MS Build. Bien entendu « cloud » doit correspondre à un des profils de publication de votre service de cloud ( par défaut cloud et local).
Ceci va indiquer à visual studio de constituer les packages de déploiements après la compilation.
Une fois cela effectué nous allons ajouter une cinquième étape en dernier de déploiement de cloud service.
Pour la souscription, sélectionner celle que vous venez d’ajouter, dans le storage account, entrez le nom de l’espace de stockage qui va servir pour le déploiement. Service Name, le nom du cloud service.
Pour le cspkg et le csconfig vous avez plusieurs options, ou bien vous pouvez spécifier le chemin complet ou relatif vers les fichiers ou alors vous pouvez spécifier un pattern de recherche. Préférant la précision j’ai rentré :
$(Agent.BuildDirectory)\artifacts\drop\ImageResizer\bin$(BuildConfiguration)\app.publish\ImageResizer.cspkg
$(Agent.BuildDirectory)\artifacts\drop\ImageResizer\bin$(BuildConfiguration)\app.publish\ServiceConfiguration.Cloud.cscfg
“imageResizer” étant le nom de mon projet de cloud service.
(si vous n’êtes pas sûrs des noms de dossiers/fichiers, lancez une première build et regardez le contenu du drop)
Pensez bien à activer l’étape, enregistrer et vous êtes prêts à déployer de manière automatique !
