• Home

Release Management : retour d’expériences

Introduction

Release Management, désormais intégré dans Visual Studio Team Services, est la nouvelle génération d’outil permettant de délivrer des applications de manière automatisée et continue. Il reprend les fonctionnalités de la précédente version tout en apportant une interface plus riche et plus intuitive. Je vais essayer de vous faire découvrir au travers de cet article les points clé de l’outil. Vous aurez ensuite tous les éléments pour maitriser et accélérer vos déploiements.

Overview

Cette nouvelle version dont l’interface se trouve uniquement dans le portail Web rompt totalement avec les précédentes moutures. Terminé le client lourd et les workflows en XAML, place désormais aux tâches à l’instar du changement effectué dans la partie Build. Disponible dans Visual Studio Team Services, cet outil l’est également dans TFS 2015 depuis l’Update 2.

La principale évolution est la simplification de son interface. Bien trop compliqué auparavant, elle est maintenant beaucoup plus claire et intuitive comme le montre la capture ci-dessous. Sur ce premier écran d’accueil, vous pouvez créer une nouvelle définition de release et consulter le statut de celles déjà présentes. Le bouton « + » permet quant à lui d’en déclencher une nouvelle.

La définition de release est la première étape à franchir. Elle permet de définir le déploiement d’une application sur les différents environnements cibles.

rm vnext

L’onglet « Overview » permet d’avoir un statut sur l’état des environnements. Un environnement correspond à un ensemble de ressources sur lesquelles seront déployés les binaires. On retrouvera classiquement un environnement pour le développement, pour les tests et pour la production. Le déploiement se fait ensuite de manière séquentielle en enchainant chaque environnement l’un après l’autre.

overview

Le bouton release permet d’instancier une nouvelle release. Cette dernière se chargera alors de jouer l’ensemble des scripts sur tous les environnements. La release sera ensuite considérée comme réussite si tous les déploiements sont verts.

Le bouton « Edit » qui se trouve à côté du nom de la release permet de modifier cette dernière. Chaque release se compose d’environnements eux-mêmes composés d’une liste de taches. Ce sont ces tâches qui ont pour but de déployer les différentes briques applicatives.

release

Setup

Release Management est inclus dans VSTS, cet outil est donc disponible facilement comme toutes les autres modules. Cependant pour pouvoir déployer vos applications, il doit s’interfacer avec votre infrastructure.

Avec ou sans Agent ?

Il y a deux moyens différents pour déployer de manière automatisée des applications. La première consiste à utiliser des agents de déploiement installés directement sur les serveurs cibles et la seconde à déployer à distance en utilisant des technologies de prise de commande.

La version actuelle de Release Management ne permet pas pour l’instant de déployer avec des agents sur les serveurs cibles. Il faut donc utiliser des technologies de remoting. Cependant l’équipe produit à annoncer la disponibilité du déploiement via Agent plus tard cette année (blogs msdn). Dès lors les deux modes cohabiteront.

Hosted Agent ou Private Agent ?

RM utilise les mêmes agents que la partie Build. Il est donc possible d’utiliser des agents provisionnés automatiquement ou bien d’installer et de configurer les siens. Généralement on choisira par défaut les agents hébergés. Ensuite suivant les contraintes liées au projet et à l’infrastructure, le choix d’installer un agent privé pourra être fait. Voici les principales raisons pouvant amenées à ce choix :

  • L’agent a besoin d’un outil non disponible sur la version hébergée
  • L’agent déploie des applications dans un data center on premise
  • Les ressources sont dans un réseau avec uniquement un accès sortant vers internet

Il est donc nécessaire avant de lancer un projet d’automatisation des déploiements de bien comprendre les contraintes de l’infrastructure cible afin de positionner au mieux les agents.

Déploiement vers Azure PaaS

Pour déployer vers les services PaaS d’Azure, la première étape consiste à créer un ou plusieurs « Endpoint ». Pour être en mesure de manipuler des ressources Azure, il faut utiliser des identifiants autorisés à effectuer ces manipulations. C’est à cela que servent les endpoints : encapsuler les identifiants pour manipuler Azure.

Il en existe trois types différents. Le choix se fera en fonction des ressources utilisées dans Azure et des tâches de déploiements utilisées. En effet certaine de ces tâches sont compatible avec tous les types tandis que d’autre en requiert un bien spécifique. Il faudra donc au cas par cas vérifier et ajouter le bon endpoint.

endpoints

Aujourd’hui le type à privilégier est celui permettant d’utiliser les éléments Azure regroupé sous la dénomination « Azure Resource Manager ». En renseignant les données issues de la création d’un « Service Principal » dans la rubrique « Applications » de l’active directory associé à votre compte VSTS, vous aurez la possibilité de gérer finement les droits d’accès en utilisant la fonctionnalité RBAC d’Azure.

Déploiement IaaS/On Premise

Les déploiements sur des ressources IaaS ou on premise sont complétement différents car ils font appel à des technologies bien différentes de celles utilisées pour le PaaS. Seul WebDeploy pourra être utilisé dans les deux cas. Pour résumer, on sera dans ce cadre amener à utiliser trois types de technologie :

  • Copie de fichier : cette étape est importante car elle permet de déplacer les binaires depuis l’agent vers le serveur cible.
  • Exécution de scripts à distance : dès lors que les binaires et les scripts d’installation sont disponibles sur le serveur cible, il faut pouvoir les exécuter à distance. Pour cela, dans le monde Windows, WinRM est la technologie de référence.
  • Exécution de script SQL : rien de compliqué ici, il s’agit de déployer les scripts SQL sur une base de données cible.

Les trois exemples ci-dessus sont les plus courant mais ils ne sont pas limitatifs.

Créer & gérer un pipeline de release

Artéfacts

L’objectif d’une release est de déployer les binaires d’une application, il faut donc les lui fournir. Pour cela il faut utiliser l’onglet « Artifacts ». Le premier artéfact doit contenir les binaires et sera dans la majorité des cas une sortie de build (VSTS ou Jenkins).

artifacts

Si votre release utilise des scripts customs, il faudra également les fournir en entrée. Il est possible de les inclure dans le package contenant les binaires cependant il est préférable de les inclure dans une source supplémentaire.

Cette opération à plusieurs avantages. Premièrement elle permet d’obtenir la liste des scripts directement depuis un repository de code sans avoir à passer par une build. Ensuite elle permet de partager les scripts entre tous les projets du compte VSTS. En effet il est probable que plusieurs projets utiliseront les mêmes scripts. Enfin le dernier point non négligeable est de fournir un espace commun de travail pour les Ops séparé des projets. Ainsi ils pourront construire avec les Dev toutes les briques nécessaires à l’usine de déploiement.

Création d’une nouvelle définition de release

Les deux éléments clés d’une définition de release sont les environnements (1) et la configuration (2). Chaque environnement correspond à une partie de votre infrastructure sur laquelle le déploiement aura lieu. Chaque environnement est constitué d’une suite de tâches. Il existe de nombreuses tâches prédéfinies dans RM que vous pouvez utiliser pour accélérer la mise en place du workflow. L’onglet configuration contient les éléments propres à chaque environnement ainsi les éléments globaux. Concrètement les informations liées aux machines et aux services trouveront leur place dans la configuration par environnement tandis que les informations globales iront dans la configuration de la release.

release

Pour accélérer la création de vos définitions de release, il est possible de cloner un environnement ou bien de générer un template. Le clone permet de reproduire à l’identique un environnement dans la même définition. Le template pour sa part à une portée sur le projet. Il faut donc choisir entre l’un ou l’autre en fonction de vos besoins.

Création d’une nouvelle release

Dès que la définition de la release est terminée, il est possible de déclencher un déploiement. Ce déclenchement peut se faire manuellement ou bien de manière automatisée après la fin d’une build. Lors des déploiements manuels, il est possible de choisir quelle version de build sera déployée.

Concernant la gestion des branches, elle se fera au niveau de la build elle-même. Il est bien sûr possible de créer une build pour chaque branche puis de modifier le template de release à chaque nouvelle version mais cette méthode n’est pas recommandée. En effet elle oblige à modifier la définition de le release et peut donc être source d’erreurs. Au lieu de cela je vous recommande de sélectionner la branche au moment de la build. Ensuite le déploiement se fera naturellement avec les binaires issus de la branche précédemment sélectionnée.

Migration d’un template RM existant

Pour les utilisateurs de la version 2013 et 2015 de Release Management, les ALM Rangers proposent un outil de migration du workflow de release (https://github.com/ALM-Rangers/Migrate-assets-from-RM-server-to-VSTS). Cet outil permet d’extraire toutes les étapes de votre pipeline de release actuel et les convertis en script PowerShell.

La stratégie à adopter dans le cadre d’une migration est d’abord d’utiliser les scripts générés par l’outil et de garder le paramétrage (à l’exception des passwords) de la précédente configuration dans les nouveaux scripts. Vous aurez alors la possibilité de valider que votre déploiement fonctionne toujours et effectue les mêmes étapes que celles que vous avez aujourd’hui.

Comme évoqué auparavant, les passwords devront être extrait des scripts car les avoir en clair dans un fichier PowerShell n’est pas une bonne pratique. Cependant seul la version cryptée sera disponible suite à l’extraction car ils sont stockés ainsi en base de données. Il faudra donc créer des variables dans la configuration des environnements et ensuite passer en paramètre ces variables aux scripts utilisés.

Ensuite, lorsque tout fonctionnera parfaitement, vous pourrez découpez vos scripts et intégrer vos paramétrages directement dans RM en procédant environnement par environnement.

La dernière phase consistera à transformer vos actions en tâche RM et ainsi construire votre propre bibliothèque.

Permissions & Sécurité

La gestion des permissions et de la sécurité est un élément majeur lors de l’utilisation d’un outil de release management. Bien qu’aujourd’hui les équipes ont tendances à être multidisciplinaire (DevOps) et à regrouper toute les compétences d’un projet (Feature Team), il n’est pas envisageable de ne pas avoir les bons contrôles sur les déploiements.

L’élément essentiel est de s’assurer que la bonne personne déploie au bon moment sur le bon environnement. Ce contrôle s’effectue à plusieurs endroits dans VSTS et nous allons voir maintenant lesquels.

Endpoints

Comme vue précédemment, pour déployer dans Azure il est nécessaire de créer des « endpoints ». Ce système porte l’authentification et il faut donc sécuriser cet accès. Prenons par exemple celui qui permet de manipuler les ressources de production. Il faut s’assurer que seul les personnes habilitées à manipuler la production y auront accès. Car même si l’on sécurise le workflow de déploiement avec des approbateurs, si les endpoints sont disponibles pour tout le monde, rien n’interdit une personne mal intentionnée de créer une release et d’utiliser cet endpoint pour supprimer toutes les ressources de la souscription Azure par exemple.

Pour sécuriser un endpoint, chacun possède deux groupes de sécurité :

  • Endpoint Administrators
  • Endpoint Readers

Le premier permet de définir qui a le droit de mettre à jour et d’administrer l’endpoint. Pour les environnements sensibles, seul un nombre restreint de personnes y auront accès. Le second groupe permet de définir qui a le droit d’utiliser l’endpoint lors de la création d’un environnement. En cas de tentative de modification de l’endpoint, le message d’erreur suivant apparaitra :

endpoint security

Il est tout de même important de noter que même si une personne ne fait partie d’aucun des groupes ci-dessus, elle pourra quand même initier une release qui utilise l’endpoint. Pour sécuriser cet aspect, il faut avoir recours aux approbateurs, ce que nous allons voir maintenant.

Approbateurs

Cet élément est essentiel pour un pipeline de release. Hormis les personnes ayant totalement automatisé leur processus de tests et de vérification, vous aurez le besoin d’inclure dans votre processus de validation des personnes. Elles seront en charge de valider le bon déroulement de la release.

Pour cela il y a deux types d’approbations : celles effectuées avant le déploiement d’un environnement et celles effectuées après.

approvers

Si l’on prend comme exemple la capture ci-dessus, on constate que l’équipe en charge des tests métiers a à sa charge la validation de l’environnement UAT. Ensuite les OPS prendront le relais pour déclencher la livraison en production. A noter que dans le cas où plusieurs utilisateurs ou groupes doivent valider, il faut la validation d’une personne de chaque groupe pour passer l’étape. Dans le cadre de l’exemple ci-dessus, un DBA et un Release Manager devront donc valider cette étape.

Ressources « on-premise » & IaaS

La sécurisation de ces ressources se fera via l’utilisation de couple utilisateur/mot de passe. Les technologies de type WinRM ou copie de fichiers se basant sur la gestion des droits de Windows, il faudra fournir le bon compte.

La création d’un compte de service est recommandée dans ce cas et il devra être administrateur local du serveur pour éviter tout problème d’accès. Par contre je vous recommande de créer un compte par application ou groupe d’applications. Ainsi si un compte est compromis, il ne mettra pas en péril toute votre infrastructure.

Conclusion

Ceux qui ont déjà utilisé les précédentes versions de Release Management auront compris qu’au-delà d’un changement majeur d’interface, l’outil a été entièrement repensé. Bien qu’encore jeune, Release Management est une brique incontournable de la suite Visual Studio Team Service. De plus son développement rapide lui permettra sans aucun doute de devenir un incontournable lorsqu’il s’agit de Continuous Delivery. Un widget est également disponible et permettra de suivre depuis le Dashboard le statut de chacun de vos environnements.

Asp.Net Core avec Docker & Release Management

Docker est un technologie qui est de plus en plus utilisée et je vous propose de voir comment déployer une application Asp.Net Core en utilisant Release Management et VSTS. L’application utilisée dans cet exemple est composée de trois parties : un front en Angular JS, une Web Api et une base Mongo DB. Je vais donc vous montrer comment déployer et configurer tous ces éléments pour former une application pleinement fonctionnelle.

Les sources de l’application sont disponibles sur GitHub : MultiChannelTodo

Docker

Release Management vNext : configuration avec WebDeploy

Le déploiement d’une Web App dans Azure avec Release Management vNext est relativement simple. La tâche « Azure Web App Deployment » permet de déployer un package WebDeploy en quelques clics. Il est également possible de spécifier une « connection string » qui sera intégrée au Web.config lors du déploiement. Cependant, par défaut, impossible d’utiliser le fichier SetParameters.xml qui est un élément clé de la gestion de la configuration avec WebDeploy. Voyons comment utiliser ce fichier .

azure web app deployment

Configurer WinRM

Ceux qui utilise les nouvelles machines virtuelles dans Azure auront sans doute remarqué que WinRM n’est pas configuré par défaut. Cet état de fait pose problème notamment lors de l’utilisation de Release Management vNext car ce dernier fait un usage intensif de cette technologie. Je vais donc vous montrer comment configurer WinRM sachant que cette technique est valable pour n’importe quelle machine, aussi bien dans Azure que on premise.

WinRM, quel protocole choisir : HTTP ou HTTPS ?

Cette question est souvent la première, quel est le protocole à utiliser. La réponse est simple et est clairement expliqué dans la MSDN : l’utilisation du mode HTTP doit servir uniquement lors des phases de mise au point. Avec un environnement de production, c’est la version sécurisée qui doit être employée. Or comme on peut le constater ci-dessous, par défaut seul la version HTTP est activée, nous allons donc configurer WinRM avec HTTPS.

winrm http

AzureRM avec un agent de build vNext

Dans cet article je vais vous montrer comment utiliser la dernière version des commandes PowerShell AzureRM avec un agent de build vNext.

Différence entre Azure et AzureRM cmdlets

Un nouveau mode de gestion des ressources est apparu dans Azure : Azure Resource Management. Concrètement ce nouveau mode permet de regrouper tous les composants au sein d’un groupe de ressources et ce mode de gestion sera à terme celui qui subsistera. Il me parait donc important de capitaliser dessus pour ne pas avoir à réécrire les scripts PowerShell à l’avenir.

Mais pour bénéficier de toutes les fonctionnalités de ce nouveau mode de gestion, il faut avoir la dernière version des commandes Azure (version > 1.0.0) qui n’est pas disponible sur le Hosted Agent. C’est pourquoi nous allons installer notre propre agent avec la toute dernière version disponible.

Installation de la machine

La première chose à installer est PowerShell 5. J’ai choisi d’utiliser Chocolatey pour gagner du temps :

install powershell 5

Ensuite il faut installer les cmdlets AzureRM. Si comme moi vous avez déjà une version antérieure installée, il faudra la désinstaller au préalable :

install azurerm

La désinstallation est possible directement depuis PowerShell :

remove azure PowerShell package

Quelle version du Framework .Net est installée ?

A priori cette question peut sembler simpliste mais quand on souhaite savoir quelle version du Framework .Net est installée sur une machine, les choses ne sont pas si évidentes. Preuve en est la page de Microsoft pour répondre à cette question : msdn.

Maintenant voyons pourquoi avoir un script donnant la version peut être intéressant : dans mon cas je dois gérer un certain nombre de serveurs de builds. Or en janvier prochain, le 16 pour être précis, le support du Framework 4.5.1 sera terminé. Il faudra donc mettre à jour toutes les machines avant cette date. Or j’ai déjà installé le Framework 4.5.2 sur quelques machines, il me faut donc ce script pour déterminer la liste des machines à mettre à jour. Mais il peut également servir dans beaucoup d’autres situations.

2000px-Microsoft_.NET_Logo.svg

Build App Package avec Visual Studio Online

Dans ce nouveau billet je vais vous montrer comment créer le package d’une application Windows Store. L’objectif est d’automatiser au maximum la validation et la création du package. La seule étape manuelle restante est l’upload du package via le Dashboard du store.

Génération du numéro de version

Avant de pouvoir générer un package, il faut avoir un numéro de version unique pour ce dernier. Il existe de nombreuses options pour numéroter un package, voici donc l’option que j’ai retenue, chaque élément étant séparé par un point :

  • Un numéro de version majeur
  • Un numéro de version mineur
  • Un numéro contenant les deux derniers chiffres de l’année courante suivi du numéro du jour dans l’année
  • Le numéro de révision de la build

Cette combinaison permet d’avoir avec certitude un numéro de version unique et permet surtout d’identifier facilement un package et sa date de génération. Pour achever cette opération, la première étape consiste à créer deux variables qui contiendront les deux premiers numéros :

major minor variables

Migration Windows Phone 8.1 vers Universal App – Partie 2

Dans ce second volet de cette série d’articles sur la migration d’application Windows Phone, je vais vous montrer comment migrer la partie globalisation de votre application. Comme je l’ai dit dans un précédent article, il me semble primordiale d’avoir dans une application du store au minimum deux langues : le français (ou autre) et l’anglais. Nous allons donc voir comment gérer au mieux les différentes ressources pour internationaliser une application.

Principe général

Le principe général n’a pas changé avec Windows Phone 8.1, pour les différentes langues prises en charge, on retrouvera un ou plusieurs fichiers qui contiendront pour un élément donné la traduction correspondante. Ensuite dans l’application, plutôt que d’insérer le texte pour un bouton par exemple, on fera à la place une référence vers la ressource contenant le texte du bouton. Ensuite au chargement de l’application, en fonction des paramètres linguistiques de la machine, le bon fichier de ressources sera chargé et donc l’application sera traduite dans la bonne langue.

Mise en place des fichiers de ressources

Auparavant, l’extension utilisée était le « resx », maintenant il faut utiliser le « resw ». De plus les différents fichiers de ressources devront être placés dans une arborescence spécifique du projet comme le montre la capture ci-dessous. Le répertoire racine « strings » contient pour chaque langue souhaitée un répertoire. Et ce sont ces répertoires qui contiennent les traductions.

project structure

Pour chaque répertoire créé, une langue de traduction sera disponible. Il n’est plus nécessaire de les déclarer dans les propriétés du manifeste de l’application comme auparavant. La seule chose à configurer est la langue par défaut. Comme le montre la capture ci-dessous, il s’agit de l’anglais. Ainsi sur un poste en français, l’application sera traduite. Pour tous les autres pays, l’application sera en anglais.

manifest

Point à noter : il est également possible de traduire le manifeste en utilisant la syntaxe « ms-resource : » comme sur la capture ci-dessus.

Utilisation des traductions dans le code

L’utilisation des fichiers « resw » ne génère plus de classe d’accès aux traductions, il faut donc les créer soit même. Voici un exemple de classe permettant d’accéder aux différentes ressources depuis le code C# :

Il s’agit d’un simple singleton qui fournit un accès simplifier aux différentes ressources.

Voyons ce que cela donne dans le code XAML

C’est maintenant qu’intervient le changement majeur via l’utilisation de la propriété « x :Uid ». C’est cette dernière qui définit quelle entrée dans le fichier « resw » sera utilisée. Voici un exemple :

La première chose que l’on peut remarquer est qu’aucune mention n’est faite à la propriété « Icon » et « Label » du bouton. Et pour cause car ces dernières sont définies dans le fichier « resw » comme le montre la capture suivant :

. resw file

Ainsi pour le bouton « Account », la propriété « Label » sera remplacée par la valeur de l’entrée « Account.Label ». Ce principe est repris pour tous les composants graphiques et à un énorme avantage, vous pouvez stocker la traduction des images et de toutes les propriétés dans un seul et même emplacement.

NuGet 3.0 : what’s new ?

Le 20 juillet dernier, Microsoft nous a livré une nouvelle version du Framework .Net et de Visual Studio. Cette édition 2015 apporte son lot de nouveautés et entre autre une évolution de NuGet : la version 3.0. Je vais donc profiter de cet article pour vous montrer les différentes améliorations apportées à cet outil devenu incontournable dans le développement d’application.

nuget

Diagnostic tools avec Visual Studio 2015

Il existe plusieurs outils dans Visual Studio pour diagnostiquer les problèmes d’une application, le plus connu étant bien sur le débuggeur. Mais il est parfois utile d’avoir une vue plus élargie sur le fonctionnement de son projet. Ainsi la consommation CPU, le nombre d’objets instanciés et les différents événements peuvent mettre en lumière un éventuel problème. Pour cela il existe les « diagnostic tools » dans Visual Studio et ils sont de deux types : ceux qui donnent des informations en « live » et ceux qui collecte les informations pour ensuite les restituer de manière consolidée. Ce sont ces outils que je vais vous présenter dans cet article.

Diagnostic Live

Cet outil permet d’avoir un suivi en temps réel des différents indicateurs. Pour les activer, il suffit d’ouvrir la fenêtre suivante :

show diagnostic tools