//Build 2018 – Continuous Monitoring for DevOps with Azure Application Insights & Log Analytics

La session commence par un courte introduction sur l’importance du monitoring dans le cycle DevOps, et avant tout pourquoi monitorer son application :

  1. Pour rendre visible l’état général de son application
  2. Pour trouver et résoudre les problèmes
  3. Pour l’optimiser en apprenant

azure-monitoring

Et pour monitorer son application, Azure propose des outils out-of-the-box analysant à la fois des données opérationnelles et des données applicatives. Tous outils peuvent être personnalisés pour surveiller des scénarios spécifiques.

La suite était une longue série d’exemples d’usage des outils sur le portail :

  • L’écran Health d’un nœud Kubernetes avec un drill-down vers Log Analytics pour regarder en détail les évènements liés
  • La configuration d’alertes sur des métriques avec en preview le choix de seuils dynamiques (déterminés par du ML sur les données historiques) plutôt qu’un seuil statique unique
  • Les différents choix d’action sur les alertes : email, sms, déclenchement d’un Logic App, lien vers son ITSM…
  • L’écran Application Map d’un site Web pour suivre les différentes ressources Azure liées et leurs interactions
  • L’écran Failures pour analyser les exceptions, voir le détail d’un transaction de bout en bout, ouvrir un snapshot de debug dans Visual Studio avec les données captées en production, ouvrir un ticket dans VSTS…
  • Le Live Metrics Stream
  • L’ajout de tâches de monitoring dans une release VSTS : ajout d’AppInsights, configuration d’alerte, ajout d’un tag de version dans AppInsights
  • L’écran Users pour analyser l’usage du site
  • L’enregistrement de chemin d’analyse dans un Workbook partageable
  • Et plein d’exemples de requête sur les données AppInsights (un cours Pluralsight devrait sortir sur le sujet !)

J’ajouterai le lien vers la vidéo parce que c’était vraiment riche !

Customiser VSTS et le synchroniser avec Project 2016

Objectif

Les projets d’équipe de VSTS offrent la possibilité de gérer les item du product backlog. Depuis l’interface web de VSTS on peut :

  • Définir des Epics, des Features, des Product Backlog Items
  • Découper les Product Backlog Items en Task
  • Assigner les différentes Tasks

Ces différents items sont personnalisables en fonction de vos besoins de suivi de projet.Il est aussi possible de les  gérer du portfolio du projet depuis Project 2016 en synchronisant ce dernier avec le projet d’équipe VSTS personnalisé.

Prérequis

  • Avoir un projet VSTS avec un backlog rempli
    • Si ce n’est pas le cas vous pouvez créer un projet rapidement en suivant cet article
  • Installer Project 2016

Au sein de cet article nous utilisons le projet ArticleSyncProject généré par l’utilitaire VSTS Demo Data generator en utilisant le template MyHealthClinic.

Lier VSTS à Project 2016

Depuis Project 2016, on peut créer un lien bidirectionnel avec un projet VSTS pour synchroniser les données.

Etape1

Il est nécessaire de créer une query pour sélectionner les items à synchroniser avec Project 2016.

Dans notre cadre , nous allons créer une query à partir des items présents dans le sprint2.

CreateQuery1

  • Cliquer sur « Create query »
  • Saisir un nom à la query
  • Sélectionner un répertoire

CreateQuery2

Etape 2

Nous pouvons maintenant utiliser Project 2016.

  • Créer un nouveau projet Vide

Project 1

Etape 3

Se connecter au projet d’équipe ArticleSyncProject

  • Aller dans l’onglet Equipe du ribbon
  • Cliquer sur « Choisir un projet d’équipe

Project 2

Dans la fenêtre de choix :

  • Sélectionner le serveur TFS ou l’URL VSTS souhaité
  • Sélectionner la collection  projet d’équipe souhaitée
  • Sélectionner le projet d’équipe à lier
  • Effectuer la connexion en cliquant sur « Connect »

Project 3

Etape 4

Maintenant que votre projet est connecté à votre projet VSTS, vous pouvez récupérer vos items.

  • Dans l’onglet « Equipe » du Ribbon, cliquer sur « Obtenir les différents de travail »

Project 4

Depuis la fenêtre de sélection :

  • Sélectionner la query créée lors de l’étape 1
  • Cliquer sur « Find » récupérer les items
  • Sélectionner tous les items qui vous intéressent
  • Cliquer sur « OK »

Project 5

Etape 5

Vous pouvez maintenant manipuler vos items depuis Project.

  • Cliquer sur « Actualiser » pour les mettre à jour sous Project  depuis VSTS
  • Cliquer sur « Publier » pour les mettre à jour sous VSTS depuis Project

Project 6

Attention, seuls les champs mappés entre VSTS et Project sont synchronisés. 

  • Cliquer sur « Afficher les mappages de colonnes » afin de contrôler quels champs sont synchronisés.

Customiser et Modifier le mappage des colonnes entre VSTS et Project 2016

Nous venons de voir comment lier un projet VSTS à Project 2016.

Dans notre projet d’exemple, ArticleSyncProject, basé sur le Template scrum, on constate que la date de début et  la date de fin des différents items ne font pas partie du mappage avec VSTS. Ainsi les modifications que l’on fera sur Project pour les date de début et de fin ne seront pas sauvegarder dans VSTS.

Ceci est normal si on utilise le Framework Scrum, mais il existe une solution afin de remonter ces informations dans le projet VSTS

Il faut ajouter la date de début et de fin aux types d’items dans le projet VSTS que l’on souhaite synchroniser. Dans notre cas :

  • Product Backlog Item
  • Task

Etape 1

Dans un premier temps nous allons créer un nouveau Template projet héritant du Template scrum de VSTS.

  • Dans les paramètres, cliquer sur « Account Setting »

Template0

Ceci permet d’accéder aux paramètres du VSTS.

  • Aller dans l’onglet « Process »
  • Sélectionner le Template Scrum de VSTS
  • Dans le menu contextuel du Template Scrum, cliquer sur « Create inherited process »

Template1

Dans la fenêtre de création :

  • Saisir le nom du nouveau Template : ScrumProjectTemplate
  • Cliquer « Create Process »

Template2

Etape 2

Maintenant que votre nouveau Template est créé, nous pouvons ajouter les nouveaux champs.

  • Cliquer sur le Template

Template3

Nous allons commencer par modifier les Tasks du nouveau Template.

  • Cliquer sur Tasks

Template5

  • Cliquer sur « New Field »

Template6

Dans la fenêtre d’ajout d’un champ :

  • Sélectionner « Use an existing field »
  • Sélectionner le Field « Start Date »
  • Cliquer sur « Add Field »

Template7

Faire de même pour ajouter le champ « Finish Date » au type « Task »

Template9

 

Répéter les opérations pour ajouter les champs Start Date et Finish Date au type « Product Backlog Item »

Etape 3

Nous pouvons à présent associer notre nouveau Template à notre projet.

Dans le menu contextuel du nouveau Template, ScrumProjectTemplate :

  • Cliquer sur « -> Change  team projects to use ScrumProjectTemplate »

TemplateToProject1

Dans la nouvelle fenêtre :

  • Sélectionner le projet : ArticleSyncProject
  • Cliquer sur « OK »

TemplateToProject2

Un projet d’équipe est associé au Template ScrumProjectTemplate.

TemplateToProjec3

En accédant au détail d’une task du projet ArticleSyncProject, les nouveaux champs sont maintenant présents.

TemplateToProject4

Etape 4

Nous pouvons maintenant modifier le mappage entre Project2016 et VSTS pour synchroniser les 2 nouveaux champs « Start Date » et « Finish Date ».

Pour ceci nous devons utiliser en ligne de commande l’utilitaire TFSFieldMapping que vous trouverez dans :

%programfiles%\Common Files\microsoft shared\Team Foundation Server\15.0

  • Ouvrir l’inviter de commandes en tant qu’Administrateur

Mapping0

  • Saisir : cd %programfiles%\Common Files\microsoft shared\Team Foundation Server\15.0
  • Saisir la commande :

Mapping1

Le fichier de « Mapping.xml » contient le xml suivant :

Mapping2

  • Pour lier les deux nouveaux champs, ajouter les 2 éléments XML suivant :
    • <Mapping WorkItemTrackingFieldReferenceName= »Microsoft.VSTS.Scheduling.StartDate » ProjectField= »pjTaskStart »/>
    • <Mapping WorkItemTrackingFieldReferenceName= »Microsoft.VSTS.Scheduling.FinishDate » ProjectField= »pjTaskFinish »/>
  • Saisir la commande suivante pour charger le nouveau fichier de mapping sur le projet ArticleSyncProject sous VSTS :

Mapping3

Etape 5

Actualisons le mappage entre VSTS et Project 2016.

Pour ceci retournons sur notre fichier Project2016 lier à notre projet VSTS :

  • Cliquer simplement sur « Actualiser »

Mapping4

  • Cliquer sur « Afficher les mappages de colonnes » afin de contrôler quels champs sont synchronisés.

Mapping5

Etape 5

Vous pouvez maintenant modifier les dates de début et de fin dans Project, elles seront synchroniser avec le projet VSTS.

En suivant la procédure décrite dans cette article, vous pourrez ajouter et mapper de nouveaux champs entre VSTS et Project 2016.

Pour modifier le fichier de mappage vous trouverez la liste des noms de champ existant sur votre VSTS :

  • Dans les paramètres, cliquer sur « Account Setting »
  • Aller dans l’onglet « Process »
  • Cliquer sur « Fields »

Mapping6

 

En ce qui concerne le nom de champs sous Project, il suffit de préfixer le nom du champ par : pjtask

  • Par exemple : Text10 => pjTaskText10

Conclusion

En liant VSTS à Project 2016, on peut tirer parti du meilleur des deux.

Avec VSTS, on partage les informations du projet aux différents acteurs :

  • Développeurs
  • Testeurs

Avec Project, le chef de projet peut suivre et modifier rapidement les différentes informations du projet afin d’anticiper le plus tôt possible.

Ce lien entre VSTS et project 2016 demande un peu de travail au début, mais en utilisant les templates VSTS on rentabilise vite cet investissement.

Connecter VSTS à Teams

Objectif

Avec Teams vous pouvez partager un ensemble d’information aux différents membres de l’équipe sans que ceci aille sur le site VSTS du projet.

Prérequis

  • Avoir un projet VSTS avec un backlog rempli (si ce n’est pas le cas vous pouvez créer un projet rapidement en suivant cet article)
  • Installer Teams

Suivre les événements du projet

Par défaut, VSTS notifie par mail différents évènements qui se produisent sur un projet. Par conséquent, notre boîte mail se retrouve vite saturée de mail provenant de VSTS.

Certains de ces évènements sont envoyés par défaut seulement à la personne qui a déclenché l’évènement.

Par exemple, suite au commit du code d’un développeur sur la branche de développement, l’échec ou la réussite du build automatique (cas d’une intégration continue) sera envoyé seulement à ce développeur, par défaut.

En connectant VSTS à Teams, ces différentes notifications peuvent être partagées à l’ensemble de l’équipe projet, sans encombrer les boîtes mail de chacun.

Etape1

Vous devez créer un nouveau canal à votre équipe projet sous Teams

  • Cliquer sur « Ajouter un canal », dans le menu contextuel de l’équipe

Teams1

Dans la fenêtre de création du canal :

  • Saisir le nom du Canal
  • Cliquer sur « Ajouter »

Teams2

Etape 2

Il ne reste plus qu’à créer un connecteur pour que les notifications de VSTS arrivent dans le canal Suivi Backlog.

  • Sélectionner le canal
  • Cliquer sur « Connecteurs » dans le menu contextuel

Teams3

Dans la fenêtre de gestion des connecteurs :

  • Rechercher « Visual »
  • Cliquer sur le bouton « Configurer » du connecteur Visual Studio Team Service

Teams4

Dans la fenêtre de configuration :

  • Sélectionner votre compte de connexion à VSTS
  • Sélectionner le nom de la souscription VSTS

Teams5_1

  • Sélectionner le projet à surveiller

Teams5_2

  • Sélectionner le type d’évènement à surveiller
    • Pour notre exemple : « Elément de travail mis à jour »

Teams5_3

  • Cliquer sur « Enregistrer »

Teams5_4

Lorsque la configuration est faite avec succès, le post suivant apparaît dans le canal :

Teams6

Etape 3

Vous pouvez tester le connecteur en modifiant par exemple une tâche du projet sous VSTS.

Teams7

Selon vos besoins, vous pouvez tester les différents types d’évènement que vous souhaitez écouter dans Teams.

Visualiser le Product Backlog du projet

Dans le canal dédié au projet, il est aussi possible d’ajouter un onglet afin de visualiser rapidement la backlog du projet sous forme de Kanban.

Etape 1

Dans le canal du projet :

  • Ajouter un nouvel Onglet, en cliquant sur « + »

TeamsBacklog1

Dans la fenêtre de sélection d’onglet :

  • Rechercher « VSTS »
  • Cliquer sur l’icône « VSTS »

TeamsBacklog2

  • Entrer vos identifiants de connexion pour VSTS

TeamsBacklog21TeamsBacklog22

Etape 2

Dans la fenêtre de configuration de l’onglet VSTS :

  • Sélectionner un compte de connexion à VSTS

TeamsBacklog3

  • Sélectionner la souscription VSTS
  • Cliquer sur « Continuer »

TeamsBacklog4

Etape 3

  • Sélectionner le projet
  • Sélectionner l’équipe
  • Sélectionner le niveau des items du Backlog à visualiser
  • Cliquer sur « Enregistrer »

TeamsBacklog5

Etape 4

Visualiser et partager avec votre équipe le kanban.

TeamsBacklog6

Attention, seuls les personnes possédant un compte pour se connecter aux projets pourront accéder à cet onglet.

 

Conclusion

Si vous utilisez déjà Teams pour gérer vos projet au sein de vos équipes, connecter VSTS à Teams est pratique. L’ensemble des informations dont vous avez besoin sont maintenant disponible sur un seul outil Microsoft.

Teams permet de visualiser rapidement et simplement certaines informations du projet VSTS, si vous avez besoin de plus de détail passer directement par VSTS.

 

 

 

 

 

 

 

Générer simplement un projet de test sous VSTS

Objectif

Lorsque l’on regarde des articles ou des tutoriaux sur l’utilisation des différentes fonctionnalités de Visual Studio Team Services, on est souvent confronté à cette problématique : je fais mes tests sur quel projet  ?

Dans ce cas on peut :

  • soit créer un nouveau  projet de test sous VSTS. Mais ce dernier est vide, il faut donc passer du temps à tout recréer avant de tester la fonctionnalité qui nous intéresse.
  • soit utiliser un projet existant en cours d’utilisation par une équipe de Delivery. Cette option est relativement dangereuse et hasardeuse, car nos tests vont perturber la stabilité du projet.
  • Soit utiliser un projet de test déjà existant sur lequel on a déjà fait des tests, donc souvent dans un état incertain. Il est donc souvent préférable de supprimer nos projets de test.

L’objectif de cet article est donc de vous présenter un outil en ligne, fourni par Microsoft, qui permet de créer rapidement un projet sous VSTS avec déjà du contenu.

Prérequis

  • Avoir une souscription Visual Studio Team Services avec les droits pour installer des extensions si besoin

Création du projet VSTS

Avec l’utilitaire VSTS Demo Data generator on peut créer rapidement et simplement un projet de test sur sa souscription VSTS.

Ce projet contient déjà :

  • Un repository Git avec du code source
  • Un portfolio complet avec :
    • des Epics
    • des Features
    • des Product Backlogs items
    • et des Tasks
  • Des équipes
  • Des sprints
  • Un process build fonctionnel
  • Un process release

Etape 1

Aller sur la page  :  VSTS Demo Data generator

Etape1

  • Compléter l’URL de votre souscription VSTS
  • Renseigner le jeton de sécurité que vous avez renseigné
  • Cliquer sur « Verify »

Etape 2

Lorsque la vérification de sécurité est validé, la page de création du projet VSTS est affichée.

  • Renseigner le nom du projet
  • Sélectionner le Template projet :
    • MyHealthClinic
    • MyShuttle2
    • PartsUnlimited

Lors de la sélection du Template, l’utilitaire vérifie que les extensions nécessaires ont bien été installées sur votre VSTS. Dans le cas contraire, vous êtes invité à les installer.

Template MyHealthClinic

Etape21

Template MyShuttle2

Etape22

Template PartsUnlimited

Etape23

 

Dans notre cas nous avons choisi le Template MyHealthClinic.

  • Cliquer sur « Create Project »

Etape 3

Lorsque votre projet VSTS est créé, la page récapitulative suivante est affichée :

Resultat

Etape 4

C’est parti pour vos tests

Suppression du projet VSTS

Lorsque vous avez fini d’utiliser votre projet VSTS vous pouvez supprimer ce dernier.

Etape 1

Depuis la page d’accueil de votre compte VSTS, allez dans la page de la vue globale des projets définis dans votre VSTS.

Delete0

 

Etape 2

Dans la liste des projets, sélectionnez le projet à supprimer.

Delete3

  • Dans le menu contextuel, cliquer sur « Delete ».

Etape 3

Confirmer le nom de projet à supprimer dans la fenêtre de suppression.

Delete4

Etape 4

La suppression a été faite avec succès lors de l’affichage de la fenêtre ci-dessous.

Delete6

 

Conclusion

Je trouve cet utilitaire très pratique et simple à utiliser. Je peux enfin faire rapidement des tests sur des projets avec du contenu, sans perturber les équipes qui travaillent sur les autres projets VSTS.

Il manque plus qu’un utilitaire dans le même esprit pour créer les environnements associés à ces projets sur Azure.

 

Migration VSTS vers TFS 2015

Récemment j’ai dû effectuer une migration d’un code source situé sur un VSTS vers le TFS 2015 On-Premise du client. C’est un scénario qui n’est pas officiellement supporté par l’outil TFS Integration Platform, mais je n’ai pas rencontré de soucis majeur (j’ai migré uniquement le code source et non les work items).

Pour rappel TFS Integration Platform est un outil développé par l’équipe ALM Rangers qui permet d’effectuer des migrations entre différentes versions de TFS. Les migrations peuvent être interrompues puis reprises. Cependant cet outil n’est plus mis à jour depuis 2012. A noter pour une migration dans le sens inverse, Microsoft a lancé un outil en preview : TFS Database Import Service for Visual Studio Team Services

Prérequis

  • un serveur SQL (SQL Express peut suffire) plus ancien que SQL Server 2014
  • le compte local qui fait tourner l’application doit pouvoir
    • Être administrateur du poste
    • Créer une base de donnée sur le serveur SQL
    • TFS Source : Être membre du groupe « Project Collection Proxy Service Accounts » et avoir des droits de lecture sur le projet
  • Disposer d’un compte pour le VSTS étant membre du groupe « Project Collection Proxy Service Accounts » et avoir des droits de lecture/écriture sur le projet (il peut être différent du compte local)
  • Visual Studio 2012 Pro ou supérieur (Team Explorer 2012 n’est plus disponible en standalone)

Installation

Après avoir double-cliqué sur le .msi, l’écran ci-dessous apparaît. Ici rien de particulier, installer juste le « TFS Integration Tools ».

Vous arrivez ensuite à cet écran où on vous demande la chaîne de connexion SQL, n’oubliez pas qu’à l’installation l’outil va créer une BDD, votre compte doit donc avoir les droits suffisants sur le serveur.

Bravo l’outil est maintenant installé, passons à la création de la migration !

Migration pas à pas

Voici l’écran d’accueil de l’application. La première chose à faire est de cliquer sur « Create New » (colonne de droite).

Avec l’explorateur Windows allez dans le dossier « Team Foundation Server » si ce n’est pas le cas et choisissez « VersionControl.xml ».

Il faut maintenant configurer la migration, veuillez cliquer sur « Configure » et choisir « VC11 Adapter » :

Sélectionner ensuite votre Team Project de source/cible :

Il ne reste plus qu’à lancer la migration et à résoudre les conflits s’il y en a. A noter que vous pouvez très bien mettre en pause la migration ou la finir une première fois, effectuer quelques commits sur la branche source et la relancer. Cela permet une interruption de service plus courte si une équipe est en train de travailler sur le projet durant la migration.

Une dernière petite astuce pour la route, je conseille de faire la migration sur une nouvelle VM que vous « jetterez » après la migration. Cela évite ainsi de polluer son poste de travail avec une vieille version de VS et de se prémunir d’un éventuel redémarrage de son poste de travail alors que la migration est en cours.

La migration est assez longue car vous aurez surement des conflits à résoudre donc je vous conseille de ne pas l’effectuer si vous avez une quantité importante de données.

 

Mettre en place du déploiement continue en local depuis VSTS

Objectif

L’objectif de cet article est de vous présenter comment mettre en place une chaine de déploiement continue sur un serveur IIS local, hébergé sur votre réseau, à partir de code source stocké dans Visual Studio Team System.

Contexte

Vous stockez  sur VSTS les code sources de vos différents projets applicatifs, mais vous aimeriez mettre en place un chaine de déploiement continue sur vos propres serveurs OnPremise n’ayant pas accès à internet à partir du code source contenu dans votre environnement VSTS.

La solution est de passer par un serveur build intermédiaire qui effectuera aussi le déploiement en local. Ce dernier  aura donc un accès à VSTS et au serveur cible IIS hébergé dans le réseau interne.

VSTS_BuildInterne

Serveur de Build

Nous avons utilisé dans notre cas un serveur de Build avec Windows Server 2012 R2. Mais il est possible d’utiliser le poste de développement en guise de serveur de Build, à condition de respecter les prérequis suivant :

 

L’environnement de développement doit être installé sur le serveur de build et l’agent de build, afin que celui-ci puisse effectuer la compilation du code source contenu dans le VSTS.

Installation et Configuration

Environnement de développement

Il est préférable d’installer et de configurer l’environnement de développement avant de configurer l’agent de build, car ce dernier détecte automatiquement l’environnement du serveur lorsqu’il se connecte à VSTS.

Dans notre cas nous avons installé :

  • Visual Studio 2015 Enterprise, version minimum recommandée
  • NodeJs pour la compilation des less avec gulp
  • Framework 4.6.2

Agent de build

Prérequis de sécurité

Pour installer et configurer l’agent de build, utiliser un compte qui soit à la fois Administrateur du Serveur de build et qui soit administrateur dans VSTS.

Authentification avec un « Personal Access Tokens »
  • Connectez vous sur votre VSTS avec le compte administrateur que vous souhaitez utiliser
  • Ouvrez le profil du compte
  • Allez dans sécurité

PAT_1

  • Allez dans Personal Acces Tokens
  • Cliquez sur PAT_2
  • Cochez seulement le scope Agent Pools (Read, manage), et veillez à laisser les autres décoché

PAT_3.png

  • Cliquez ensuite sur PAT_4

PAT_5

  • Copiez le token ainsi obtenu

Note : Veillez à conserver précieusement le token généré, il sera utile pour configurer et supprimer l’agent.

Installation

Pour installer l’agent sur le serveur de build :

  • Connectez vous sur le serveur de build, avec un compte administrateur
  • Depuis le serveur, connectez vous sur votre VSTS avec un compte administrateur.
  • Allez dans Settings\Agent Pools
  • Cliquez sur  DownLoadAgnet

Une fenêtre contenant les commandes à effectuer pour installer sur différent OS s’ouvre.

DownLoadAgent_2

Lancer le téléchargement à la fin de celui-ci exécuter les commandes PowerShell du bloc Create Agent. Ceci décompressera le zip précédemment téléchargé dans le répertoire C:\agent.

Configuration

Création du pool

Lors de la configuration de l’agent de build, nous allons le rattacher à un pool que nous avons spécialement créé :

  • Connectez vous sur votre VSTS avec un compte administrateur.
  • Allez dans Settings\Agent Pools
  • Cliquez sur « New Pool… » New_Pool
  • Dans la fenêtre de saisie, entrez le nom du nouveau pool : « Interne »

Create_Pool

Agent de build

Nous pouvons passer, maintenant, à la configuration de l’agent de build :

  • Dans la console PowerShell  en tant qu’administrateur, placez vous dans le répertoire où a été installé l’agent
  • Exécuter la commande :Configuration_agent_1

Un assistant de configuration en ligne de commande PowerShell démarre :

Connexion à VSTS :

Configuration_agent_Connection_PS_3
  • Saisissez l’URL VSTS : https://{your-account}.visualstudio.com
  • Sélectionnez le type authentification PAT (précédemment configuré avec le compte que vous utilisé)
  • Saisissez le jeton précédemment généré

Inscription de l’agent sur VSTS :

Configuration_agent_Inscription_PS_4

 

  • Saisissez le nom du pool d’agent précédent créé : Interne
  • Saisissez le nom de l’agent, par défaut il vous propose le nom du serveur : BuildInterne
  • Saisissez le dossier de travail de l’agent : _workVSTS
  • Choisissez de l’exécuter en tant que Service, en saisissant ‘O’
  • Choisissez le compte par défaut

Résultat :

  • Connectez vous sur votre VSTS
  • Allez dans Settings\Agent Queues

Vous  devez voir le résultat suivant :

Configuration_agent_Resultat_VSTS

Vous pouvez utiliser maintenant le pool Interne dans la configuration de vos Builds.

Note : Sur un serveur de build, vous pouvez installer plusieurs agent de build, il faut juste les utiliser des répertoires d’installation différents.

Création d’un Build VSTS

  • Connectez sur VSTS
  • Allez dans « Build & Realease »/Builds

 

Create_Build_1.png

  • Cliquez sur New

Create_Build_2

  • Sélectionnez le Template ASP.NET et cliquez sur « Apply »

Create_Build_3

  • Allez dans l’onglet « Triggers » pour activer l’intégration continue
  • Préciser la branche à surveiller

 

Create_Build_4.png

  • Allez dans l’onglet « Options » pour sélectionner l’agent interne précédemment créé

Create_Build_5.png

  • Allez dans l’onglet « Variables » Afin de modifier :
    • BuildConfiguration selon la configuration souhaitez (Release, Debug, ou une que vous avez créée dans votre solution). Dans notre cas, nous avons créé la configuration de Build « Developpement »

Create_Build_Variables

  • Cliquez sur « Save »

Save_Build_6.png

  • Cliquez sur « Save »

 

Déploiement automatique

L’objectif est déployer automatiquement sur le serveur cible IIS, le dernier package compilé par le pool de build que nous venons de créer avec l’agent « BuildInterne ».

Configuration du serveur Cible

Dans notre cas nous effectuons le déploiement automatique sur un serveur web IIS Windows server 2012 R2.

Sur ce dernier, il faut activer WinRM : Remote Management.

WinRM

Pour activer WinRM sur Windows Server 2012 :

  • Connectez vous sur le serveur Cible
  • Ouvrir sur le serveur Server Manager > Local Server

Server_manager

Site Web Cible

Dans notre exemple, nous allons mettre en place un déploiement automatique sur un site web existant que nous allons créer sur le serveur manuellement. mais cette action est parfaitement automatisable dans le processus de déploiement automatique.

  • Connectez vous sur le serveur cible
  • Ouvrir sur le serveur IIS manager
  • Ajouter un nouveau site Web, par exemple : WebInterne sur un port libre

Note : Pensez bien à ouvrir le port utilisé sur le serveur cible

Créer une release

  • Connectez sur VSTS
  • Allez dans « Build & Realease »/Releases

Create_release_1

  • Cliquez sur « Create release definition »

Create_release_2

  • Sélectionnez Empty et cliquez sur Next
 Create_release_3
  • Sélectionnez votre projet
  • Sélectionnez la définition du build que vous avez précédemment créé
  • Cochez « Continuous Deployement », pour le déploiement s’exécute à chaque nouveau build.
  • Cliquez sur Create

Ajout de tâches

Maintenant que la release a été créé vide, il faut lui ajouter des tâches à exécuter.

Task_release_1.png

  • Modifier le nom de la Release : Interne
  • Liez la release à un package de déploiement :
    • Cliquez sur « Link to an artifact source « Link_to_artefact_release_2.png
  • Sélectionnez la queue de déploiement :
    • Celle que nous avons précédemment créée : Interne

Select_Queue_release_2.png

  • Cliquez sur « Add tasks » :
    • Windows Machine File Copy
      • Ajouter la tache « Windows Machine File Copy », afin de copier le package à déployer sur le serveur cible.Add_Task_Copy_files.PNG
      • Configurez cette tache de copie :
        • Sélectionner le fichier compresser dans le package précédemment lié,Select_Package_release_3
        • Select_Package_release_4
        • Select_Package_release_5
    • WinRM – IIS Web Deployment
      • Ajoutez la tache « WinRM – IIS Web Deployment »Add_Task_Web App Deployment
        • Si cette dernière n’est pas disponible, il faut ajouter l’extension à votre VSTS depuis le market Visual Studio ici.
      • Configurez la tache :
        • WinRM :
          •  Machines : Nom réseau du serveur cible
          • Admin Login/Password : Login et Password d’un compte admin sur le serveur cible
          • Protocol : Sélectionnez le protocole utilisez par le WinRM sur le serveur cible
        • Deploiement :
          • Web Deploy Package : Nom et chemin de copie du package de déploiement, définie dans la tache précédente
          • Website Name : Name du site web précédemment créé : InterneWebApp_release_.png
  • Allez dans l’onglet « Triggers » :
    • Cochez « Continuous Deployment »
    • Sélectionnez le nom du build à surveiller et pour quelle branche le build a été effectuéTriggers_release_.png

 

 

Héberger un package Nuget sur Team Services et l’alimenter depuis une build

Objectif : 

L’objectif de cet article est de vous présenter comment automatiser depuis Team Services la génération d’un ensemble de classes qui seront ajoutées dans un package NUGET hébergé sur TFS online.

Contexte : 

Une solution VS contient un ensemble de classes communes à plusieurs projets.
Ces classes sont regroupées dans des librairies que l’on veut pouvoir accéder depuis NUGET.

vso_nuget_sc1

Création du container sur VSTS : 

Pour créer le container, vous devez aller dans la section « Packages » du menu « Build & Release ». Si vous ne voyez pas le menu, c’est que vous devez préalablement sélectionner un projet.

vso_nuget_sc2

Si vous n’avez pas le menu package depuis votre interface, vous devez aller dans le MarketPlace et installer Package Management (https://marketplace.visualstudio.com/items?itemName=ms.feed)

Vous pouvez alors ajouter un « feed ». Nous vous conseillons de laisser les options par défaut pour le moment.

Une fois créé, il faut modifier les droits de ce dernier. Pour cela aller dans la section « Permission », et ajouter aux contributeurs les comptes « Project Collection Build Service » et « Project Build Service ». Ces deux comptes sont ceux qu’utilisera le Publisher Nuget lors de la Build.

De même vous pouvez restreindre les accès en lecture à certains groupes si vous le désirez.

vso_nuget_sc3

Le container est maintenant créé, il faut l’alimenter.

Création de la Build : 

Nous allons maintenant créer la Build qui générera le package et le mettra dans le feed. Pour cela aller dans Builds et Cliquer sur « New » et choisir une le template Visual Studio.

Dans les étapes, supprimer les modules « Publish symbols path », « Copy Files » et « Publish Articfact », et ajouter les tâches « Nuget Packager » et « Nuget Publisher ».

On peut commencer le paramétrage de chaque étape.

La première consiste à restaurer les packages Nuget nécessaires à la compilation des projets.
Pour cela on sélectionne le path du fichier solution .sln.

vso_nuget_sc4

On procède de la même manière sur l’étape de compilation.

Comme notre solution comporte des tests unitaires, nous laissons l’étape de tests. Ainsi, s’il y a une régression, la build sera en erreur et le package ne sera pas généré.

Concernant l’étape « Nuget Packager », il est possible de spécifier un fichier .sln ; toutes les dlls de la solution seront alors intégrées dans le package, ou préciser un fichier de configuration.
Pour ne pas ajouter des dlls inutiles (celles du framework, celles des librairies de tests), nous faisons le choix de sélectionner un fichier de configuration .nuspec. Ce fichier ajouté manuellement se trouve à la racine de la solution.
Voici le fichier actuellement utilisé :

<?xml version= »1.0″ encoding= »utf-8″?>
<package xmlns= »http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd »&gt;
<metadata>
<id>CommonLibraries</id>
<version>2.0.1</version>
<authors>MCNEXT</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<developmentDependency>true</developmentDependency>
<summary />
<releaseNotes />
</metadata>
<files>
<file src= »0-Services\bin\Debug\0-Entites.dll » target= »lib » />
<file src= »0-Services\bin\Debug\0-Helpers.dll » target= »lib » />
<file src= »0-Services\bin\Debug\0-Repository.dll » target= »lib » />
<file src= »0-Services\bin\Debug\0-Services.dll » target= »lib » />
</files>
</package>

Les données obligatoires sont l’id, le numéro de version et la liste des fichiers.
Le numéro de version est dans ce fichier une valeur fixe. Elle sera écrasée par la build à chaque incrément.

Voici le détail de la configuration :

vso_nuget_sc5

Remarquons que le package généré se trouvera dans le répertoire $(Build.StagingDirectory) et que nous automatisons le versionning en utilisant l’horodatage.

Enfin la dernière étape consiste à publier le package Nuget généré vers le container créé précédemment.
Nous précisons la localisation du package nuget à déployer, tout en supprimant les packages importés lors de la compilation ; le type de Feed, et l’url de ce dernier qui nous a été fournie lors de sa création.vso_nuget_sc6

 

La build est prête, vous pouvez la lancer pour générer votre premier package.

Maintenant nous allons voir comment l’utiliser dans vos solutions.

Importer le package Nuget dans son projet

La première étape est d’ajouter le container à Visual Studio.
Pour cela aller dans Visual Studio, Outils -> Options, ajouter la source de package avec l’url du feed.

Vous pouvez alors ajouter le package Nuget à votre solution/projet en utilisant le package manager de Visual Studio.

vso_nuget_sc8

Il est possible que pour l’installation ou les mises à jour vous ayez besoin de cocher « Include prerelease ».

Importer le package Nuget lors d’une build

Si votre projet consommateur du package Nuget généré est intégré à une build, il faut préciser à l’agent de Build comment récupérer le package pour compiler.

Pour cela, lors de l’étape de restauration du package Nuget, il ne faut pas préciser le path du fichier Solution (.sln) mais plutôt utiliser un fichier de configuration.

Dans chaque solution, nous avons normalement un fichier NuGet.Config dont nous modifions le contenu comme tel :

<?xml version= »1.0″ encoding= »utf-8″?>
<configuration>
<solution>
<add key= »disableSourceControlIntegration » value= »true » />
</solution>
<activePackageSource>
 <add key= »All » value= »(Aggregate source) » />
</activePackageSource>
<packageSources>
<add key= »nuget.org » value= »https://www.nuget.org/api/v2/ &raquo; />
<add key= »CommonLibraries_DEV » value= »https://monurl.pkgs.visualstudio.com/_packaging/CommonLibraries_DEV/nuget/v3/index.json »/&gt;
</packageSources>
</configuration>

Les informations à ajouter sont le paramètre activePackageSource où nous spécifions que nous voulons importer tous les packages.
Et bien sûr, le package à importer.

Dans la configuration d’une build d’un projet, le path est à préciser dans le champs « Path to Nuget.config »

vso_nuget_sc9

 

La build est paramétrée pour importer correctement le package Nuget créé en interne.

 

Nous venons de voir comment configurer un  package Nuget dans VSTS. Cette génération peut très bien être déclenchée dans le cadre d’une intégration continue.

Une étude plus approfondie peut être faite sur la génération du numéro de version pour éviter de rechercher les nouvelles versions du package en cochant ‘pre-release’.