Gestion du cycle de vie des applications : du développement à la production

par Jason Lee

Cette rubrique montre comment une entreprise fictive gère le déploiement d’une application web ASP.NET via des environnements de test, de préproduction et de production dans le cadre d’un processus de développement continu. Tout au long de la rubrique, des liens sont fournis vers des informations supplémentaires et des procédures pas à pas sur la façon d’effectuer des tâches spécifiques.

La rubrique est conçue pour fournir une vue d’ensemble générale d’une série de tutoriels sur le déploiement web dans l’entreprise. Ne vous inquiétez pas si vous n’êtes pas familiarisé avec certains des concepts décrits ici. Les tutoriels qui suivent fournissent des informations détaillées sur toutes ces tâches et techniques.

Notes

Par souci de simplicité, cette rubrique ne traite pas de la mise à jour des bases de données dans le cadre du processus de déploiement. Toutefois, la mise à jour incrémentielle des fonctionnalités de bases de données est une exigence de nombreux scénarios de déploiement d’entreprise, et vous trouverez des conseils sur la façon d’y parvenir plus loin dans cette série de tutoriels. Pour plus d’informations, consultez Déploiement de projets de base de données.

Vue d’ensemble

Le processus de déploiement illustré ici est basé sur le scénario de déploiement Fabrikam, Inc. décrit dans Déploiement web d’entreprise : vue d’ensemble du scénario. Vous devez lire la vue d’ensemble du scénario avant d’étudier cette rubrique. Essentiellement, le scénario examine la façon dont un organization gère le déploiement d’une application web relativement complexe, la solution Contact Manager, par le biais de différentes phases dans un environnement d’entreprise classique.

À un niveau général, la solution Contact Manager passe par ces étapes dans le cadre du processus de développement et de déploiement :

1. Un développeur vérifie du code dans Team Foundation Server (TFS) 2010.
2. TFS génère le code et exécute tous les tests unitaires associés au projet d’équipe.
3. TFS déploie la solution dans l’environnement de test.
4. L’équipe de développement vérifie et valide la solution dans l’environnement de test.
5. L’administrateur de l’environnement intermédiaire effectue un déploiement « what if » dans l’environnement intermédiaire pour déterminer si le déploiement causera des problèmes.
6. L’administrateur de l’environnement intermédiaire effectue un déploiement en direct dans l’environnement intermédiaire.
7. La solution subit des tests d’acceptation par l’utilisateur dans l’environnement intermédiaire.
8. Les packages de déploiement web sont importés manuellement dans l’environnement de production.

Ces étapes font partie d’un cycle de développement continu.

Dans la pratique, le processus est légèrement plus complexe que celui-ci, comme vous le verrez lorsque nous examinerons chaque étape plus en détail. Fabrikam, Inc. utilise une approche différente du déploiement pour chaque environnement cible.

Le reste de cette rubrique examine les étapes clés de ce cycle de vie de déploiement :

• Prérequis : Comment configurer votre infrastructure de serveur avant de mettre en place votre logique de déploiement.
• Développement et déploiement initiaux : ce que vous devez faire avant de déployer votre solution pour la première fois.
• Déploiement à tester : comment empaqueter et déployer automatiquement du contenu dans un environnement de test lorsqu’un développeur vérifie le nouveau code.
• Déploiement en préproduction : comment déployer des builds spécifiques dans un environnement intermédiaire et comment effectuer des déploiements « what if » pour s’assurer qu’un déploiement ne cause aucun problème.
• Déploiement en production : comment importer des packages web dans un environnement de production lorsque l’infrastructure réseau empêche le déploiement à distance.

Prérequis

La première tâche dans un scénario de déploiement consiste à s’assurer que votre infrastructure de serveur répond aux exigences de vos techniques et outils de déploiement. Dans ce cas, Fabrikam, Inc. a configuré son infrastructure de serveur comme suit :

• TFS est configuré pour inclure une collection de projets d’équipe, des contrôleurs de build et des agents de build. Pour plus d’informations, consultez Configuration de Team Foundation Server pour le déploiement web automatisé .
• L’environnement de test est configuré pour accepter les déploiements à distance à l’aide du service web Deployment Agent (l'« agent distant »), comme décrit dans Scénario : Configuration d’un environnement de test pour le déploiement web et Configurer un serveur web pour la publication web (agent distant).
• L’environnement intermédiaire est configuré pour accepter les déploiements distants à l’aide du point de terminaison du gestionnaire Web Deploy, comme décrit dans Scénario : Configuration d’un environnement intermédiaire pour le déploiement web et Configurer un serveur web pour la publication Web Deploy (gestionnaire de déploiement web).
• L’environnement de production est configuré pour permettre à un administrateur d’importer manuellement des packages de déploiement web dans Internet Information Services (IIS), comme décrit dans Scénario : Configuration d’un environnement de production pour le déploiement web et Configurer un serveur web pour la publication web (déploiement hors connexion).

Développement et déploiement initiaux

Avant que l’équipe de développement de Fabrikam, Inc. puisse déployer la solution Contact Manager pour la première fois, elle doit effectuer les tâches suivantes :

• Créez un projet d’équipe dans TFS.
• Créez les fichiers projet Microsoft Build Engine (MSBuild) qui contiennent la logique de déploiement.
• Créez les définitions de build TFS qui déclenchent les processus de déploiement.

Créer un projet d’équipe

• L’administrateur TFS, Rob Walters, crée un projet d’équipe pour l’application, comme décrit dans Création d’un projet d’équipe dans TFS. Ensuite, le développeur principal, Matt Hink, crée une solution squelette. Il vérifie ses fichiers dans le nouveau projet d’équipe dans TFS, comme décrit dans Ajout de contenu au contrôle de code source.

Créer la logique de déploiement

Matt Hink crée différents fichiers projet MSBuild personnalisés à l’aide de l’approche de fichier projet fractionné décrite dans Présentation du fichier projet. Matt crée :

• Fichier projet nommé Publish.proj qui exécute le processus de déploiement. Ce fichier contient des cibles MSBuild qui créent les projets dans la solution, créent des packages web et déploient les packages dans un environnement de serveur de destination.
• Fichiers projet spécifiques à l’environnement nommés Env-Dev.proj et Env-Stage.proj. Ceux-ci contiennent des paramètres spécifiques à l’environnement de test et à l’environnement intermédiaire, respectivement, comme les chaînes de connexion, les points de terminaison de service et les détails du service distant qui recevra le package web. Pour obtenir des conseils sur le choix des paramètres appropriés pour des environnements de destination spécifiques, consultez Configurer les propriétés de déploiement pour un environnement cible.

Pour exécuter le déploiement, un utilisateur exécute le fichier Publish.proj à l’aide de MSBuild ou Team Build et spécifie l’emplacement du fichier projet spécifique à l’environnement approprié (Env-Dev.proj ou Env-Stage.proj) en tant qu’argument de ligne de commande. Le fichier Publish.proj importe ensuite le fichier projet spécifique à l’environnement pour créer un ensemble complet d’instructions de publication pour chaque environnement cible.

Notes

Le fonctionnement de ces fichiers projet personnalisés est indépendant du mécanisme que vous utilisez pour appeler MSBuild. Par exemple, vous pouvez utiliser directement la ligne de commande MSBuild, comme décrit dans Présentation du fichier projet. Vous pouvez exécuter les fichiers projet à partir d’un fichier de commandes, comme décrit dans Créer et exécuter un fichier de commandes de déploiement. Vous pouvez également exécuter les fichiers projet à partir d’une définition de build dans TFS, comme décrit dans Création d’une définition de build prenant en charge le déploiement.
Dans chaque cas, le résultat final est le même : MSBuild exécute le fichier projet fusionné et déploie votre solution dans l’environnement cible. Cela vous offre une grande flexibilité dans la façon dont vous déclenchez votre processus de publication.

Une fois qu’il a créé les fichiers projet personnalisés, Matt les ajoute à un dossier de solution et les vérifie dans le contrôle de code source.

Créer les définitions de build

En guise de dernière tâche de préparation, Matt et Rob travaillent ensemble pour créer trois définitions de build pour le nouveau projet d’équipe :

• DeployToTest. Cela génère la solution Contact Manager et la déploie dans l’environnement de test chaque fois qu’une case activée se produit.
• DeployToStaging. Cela déploie des ressources d’une build précédente spécifiée dans l’environnement intermédiaire lorsqu’un développeur met en file d’attente la build.
• DeployToStaging-WhatIf. Cela effectue un déploiement « what if » dans l’environnement intermédiaire lorsqu’un développeur met en file d’attente la build.

Les sections suivantes fournissent plus de détails sur chacune de ces définitions de build.

Déploiement à tester

L’équipe de développement de Fabrikam, Inc. gère des environnements de test pour mener diverses activités de test de logiciels, telles que la vérification et la validation, les tests d’utilisabilité, les tests de compatibilité et les tests ad hoc ou exploratoires.

L’équipe de développement a créé une définition de build dans TFS nommée DeployToTest. Cette définition de build utilise un déclencheur d’intégration continue, ce qui signifie que le processus de génération s’exécute chaque fois qu’un membre de l’équipe de développement de Fabrikam, Inc. effectue une case activée-in. Lorsqu’une build est déclenchée, la définition de build :

• Générez la solution ContactManager.sln. À son tour, chaque projet au sein de la solution est généré.
• Exécutez des tests unitaires dans la structure du dossier de solution (si la solution est générée avec succès).
• Exécutez les fichiers projet personnalisés qui contrôlent le processus de déploiement (si la solution est générée avec succès et réussit des tests unitaires).

Le résultat final est que si la solution est générée avec succès et réussit les tests unitaires, les packages web et toutes les autres ressources de déploiement sont déployés dans l’environnement de test.

Comment fonctionne le processus de déploiement ?

La définition de build DeployToTest fournit ces arguments à MSBuild :

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

Les propriétés de package DeployOnBuild=true et DeployTarget= sont utilisées lorsque Team Build génère les projets au sein de la solution. Lorsque le projet est un projet d’application web, ces propriétés indiquent à MSBuild de créer un package de déploiement web pour le projet. La propriété TargetEnvPropsFile indique au fichier Publish.proj où trouver le fichier projet spécifique à l’environnement à importer.

Notes

Pour obtenir une procédure pas à pas détaillée sur la création d’une définition de build comme celle-ci, consultez Création d’une définition de build prenant en charge le déploiement.

Le fichier Publish.proj contient des cibles qui génèrent chaque projet dans la solution. Toutefois, il inclut également une logique conditionnelle qui ignore ces cibles de build si vous exécutez le fichier dans Team Build. Cela vous permet de tirer parti des fonctionnalités de build supplémentaires qu’offre Team Build, comme la possibilité d’exécuter des tests unitaires. Si la build de la solution ou les tests unitaires échouent, le fichier Publish.proj n’est pas exécuté et l’application ne sera pas déployée.

La logique conditionnelle est obtenue en évaluant la propriété BuildingInTeamBuild . Il s’agit d’une propriété MSBuild qui est automatiquement définie sur true lorsque vous utilisez Team Build pour générer vos projets.

Déploiement vers préproduction

Lorsqu’une build répond à toutes les exigences de l’équipe de développement dans l’environnement de test, l’équipe peut vouloir déployer la même build dans un environnement intermédiaire. Les environnements intermédiaires sont généralement configurés pour correspondre aussi étroitement que possible aux caractéristiques de l’environnement de production ou « actif », par exemple, en termes de spécifications du serveur, de systèmes d’exploitation et de logiciels et de configuration réseau. Les environnements intermédiaires sont souvent utilisés pour les tests de charge, les tests d’acceptation par les utilisateurs et les révisions internes plus larges. Les builds sont déployées dans l’environnement intermédiaire directement à partir du serveur de build.

Les définitions de build utilisées pour déployer la solution dans l’environnement intermédiaire , DeployToStaging-WhatIf et DeployToStaging, partagent ces caractéristiques :

• Ils ne construisent rien. Quand Rob déploie la solution dans l’environnement intermédiaire, il souhaite déployer une build existante spécifique qui a déjà été vérifiée et validée dans l’environnement de test. Les définitions de build doivent simplement exécuter les fichiers projet personnalisés qui contrôlent le processus de déploiement.
• Quand Rob déclenche une build, il utilise les paramètres de build pour spécifier la build contenant les ressources qu’il souhaite déployer à partir du serveur de build.
• Les définitions de build ne sont pas déclenchées automatiquement. Rob met manuellement en file d’attente une build lorsqu’il souhaite déployer la solution dans l’environnement intermédiaire.

Il s’agit du processus de haut niveau d’un déploiement dans l’environnement intermédiaire :

1. L’administrateur de l’environnement intermédiaire, Rob Walters, met en file d’attente une build à l’aide de la définition de build DeployToStaging-WhatIf . Rob utilise les paramètres de définition de build pour spécifier la build qu’il souhaite déployer.
2. La définition de build DeployToStaging-WhatIf exécute les fichiers projet personnalisés en mode « what if ». Cela génère des fichiers journaux comme si Rob effectuait un déploiement en direct, mais il n’apporte aucune modification à l’environnement de destination.
3. Rob passe en revue les fichiers journaux pour vérifier les effets du déploiement sur l’environnement intermédiaire. En particulier, Rob souhaite case activée ce qui sera ajouté, ce qui sera mis à jour et ce qui sera supprimé.
4. Si Rob est convaincu que le déploiement n’apporte pas de modifications indésirables aux ressources ou données existantes, il met en file d’attente une build à l’aide de la définition de build DeployToStaging .
5. La définition de build DeployToStaging exécute les fichiers projet personnalisés. Celles-ci publient les ressources de déploiement sur le serveur web principal dans l’environnement intermédiaire.
6. Le contrôleur WFF (Web Farm Framework) synchronise les serveurs web dans l’environnement intermédiaire. Cela rend l’application disponible sur tous les serveurs web de la batterie de serveurs.

Comment fonctionne le processus de déploiement ?

La définition de build DeployToStaging fournit ces arguments à MSBuild :

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

La propriété TargetEnvPropsFile indique au fichier Publish.proj où trouver le fichier projet spécifique à l’environnement à importer. La propriété OutputRoot remplace la valeur intégrée et indique l’emplacement du dossier de build qui contient les ressources que vous souhaitez déployer. Lorsque Rob met en file d’attente la build, il utilise l’onglet Paramètres pour fournir une valeur mise à jour pour la propriété OutputRoot .

Notes

Pour plus d’informations sur la création d’une définition de build comme celle-ci, consultez Déployer une build spécifique.

La définition de build DeployToStaging-WhatIf contient la même logique de déploiement que la définition de build DeployToStaging . Toutefois, il inclut l’argument supplémentaire WhatIf=true :

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

Dans le fichier Publish.proj , la propriété WhatIf indique que toutes les ressources de déploiement doivent être publiées en mode « what if ». En d’autres termes, les fichiers journaux sont générés comme si le déploiement avait été effectué, mais rien n’est réellement modifié dans l’environnement de destination. Cela vous permet d’évaluer l’impact d’un déploiement proposé(en particulier, ce qui sera ajouté, ce qui sera mis à jour et ce qui sera supprimé) avant d’apporter des modifications.

Notes

Pour plus d’informations sur la configuration des déploiements « what if », consultez Exécution d’un déploiement « What If ».

Une fois que vous avez déployé votre application sur le serveur web principal dans l’environnement intermédiaire, le WFF synchronise automatiquement l’application sur tous les serveurs de la batterie de serveurs.

Notes

Pour plus d’informations sur la configuration du WFF pour synchroniser les serveurs web, consultez Créer une batterie de serveurs avec web Farm Framework.

Déploiement en production

Lorsqu’une build a été approuvée dans l’environnement intermédiaire, l’équipe Fabrikam, Inc. peut publier l’application dans l’environnement de production. L’environnement de production est l’endroit où l’application est mise en service et atteint son public cible d’utilisateurs finaux.

L’environnement de production se trouve dans un réseau de périmètre accessible sur Internet. Il est isolé du réseau interne qui contient le serveur de build. L’administrateur de l’environnement de production, Lisa Andrews, doit copier manuellement les packages de déploiement web à partir du serveur de build et les importer dans IIS sur le serveur web de production principal.

Il s’agit du processus général d’un déploiement dans l’environnement de production :

1. L’équipe de développement informe Lisa qu’une build est prête pour le déploiement en production. L’équipe informe Lisa de l’emplacement des packages de déploiement web dans le dossier de dépôt sur le serveur de build.
2. Lisa collecte les packages web à partir du serveur de build et les copie sur le serveur web principal dans l’environnement de production.
3. Lisa utilise le Gestionnaire des services Internet pour importer et publier les packages web sur le serveur web principal.
4. Le contrôleur WFF synchronise les serveurs web dans l’environnement de production. Cela rend l’application disponible sur tous les serveurs web de la batterie de serveurs.

Comment fonctionne le processus de déploiement ?

Le Gestionnaire des services Internet inclut un Assistant Importer un package d’application qui facilite la publication de packages web sur un site web IIS. Pour obtenir une procédure pas à pas sur la façon d’effectuer cette procédure, consultez Installation manuelle de packages web.

Conclusion

Cette rubrique fournit une illustration du cycle de vie du déploiement d’une application web classique à l’échelle de l’entreprise.

Cette rubrique fait partie d’une série de tutoriels qui fournissent des conseils sur différents aspects du déploiement d’applications web. Dans la pratique, il existe de nombreuses tâches et considérations supplémentaires à chaque étape du processus de déploiement, et il n’est pas possible de les couvrir toutes dans une seule procédure pas à pas. Pour plus d’informations, consultez les tutoriels suivants :

• Déploiement web dans l’entreprise. Ce tutoriel fournit une présentation complète des techniques de déploiement web à l’aide de MSBuild et de l’outil de déploiement web IIS (Web Deploy).
• Configuration des environnements de serveur pour le déploiement web. Ce tutoriel fournit des conseils sur la configuration des environnements serveur Windows pour prendre en charge différents scénarios de déploiement.
• Configuration de Team Foundation Server pour le déploiement web automatisé. Ce tutoriel fournit des conseils sur l’intégration de la logique de déploiement dans les processus de génération TFS.
• Déploiement web d’entreprise avancé. Ce tutoriel fournit des conseils sur la façon de relever certains des défis de déploiement les plus complexes auxquels les organisations sont confrontées.

Précédent