juin 04 2010

[Visual Studio 2010] Déploiement Web Partie 3 - Web Packaging

 Suite de la série de billets sur le déploiement Web avec Visual Studio 2010 :

C'est LA nouveauté qui va révolutionner le déploiement d'applications Web, mais aussi faciliter la vie aux développeurs, aux administrateurs IIS et, dans une moindre mesure aux administrateurs de base de données qui seront beaucoup moins sollicités lors des déploiements. Comme expliqué précédemment, l'étape du déploiement dans un projet est souvent source de problèmes mais aussi de pertes de temps du fait des nombreuses opérations manuelles à réaliser. Les Web Packages vont nous permettre d'automatiser tout cela.

 

Qu'est ce qu'un Web Package

Un Web Package est une unité atomique, transparente et descriptive qui représente votre application Web et qui permet de la déployer facilement sur n'importe quel serveur Web IIS. C'est un fichier .zip qui contient non seulement le contenu du site, mais aussi ses dépendances comme les paramètres IIS, les bases de données, les Assemblies du Global Assembly Cache(GAC), les clés de registres, les paramètres de sécurité, etc.

Ce nouveau concept pour le déploiement d'applications Web a été introduit avec l'outil Microsoft Web Deployment Tool, mais sera démocratisé avec l'arrivée de Visual Studio 2010.

 

Présentation de Microsoft Web Deployment Tool (ou MsDeploy, ou Web Deploy)

Microsoft Web Deployment Tool, ou MS Deploy, est un nouvel outil proposé par l'équipe de développement IIS qui simplifie la migration, la gestion et le déploiement de serveurs IIS, de Web Applications et de Web Sites. Les administrateurs peuvent utiliser la fonction de script en ligne de commande avec MsDeploy pour synchroniser IIS 6.0 et 7.0 ou bien pour migrer un serveur IIS 6.0 vers un serveur IIS 7.0.

Pour cet article et plus généralement en ce qui concerne les développeurs, cet outil permet aux utilisateurs délégués d'utiliser IIS Manager pour déployer des applications ASP.NET (mais aussi PHP) sur un serveur IIS 7.0. MsDeploy est intégré avec PowerShell, Visual Studio 2010 et est compatible avec le Web Platform Installer.

 

Comment fonctionne le déploiement Web avec Visual Studio 2010 et MSDeploy

Visual Studio 2010 utilise MsDeploy dans les coulisses pour faciliter le déploiement des applications Web. Afin de mieux maîtriser le Packaging de vos futures applications développées en ASP.NET 4.0, il convient de jeter un oeil sur le fonctionnement de cet outil.

MsDeploy vous permet de déployer un site ou de répliquer celui-ci sur une ferme de serveurs Web en utilisant une application Web d'origine ainsi que ses dépendances. Pour résumer, MsDeploy utilise un concept très simple : il s'agit d'utiliser une source pour l'appliquer à une destination. Essayons de comprendre quelles sont les sources et les destinations possibles.


Source :
  • si vous souhaitez déployer le site que vous développez sur votre machine de développement, alors ce site devient la source ;
  • si vous avez votre contenu Web stocké dans un gestionnaire de sources et que vous avez une usine de développement qui est paramétrée pour compiler et déployer automatiquement, alors l'usine de développement devient la source ;
  • si un Web Package vous est envoyé par quelqu'un et que vous tentez de l'installer sur votre machine de développement, alors ce Web Package devient la source.
 
Destination :
  • si vous déployez une application Web sur un serveur de test, alors ce serveur de test est la destination ;
  • si vous créez un Web Package de votre application en utilisant MsDeploy, alors ce Web Package devient la destination ;
  • si vous déployez sur votre machine de développement pour des tests, alors dans ce cas, votre machine devient la destination.
 

Comme vous avez pu le constater, les concepts de source et de destination sont assez simples. La raison pour laquelle ils sont si intéressants est que lorsque vous configurez vos paramètres de déploiement dans Visual Studio 2010, celui-ci crée quelque chose que nous appelons Source Manifest, qui est en fait un fichier XML. Ce fichier alimente MsDeploy lors de la création du Web Package. Ci-dessous, un schéma représentant les concepts évoqués précédemment :


Process de génération de Web Package


Source Manifest est un simple fichier XML qui indique à MsDeploy quelles sont les Providers à invoquer sur la machine source. La question qui se pose est : qu'est ce qu'un Provider MsDeploy ? Un provider MsDeploy est un module que le moteur MsDeploy invoque pour réaliser deux principales tâches conceptuelles :

  • sur la machine source pour obtenir le contenu directement depuis son emplacement. Par exemple, si vous avez une base de données attachée à votre site Web, alors le DB Provider utilisera la source pour extraire les données et le schéma de la base afin de les convertir en script SQL qui sera inclus dans le Web Package ;
  • sur la machine de destination pour mettre le contenu au bon endroit, par exemple, s'il y avait des scripts SQL inclus dans le Web Package, alors sur la machine de destination, le DB Provider sera appelé pour exécuter ces scripts et ainsi mettre en place la base de données.

MsDeploy est fourni avec de nombreux providers comme :

  • un provider pour les paramètres IIS (pour les versions 5.1, 6.0, et 7.0) ;
  • DB Provider pour SQL Server ;
  • un provider pour gérer le Global Assembly Cache (GAC) ;
  • un provider pour gérer les objets COM ;
  • un provider pour gérer les clés de registres ;
  • etc.
 

En se basant sur les paramètres de votre projet, Visual Studio 2010 crée un fichier XML Source Manifest qui servira à alimenter MsDeploy pour créer un Web Package ou déployer votre application Web. Le schéma ci-dessous montre comment MsDeploy procède :


En plus de créer le fichier XML Source Manifest, Visual Studio 2010 crée également le fichier Destination Manifest pour vous. Lorsque vous êtes prêt à le déployer sur la machine de destination, vous pouvez alimenter MsDeploy avec le Web Package et le Destination Manifest. Vous pouvez bien entendu changer dans le Destination Manifest des paramètres comme le nom de l'application dans IIS, ou bien la Connection String pour votre base de données de production.

Il n'est évidement pas possible d'avoir un provider pour chaque besoin des développeurs. Néanmoins, la liste fournie par défaut en comble une bonne partie. Surtout, et comme indiqué sur le schéma précédent, il est possible de créer soi-même un provider pour MsDeploy.

 

Les avantages à utiliser des Web Packages

Pour vous démontrer rapidement les avantages à utiliser des Web Packages, je vais m'inspirer de 10 bonnes raisons citées par Vishal Joshi (Senior Program Manager chez Microsoft).

  1. Avoir tout votre contenu Web et ses dépendances comme les paramètres de IIS ou de votre base de données dans un seul fichier .zip vous permet de transporter votre application facilement n'importe où.
  2. Si le Web Package contient également le code source de l'application, vous pouvez répliquer facilement votre environnement de développement sur un autre poste. Imaginez être en mesure de recréer un projet sur votre propre machine en recevant par mail un simple fichier .zip.
  3. Si vous déployez votre application sur une ferme Web, alors le déploiement du Web Package vous facilitera grandement la tâche.
  4. Si vous développez votre application pour que la communauté l'utilise, alors partager le fichier .zip du Web Package vous permettra de créer un modèle utilisable très facilement
  5. La Web Application Gallery de Microsoft, qui dans un avenir proche va devenir le lieu par excellence pour trouver des applications Web réutilisables, utilise le format des Web Packages. Donc, créer un Web Package vous donne l'opportunité de rendre votre application disponible dans la Web Application Gallery.
  6. La plupart des processus de création de Web Packages sont automatisés et vous n'avez pas besoin d'écrire des actions personnalisées, comme c'est le cas avec Microsoft Windows Installer (MSI).
  7. La création de Web Packages peut être automatisée avec vos compilations nocturnes très facilement en utilisant MsBuild avec des systèmes comme Team Build ou Cruise Control.
  8. Vous pouvez créer un Web Package pour différentes version de votre application Web et facilement utiliser des packages correspondant à une version pour permettre un rollback vers n'importe quelle version. Cette fonctionnalité est très utile pour les mises à jour d'applications critiques en production.
  9. Vous obtenez gratuitement l'interface graphique standardisée pour installer les Web Packages avec IIS Manager. Et si vous n'aimez pas utiliser l'interface graphique, le Web Package peut être installé en mode ligne de commande.
  10. La plupart des outils automatisés, les providers, nécessaires au Packaging de votre application Web et à ses dépendances sont à disposition.

 

Création de Web Packages avec Visual Studio 2010 et MSDeploy

Entrons maintenant dans le vif du sujet avec un exemple. Reprenons le projet WebApplicationBidon qui, comme son nom l'indique, est un projet de type Web Application et non un Web Site. En regardant dans Visual Studio 2010 la fenêtre Propriétés de votre projet (clic droit sur le projet puis Propriétés ou ALT+Enter lorsque le projet est sélectionné, pour aller plus vite), vous remarquez que de nouveaux onglets ont fait leur apparition par rapport à la version 2008. Il s'agit des onglets " Package/Publish Web " et " Package/Publish SQL ". Nous allons nous intéresser au premier, le second sera abordé plus loin, dans la partie expliquant le déploiement de base de données avec les packages. Voici le contenu de ce nouvel onglet :



Pour ce nouvel onglet, regardons plus en détail les différentes options affichées.

  • Configuration et Platform : ces éléments ne sont pas nouveaux puisque déjà présents dans Visual Studio 2008. La configuration en mode débug est très utile par exemple pour déployer l'application sur un serveur de test et avoir notamment accès au PDB. Le mode Release l'exclut. Il est utile de rappeler que l'on peut très bien créer soi-même d'autres modes de configuration, par exemple pour l'environnement UAT. Pour ce faire, allez dans le menu Build puis Configuration Manager.
 

La première section Items to deploy permet de décider quel type de contenu vous voulez réellement déployer ou inclure dans votre Package. Elle s'applique donc à tous les types de déploiement.

  • Fichiers à déployer : cette première liste est réglée par défaut sur « Only files needed to run this application ». Cette option est rarement changée car elle permet d'inclure tous les fichiers de votre projet, à l'exception du code source, des fichiers projets et d'autres types de fichiers non nécessaires au déploiement. Les autres options sont « All files in this project » (tous les fichiers inclus dans le projet sont déployés sur le serveur de destination. Les fichiers qui sont dans le dossier du projet, mais non inclus dans le projet sont exclus) et « All files in this project folder » (tous les fichiers du dossier du projet, même exclus du projet sont déployés).
  • Exclude generated debug symbols : ne pas cocher cette option implique que les fichiers .pdb seront déployés sur le serveur. Ces fichiers sont nécessaires pour le débugage, mais généralement utilisés sur un serveur de test et non un serveur de production.
  • Exclude files from the App_Data folder : le dossier App_Data dans la version Web Developer de Visual Studio peut être considéré comme un magasin de données. Il est créé en-dessous du dossier racine du site et est généralement utilisé pour stocker les fichiers .mdf de SQL Server Express, ou encore les fichiers XML. Il vous suffit de cocher cette case pour exclure du déploiement les fichiers contenus dans ce dossier.
 

La deuxième section Items to deploy est consacrée uniquement aux déploiements via Web Deploy.

  • Include all databases configured in Package/Publish SQL tab : cette option vous permet de spécifier si vous voulez ou non inclure toutes les bases de données que vous avez paramétrées dans l'onglet Package/Publish SQL. Si cette case n'est pas cochée, aucun script SQL ne sera exécuté lors du déploiement.
  • Include all IIS settings as configured in IIS Manager : cette option est très utile car elle vous permet d'inclure dans le déploiement, les paramètres du site dans IIS. En cliquant sur le lien Open Settings à droite, vous arrivez directement dans le Gestionnaire IIS pour visualiser ces paramètres. Attention tout de même, dans le cas du serveur d'un hébergeur ou d'un serveur de production de votre entreprise, vous n'aurez surement pas les droits nécessaires. Par contre, pour déployer facilement tous les paramètres IIS sur un environnement de DEV ou UAT cela s'avère très utile. Si vous cochez cette option, vous pourrez également sélectionner « Include application pool settings used by this Web project », ce qui vous permettra d'inclure également les paramètres de l'App pool dans le déploiement sur IIS
 

La troisième et dernière section est celle qui nous intéresse le plus : les Web Deployment Package Settings. Dans cette dernière, nous allons pouvoir définir comment le Web Package sera créé et où il doit être déployé.

  • Create deployment package as a zip file : cette case à cocher permet de spécifier si vous désirez inclure votre Web Package dans un fichier .zip (très utile pour le partage entre développeurs ou dans la communauté), ou si vous désirez simplement qu'il soit sous forme de dossier. Notez que la deuxième option se révèle aussi utile, si vous souhaitez comparer les fichiers contenus dans le dossier entre deux versions du packages (avec l'outil WinMerge par exemple).
  • Location where package will be created : permet de spécifier le path dans lequel sera créé le package. Selon que la création d'un fichier .zip sera cochée ou non, vous obtiendrez un fichier zip portant le nom de votre projet ou un dossier.
  • IIS Web site/application name to user on the destination server : vous permet de spécifier quel site sera utilisé et quel nom portera votre application sur le serveur IIS de destination. Par défaut, l'application est déployée sur le site « Default Web Site »
  • Physical path of Web application on destination server : cette option n'est disponible que si vous avez décidé d'inclure les paramètres IIS dans votre Web Package. C'est aussi une des informations des plus importantes à inclure dans votre Package, même si vous aurez la possibilité de changer ce chemin dans IIS lors du déploiement.
  • Password used to encrypt secure IIS settings : vous permet de spécifier un mot de passe afin de sécuriser les paramètres IIS inclus dans le Package.
 

L'ensemble des options de cet onglet décrit, passons maintenant à la création d'un Package pour l'application WebApplicationBidon. Pour ce faire c'est très simple : un clic droit sur l'application puis Build Deployment Package, comme indiqué sur la figure ci-dessous.


 
 

Observons maintenant les fichiers qu'à généré Visual Studio dans le sous-dossier obj/Debug du projet :



On peut noter quatre fichiers importants :

  • le Web Package lui-même : ce peut être comme ici un fichier .zip qui correspond en fait au contenu du dossier PackageTmp, ou bien un simple dossier si on a choisi de ne pas utiliser le format .zip pour notre package ;
  • le script de commande .deploy : ce script créé par Visual Studio encapsule les commandes MSDeploy afin de nous permettre ne de pas avoir à taper une seule commande pour installer le package ;
  • le fichier Source Manifest qui, comme indiqué précédemment, est un simple fichier XML qui indique à MsDeploy quels sont les Providers à invoquer sur la machine source ;
  • le fichier Set Parameters qui est un fichier XML comprenant les paramètres que nous avons spécifiés pour le déploiement.
 

Regardons de plus près le contenu des deux fichiers XML. Tout d'abord, le fichier Source Manifest :



Et le fichier SetParameters :



Comme on peut le constater, ces deux fichiers contiennent les principaux paramètres utiles au déploiement comme le nom de l'application dans IIS, la Connection String, etc. On peut également indiquer au provider setAcl une Access Control List (ACL) pour un fichier ou un dossier. Les ACL sont utilisées pour définir l'accès et les permissions qu'un utilisateur ou une application possède pour un fichier ou un dossier.

Ces paramètres sont donc facilement modifiables en cas de changement de dernière minute.


info Si vous désirez inclure dans votre Package la modification de clés de registre, l'équipe Visual Web Développer donne une solution sur son blog. De même, ce billet explique comment inclure dans un Web Package le déploiements de composant COM.

Tags: , , , , , , ,

Les commentaires sont clos