Release Management for Visual Studio 2013 est un solution de Déploiement Continu permettant de créer des cycles de release répétables, apportant de la visibilité sur l'activité de déploiement et de la productivité au travers de l'automatisation des déploiements sur l'ensemble des environnements en partant d'un serveur TFS jusqu'à la production.
En s'appuyant sur des chemins de release prédéfinis, des workflows d'approbation pour le déclenchement et la validation des déploiements, l'outil va permettre de rassembler tous les packages nécessaires et procéder au déploiement de ces packages sur les serveurs cibles, le déploiement étant réalisé sous la forme d'un transaction. Une fois le déploiement effectué avec succès, l'outil peut jouer des tests automatiques et ou générer des données de test. Les mêmes étapes sont répétés au travers des différents environnementsRelease Management for Visual Studio 2013 est basé sur un Workflow d'approbation métier, et une configuration centrale et flexible.
Release Management for Visual Studio 2013 est une plate forme d'orchestration que va contribuer à améliorer la coordination et la communication entre le développement, les opérations et l'assurance qualité en vue de diminuer les problèmes inhérent aux mises en production manuelles.
Nous allons au travers de cet article démontrer comment utiliser release management étape par étape dans le cadre d'un scénario simple: le déploiement d'une application .net et la création d'un base de données SQL. Les binaires de l'application seront déployés en s'appuyant sur une build de release TFS automatiquement.
La première chose à faire après avoir installé l'outil va être de configurer le pipeline de release que l'on souhaite mettre en place.
Pour cela, activer l'onglet Administration / Manage Pick lists, cette liste va nous permettre de définir les différentes étapes de notre processus de release, par exemple, DEV, Integration, Preprod, Production. Cette étape est obligatoire, c'est sur ces différentes étapes que vont reposer les chemins de Release
A titre d'exemple, ci dessous, l'édition de l'acion create SQL Database qui utiliser SQLCMD et des arguments:
Les outils vont également permettre d'utiliser des fonctions très intéressantes tel qu'un Msi Deployer, ou un Database Deployer basé sur la technologie DACPAC
Nous avons donc configuré les étapes (Stage), nous allons maintenant construire nos environnements et les releases Paths. Les environnements se composent de machines disponibles sur le réseau sur lesquelles a été installé et configuré le Deployment Agent. POur ajouter de nouveaux serveurs, simplement activer l'onglet Configure Paths / Servers. l'écran affiche les serveurs déjà enregistrés, on peut en créer de nouveaux en cliquant le bouton New, une fonction de Scan permet de les découvrir sur le réseau.
Les serveurs cibles étant configurés, l'étape suivante va consister à configurer les environnements, simplement en ajoutant les serveurs ou stations de travail qui les constituent. Pour cela, activer l'onglet Configure Paths / Environments, La liste des environnements existant est affichée, Cliquer sur New pour créer le nouvel environnement, nous allons ici créer une environnement de Dev puis utiliser la commande Link Existing pour ajouter les serveurs qui vont composer l'environnement (à noter que ces serveurs sont déjà listés dans l'onglet Servers). On créera également les environnements d'intégration , de pré production et de production
La dernière étape va consister à créer le chemin de release pour notre application, pour cela, activer l'onglet : Configure paths / Release Paths puis cliquer sur New, il suffit de nommer le Release Path puis via l'onglet Stages ajouter simplement les différentes étapes que l'on souhaite faire partie de notre pipeline de release, dans l'étape ci dessous, DEV / Integration / PRE PPROD et PRODUCTION. Sauver et fermer
Ci dessous le Release Path que nous venons de créer affiché dans la liste.
Nous avons terminé la partie Paths, nous allons maintenant mettre en place le déploiement de l'application, pour cela nous allons utiliser l'onglet Configure Apps
Notre projet exemple est un calculateur géométrique, pour le déployer, nous allons créer un composant personnalisé basé sur les outils existants, simplement activer l'onglet component, puis cliquer sur New pour le créer. Dans notre exemple, il a déjà été créé et nous allons simplement l'ouvrir en double cliquant dessus.
Le composant a donc un nom et une description, pour la source, il est spécifié qu'il va utiliser l'output de la build TFS définie dans le release Template (étape de configuration que l'on va voir juste après) à partir de la source de la Drop location (\)
activer l'onglet Deployment, dans notre exemple, on utilise l'outil XCopy Deployer pour copier les binaires vers un répertoire cible dans le serveur de l'environnement cible.puis on se place dans l'onglet Release Template, qui va nous permettre de configurer le déploiement proprement dit, c'est l'étape qui peut s'avérer la plus complexe. Dans cet onglet sont affichés les Release Templates existants.
Cliquer simplement sur New pour créer le nouveau Release Template, Entrer un nom et une description pour le Template, choisir un Release Path et configurer la build definition en choisissant le Team project contenant le projet de développement ainsi que la build qui génére les binaires à déployer
Une fois terminé, cliquer sur la bouton Create pour valider
Un Designer graphique s'affiche (basé sur la technologie Workflow Foundation 4.0) permettant de créer la séquence du Déploiement. Nous allons dans le cadre de cet exemple :
Glisser notre serveur cible sur la surface de design et dans la boite graphique du serveur glisser les actions suivantes :
- La création d'un dossier avec Create Folder
- La création de la base de données avec Create Database
- Le déploiement de l'application avec le composant GeometryCalculator Deployer
Ces actions seront alors exécutées sur le serveur cible dans l'ordre de la séquence. Dans le cas ou l'on veut déployer des binaires sur plusieurs serveurs, on va pouvoir paralléliser ces taches.
L'ensemble de la configuration est désormais terminée, la phase de création du Release Template est bien la plus complexe de l'ensemble de ce processus de mise en œuvre d'un pipeline de release.
La dernière étape va consister simplement à consommer l'ensemble des artefacts mis en place afin de créer des Releases puis de déployer ces releases.
Pour ce faire, activer l'onglet Releases puis cliquer sur New, un formulaire de saisie de release s'ouvre, Entre un nom pour la release, dans notre exemple Sample Release V1.0, sélectionner le release Template à exécuter, définir étape cible, par exemple DEV, ainsi que la build (dans notre exemple on utilise Latest afin de déployer la dernière version) Puis cliquer sur Start pour lancer le déploiement de suite ou sur Create Draft pour la lancer plus tard.
Simplement pour vérifier, ci dessous une vue des bases SQL qui ne contient pas de base de données SampleApplicationDB, ainsi que le dossier cible sur le serveur qui est vide.
La première étape lorsque que l'on démarre un release est de l'approuver, pour cela cliquer sur Approve, entrer un commentaire et valider comme montré ci dessous.
Le déploiement est ensuite démarré, on notera le statut Pending ci dessous.
Une fois la transaction de déploiement terminé, le statut est Done et la release est en attente d'approbation du déploiement, qui se fait de la même manière que pour l'acceptation du déploiement
Avant de valider, on vérifie que le déploiement s'est bien passé, ci dessous, on voit que la base de données a été créée avec succès et que les binaires ont été déployés correctement dans le dossier cible.
On peut donc procéder à la validation du déploiement comme montré ci dessous
Et on a le statut final avec un triple Done
En fermant l'écran précédent on revient à l'écran des releases, et on a le statut Released affiché
La suite sera de répéter ce déploiement vers les différents environnements en utilisant les étapes suivantes (stages). Pour passer une release à l'étape suivante, il suffit simplement de l'éditer et de modifier la valeur Target Stage ce qui aura pour effet de réinitialiser un nouveau Workflow de déploiement vers un nouvel environnement. Il faudra en prérequis prendre soin de configurer le release Template pour les différentes étapes.
Ci dessous l'onglet Integration de notre Release Template qui n'est pas configuré de même que Pre prod et Production, il suffit simplement de répéter l'opération précédente, en utilisant un environnement et des serveurs cibles différents;
Aucun commentaire:
Enregistrer un commentaire