Déploiement web d’entreprise : Vue d’ensemble du scénario

par Jason Lee

Cet ensemble de tutoriels utilise un exemple de solution avec un niveau de complexité réaliste, ainsi qu’un scénario de déploiement d’entreprise fictif, pour fournir une implémentation de référence et pour donner aux tâches et aux procédures pas un contexte commun. Cette rubrique décrit le scénario du didacticiel et présente l’exemple de solution.

Description du scénario

Fabrikam, Inc., une entreprise fictive, crée une solution qui permet aux équipes commerciales à distance de stocker et de récupérer des informations de contact à partir d’une interface web.

Les processus de gestion du cycle de vie des applications (ALM) de Fabrikam, Inc. nécessitent que la solution soit déployée dans trois environnements serveur à différentes étapes du processus de développement logiciel :

• Un environnement de test de développeur ou de bac à sable.
• Un environnement intermédiaire basé sur intranet.
• Environnement de production accessible sur Internet.

Chacun de ces environnements a des exigences de configuration et de sécurité différentes, et chacun pose des défis de déploiement uniques.

Infrastructure serveur Fabrikam, Inc.

Il s’agit de l’infrastructure de développement et de déploiement de haut niveau de Fabrikam, Inc.

Les stations de travail de développeur, l’infrastructure de contrôle de code source, l’environnement de test des développeurs et l’environnement intermédiaire résident tous sur le réseau intranet au sein du domaine Fabrikam.net. L’environnement de production réside sur un réseau de périmètre (également appelé DMZ, zone démilitarisée et sous-réseau filtré), qui est isolé du réseau intranet par un pare-feu. Il s’agit d’un scénario de déploiement courant : vous isolez généralement vos serveurs web internet de votre infrastructure de serveur interne via l’utilisation de pare-feu ou de serveurs de passerelle.

Dans cet exemple :

• Un serveur Team Foundation Server (TFS) 2010 avec un serveur de build distinct fournit des fonctionnalités de contrôle de code source et d’intégration continue (CI).
• L’environnement de test des développeurs comprend un serveur web IIS (Internet Information Services) 7.5 et un serveur de base de données SQL Server 2008 R2.
• L’environnement de production comprend plusieurs serveurs web IIS 7.5 synchronisés par un serveur de contrôleur WFF (Web Farm Framework), ainsi qu’un serveur de base de données SQL Server 2008 R2. Dans la pratique, le serveur de base de données peut utiliser clustering ou la mise en miroir pour améliorer la scalabilité et la disponibilité.
• L’environnement intermédiaire est conçu pour répliquer la configuration de l’environnement de production aussi étroitement que possible.
• Les stratégies de pare-feu et d’isolation réseau n’autorisent pas le déploiement direct et automatisé de l’intranet vers le réseau de périmètre.

La configuration de chacun de ces environnements est décrite plus en détail dans le deuxième tutoriel, Configuration des environnements de serveur pour le déploiement web.

Rôles d’équipe pour ALM

Ces utilisateurs sont impliqués dans la création, la gestion, la création et la publication de la solution Contact Manager :

• Matt Hink est développeur d’applications web chez Fabrikam, Inc. Il fait partie de l’équipe qui a développé la solution Contact Manager à l’aide de Visual Studio 2010. Matt dispose de droits d’administrateur complets sur les serveurs dans l’environnement de test du développeur, ce qui lui permet de configurer l’environnement pour répondre à ses besoins. Il dispose également d’un accès utilisateur à l’instance TFS Visual Studio 2010 où il stocke le code source de la solution Gestionnaire de contacts.

• Rob Walters est administrateur de serveur pour l’équipe de développement de Fabrikam, Inc. Rob dispose d’un accès administratif sur le serveur TFS afin qu’il puisse configurer tous les aspects de TFS et Team Build. Rob dispose également d’un accès administratif aux serveurs web de test et de préproduction et agit en tant qu’administrateur de base de données (DBA) pour les serveurs de base de données dans les environnements de test et de préproduction. Rob a configuré Team Build sur le serveur TFS pour effectuer les tâches suivantes :

  • Générez et exécutez des tests unitaires sur l’application chaque fois qu’un utilisateur archive un fichier sur TFS. C’est ce qu’on appelle CI.
  • Déployez automatiquement l’application Contact Manager dans l’environnement de test une fois que l’application a réussi les tests unitaires. Cela inclut la publication de la base de données sur les serveurs de test lors du déploiement initial et les mises à jour de la base de données après le déploiement initial.
  • Déployez l’application Contact Manager dans l’environnement intermédiaire dans un processus en une seule étape.
  • Créez un package web qu’un administrateur de serveur web et un administrateur de base de données peuvent utiliser pour publier l’application dans l’environnement de production.

• Lisa Andrews est une administrateur de serveur responsable du déploiement des applications sur les serveurs de production Fabrikam, Inc. Elle dispose d’un accès en lecture au partage où TFS Team Build stocke le package de déploiement web une fois qu’il a généré l’application Contact Manager. Elle dispose également d’un accès administratif aux serveurs web de production afin de déployer l’application en production. En outre, elle agit en tant qu’administrateur de base de données qui déploie des bases de données et des mises à jour de base de données sur le serveur de base de données dans l’environnement de production.

La solution Gestionnaire de contacts

La solution Gestionnaire de contacts est conçue pour permettre aux utilisateurs inscrits et connectés d’ajouter et de modifier des informations de contact via une interface web. La solution Contact Manager se compose de quatre projets individuels :

• ContactManager.Mvc. Il s’agit d’un projet d’application web MVC3 ASP.NET qui représente le point d’entrée de la solution. Il offre certaines fonctionnalités d’application web de base, comme fournir aux utilisateurs la possibilité de créer et d’afficher les coordonnées. L’application s’appuie sur un service Windows Communication Foundation (WCF) pour gérer les contacts et une base de données des services d’application ASP.NET pour gérer l’authentification et l’autorisation.
• ContactManager.Database. Il s’agit d’un projet de base de données Visual Studio 2010. Le projet définit le schéma d’une base de données qui stocke les coordonnées.
• ContactManager.Service. Il s’agit d’un projet de service web WCF. WCF expose un point de terminaison qui permet aux appelants d’effectuer des opérations de création, de récupération, de mise à jour et de suppression (CRUD) sur la base de données Contact Manager. Le service s’appuie sur la base de données Contact Manager et l’assembly ContactManager.Common.dll.
• ContactManager.Common. Il s’agit d’un projet de bibliothèque de classes. Le service WCF s’appuie sur les types définis dans cet assembly.

Un examen complet de la solution et de ses exigences de déploiement est fourni dans le premier tutoriel de cette série, Déploiement web dans l’entreprise.

Tâches de déploiement

Il existe plusieurs tâches distinctes impliquées dans le déploiement d’applications dans différents environnements dans une grande organization. Voici les tâches clés couvertes par les tutoriels :

Voici une liste de chaque étape du processus de déploiement du point de vue des utilisateurs décrits précédemment dans ce document :

1. Tous les membres de l’équipe passent en revue la solution Gestionnaire de contacts dans Visual Studio 2010 pour déterminer les exigences et problèmes de déploiement clés.
2. Matt Hink peut déployer la solution Contact Manager directement à partir de la station de travail du développeur vers l’environnement de test du développeur, pour effectuer un test initial de la logique de déploiement.
3. Matt Hink ajoute l’application au contrôle de code source dans TFS.
4. Rob Walters crée différentes définitions de build pour la solution Contact Manager dans Team Build. Une définition de build utilise CI pour déployer la solution dans l’environnement de test du développeur chaque fois qu’un utilisateur vérifie le nouveau code. Une autre définition de build permet aux utilisateurs de déclencher des déploiements dans l’environnement intermédiaire en fonction des besoins.
5. Chaque fois qu’un utilisateur vérifie le nouveau code, Team Build génère automatiquement les composants de la solution, exécute des tests unitaires et déploie la solution dans l’environnement de test du développeur si la build a réussi et que les tests unitaires réussissent.
6. Lorsqu’un utilisateur déclenche un déploiement dans l’environnement intermédiaire, la solution est empaquetée et déployée dans un processus en une seule étape. Ce processus génère également un package pour un déploiement manuel dans l’environnement de production.
7. Lisa Andrews déploie l’application dans l’environnement de production en important manuellement le package web créé à l’étape 6.

Principaux problèmes de déploiement

La solution Gestionnaire de contacts et le scénario Fabrikam, Inc. mettent en évidence divers problèmes et défis courants que vous pouvez rencontrer lorsque vous déployez des solutions complexes à l’échelle de l’entreprise. Par exemple :

• Vous devez être en mesure de déployer des projets dans plusieurs environnements, tels que des environnements de développement ou de test, des plateformes intermédiaires et des serveurs de production. La solution doit être déployée avec des paramètres de configuration différents pour chaque environnement.
• Vous devez déployer simultanément plusieurs projets dépendants dans le cadre d’un processus de génération et de déploiement automatisé ou en une seule étape.
• Vous devez être en mesure de piloter le déploiement à partir d’un processus automatisé. Par exemple, vous souhaitez utiliser un processus CI pour déployer des applications web dans un environnement intermédiaire lors de l’enregistrement du nouveau code.
• Vous devez pouvoir contrôler le processus de déploiement et définir des variables de déploiement en dehors de Visual Studio, car il est peu probable que les développeurs disposent des paramètres de configuration corrects ou des informations d’identification nécessaires pour chaque environnement cible.
• Vous devez déployer des projets de base de données basés sur des schémas et conserver les données existantes lors des déploiements suivants.
• Vous devez déployer des bases de données d’appartenance sur une base ad hoc sans déployer les données de compte d’utilisateur. Vous devrez peut-être également mettre à jour le schéma des bases de données d’appartenance déployées sans perdre les données de compte d’utilisateur existantes.
• Vous devez exclure certains fichiers ou dossiers lorsque vous déployez du contenu dans différents environnements cibles.

En outre, la gestion du déploiement lorsque les mises à jour sont fréquentes et incrémentielles pose des défis supplémentaires. Par exemple :

• Vous exécutez des tests unitaires chaque fois qu’un développeur vérifie le nouveau code. Vous ne souhaitez déployer la solution que si le code réussit les tests unitaires.
• Lorsque vous déployez une application web dans un environnement intermédiaire ou de production, vous souhaitez rediriger les utilisateurs vers un fichier app_offline.htm pendant toute la durée du processus de déploiement.
• Vous souhaitez journaliser les activités de déploiement. Le processus de déploiement doit envoyer Notifications par e-mail de déploiements réussis ou ayant échoué aux destinataires désignés.
• Si un déploiement automatisé échoue, le processus de déploiement doit réessayer le déploiement actuel ou déployer le package web précédent à la place.

PrécédentSuivant