Pages

vendredi 29 juillet 2011

Documentation des principaux scénarii de déploiement avec WebDeploy

Préambule : Ce post est la traduction d’un autre post de Vishal Joshi Senior PM chez MSFT, à qui l’on doit le web-deploy et qui, dans cet article, nous expose les différents scénarii que son équipe vont traiter dans les tutoriaux et procédures à venir sur le sujet.

Le « Nous » employé dans la suite les concernent donc, et pas moi ;)

L'outil IIS Web Deployment (Déploiement Web) et le déploiement de fonctionnalités introduites dans Visual Studio 2010 permettent d'automatiser de nombreuses tâches de déploiement, mais nous savons que de nombreux scénarios courants ne sont pas encore pleinement documentés.
Nous nous attaquons à ce besoin en créant  une procédure pas-à-pas qui vous guidera du début à la fin, par des scénarios qui couvrent des besoins du monde réel.
Notez-bien que ce blog n'est pas une documentation proprement dite mais une aide sur des problèmes réels.
Ce post présente une première série de scénarios que nous avons identifiés et nous sollicitons vos commentaires pour nous aider à déterminer qu'elles sont assez représentatives ou non.
Si vous avez des commentaires, vous pouvez les poster sur le blog de Vishal  ou n'hésitez pas à lui envoyer un email à Vishal.Joshi @ Microsoft.com (in English of course).
Let’s go

Scénario 1: déploiement en entreprise avec l'intégration continue
Dans ce scénario, il y a une solution, qui comprend de multiples projets d'application Web, est déployée sur  des environnements de  test, de staging et de production, en utilisant un processus d'intégration continue pour la staging et la production.

Environnements cibles
L'environnement de test  (TEST) se compose d'un serveur avec IIS 7.5 et un serveur avec  SQL Server 2008 R2. Les développeurs disposent d’un accès vers les serveurs de test, et les développeurs utilisent one-click pour déployer dans l’environnement de test.

L’environnement de pré-production (STAGING) consiste en une ferme de serveurs web (2 serveurs exécutant IIS 7.5) et un serveur de base faisant tourner SQL Server 2008 R2.
Le PC type des développeurs dispose d'une connexion  à accès à un serveur TFS qui sert de référentiel de code source, et ce serveur TFS a accès aux serveurs de pré-production (Les développeurs n'ont pas un accès direct à STAGING, et le développeur n'a pas de droits administratifs sur les serveurs de mise en scène).
Team Build génère la solution Visual Studio, exécute les tests unitaires, et publie sur le STAGING.
Chaque fois que Team Build effectue le  build et le déploiement, il crée simultanément un package de déploiement (un fichier web deploy .zip) qui est utilisé pour le déploiement en production.

L’environnement de production (PROD) est le clone du STAGING, sauf qu’un pare-feu (ou dans domaine différent) empêche l'accès direct pour la publication depuis le serveur TFS. Quand un build  est approuvé, le département IT utilise le package créé par le TFS.

Le schéma ci-dessous illustre ce scénario



Note : Certaines entreprises peuvent, en plus,  avoir un environnement ‘Assurance Qualité’  équivalent au STAGING, toutefois, pour les besoins de cette démonstration, nous n’inclurons pas cet environnement qui, de fait, est très similaire dans son déploiement au STAGING.

Solution ‘Visual Studio’
La solution Visual Studio  devant être déployée,  est constitué de plusieurs projets d'application Web, un projet de bibliothèque de classe, et un projet de test unitaire. Le déploiement doit prendre en compte les considérations suivantes:
  • Un des projets utilise la fonctionnalité ASP.NET membership, et la base de données ‘Membership’ doit être déployée. Ceci ne concerne que le TEST, il ne sera pas déployé sur le STAGING et le PROD.
  • Un des projets utilise une base de données SQL Server qui est accédée via l'Entity Framework (Méthode « Database first », en utilisant un fichier. Edmx). Pour le déploiement initial, pour n'importe quel environnement, seule la structure de la base de données doit être déployée. Pour les suivants, les données déjà saisies en ligne dans cet environnement doivent être préservé.
  • Le projet de bibliothèque de classe crée un assembly pour un contrôle personnalisé qui est utilisé dans l'un des projets. Cette assembly doit être installée dans le GAC dans le cadre du processus de déploiement.
  • Le contrôle personnalisé récupéré une valeur par défaut dans un registre Windows. La valeur de Registre est différente pour chaque environnement et elle est mise à jour lorsque la solution est déployée (Cette utilisation particulière des paramètres de registre n'est pas commune, mais la mise à jour d’un registre est un assez commune, et cela fournit un moyen simple d'intégrer une mise à jour du registre dans le scénario).
  • Le fichier Web.config contient des paramètres qui doivent être différents pour les versions debug et release, et les paramètres doivent être différents pour chaque environnement cible.
  • Un des projets web contient un dossier pour les fichiers Logs. Le processus de déploiement ne doit pas copier ces fichiers et ne doit pas supprimer ces fichiers du dossier sur le serveur cible.
  • Les paramètres IIS de la  gestion d’erreurs et d'authentification doit être mis en place sur le serveur cible pendant le déploiement. Ces paramètres peuvent être identiques pour TEST et sur l'ordinateur du développeur, mais ils sont différents pour STAGING et PROD.

Quelques considérations supplémentaires sur le déploiement s'appliquent uniquement au déploiement automatisé de TFS pour STAGING et PROD :
  • Le déploiement ne devra se produire que si les tests unitaires sont réussis.
  • Les projets Web doivent être précompilés avant le déploiement.
  • Les paramètres IIS pour STAGING et PROD sont issus de l'IIS du serveur TFS. (Ceci est une limitation de la version actuelle de Visual Studio et Web Deploy; quand ce problème sera réglé pour la prochaine version du logiciel, nous espérons nous passer du TFS pour la config IIS (croisons les doigts)
  • App_offline.htm doit être mis en place au début du déploiement et retiré à la fin.
  • Le déploiement doit être loggé (journalisé). Lorsque le déploiement se termine ou échoue, les notifications doivent être envoyées par courriel aux destinataires désignés.
  • Si le déploiement échoue, le package précédent doit être redéployé, ou le déploiement actuel devrait être réessayé.
Illustrations
Les  procédures pour ce scénario se font au travers des tâches suivantes : 
  • Téléchargement de la solution Visual Studio à déployer.
  • Mettre en place le serveur de test.
  • Utilisation de publication en un clic à déployer des serveurs de test:
  • Le déploiement initial.
  • Redéploiement sans un changement de bases de données (par exemple, une mise à jour du code dans une page Web).
  • Redéploiement après avoir fait un changement de schéma de bases de données.
  • Mise en place des serveurs STAGING  et de PROD.
  • Mise en place du serveur de build.
  • Trois déploiements sur STAGING (initial, avec  changement de page web, avec  changement de bases de données).
  • Trois des déploiements sur PROD (initial, avec changement de page web, avec changement de bases de données)
Pour la version de Visual Studio 2010, les mises à jour de bases de données impliquent d’exécuter des scripts SQL dans le cadre du déploiement.

Ces scripts seront créés manuellement; outils tels que TSData et Red Gate (pour les français : PowerAMC) peuvent être utilisés pour générer ces scripts, mais ces outils ne seront pas couverts dans ces procédures. Eventuellement, nous nous pencherons sur ce flux également.

Scénario 2: déploiement en entreprise pour MVC et Entity Framework Code First
Ceci est une variante du premier scénario qui diffère sur :
     
  • Les projets web sont MVC lieu de l’asp.net standard.
  • Entity Framework Code First est utilisé au  lieu du « Database first » (pas de fichier .Edmx).
  • TeamCity  est utilisé en lieu et place de TFS.

Scénario 3: déploiement en entreprise pour les projets de site Web
Une autre variante du premier scénario avec comme différence :

  • Les projets Web  sont des sites web (dans le sens du type de projet VS2010) au lieu d’être des applications web ou MVC.
  • Web Deployment Projects (WDP 2010) sont utilisés.
  • One-click n'est pas disponible pour des projets de site web, donc nous utiliserons  un package de déploiement pour le déploiement sur TEST.
Conclusion
Pour ceux d'entre vous qui travaillez dans des entreprises, ces scénarios vous semblent-ils bien représenter le genre de challenge que vous rencontrez lors des déploiements des applications ASP.NET Web?  Y a-t-il des éléments qui manquent ?
Nous ne pouvons pas répondre à toutes les questions dans ces procédures, mais s'il y a d'autres problèmes que vos équipes rencontrent couramment, nous pouvons les ajouter dans ces procédures.
Vos suggestions et vos commentaires sont les bienvenus.