Share via

Différences de configuration courantes entre le développement et la production (C#)

  • Article

par Scott Mitchell

Télécharger le PDF

Dans les didacticiels précédents, nous avons déployé notre site web en copiant tous les fichiers pertinents de l’environnement de développement vers l’environnement de production. Toutefois, il n’est pas rare qu’il existe des différences de configuration entre les environnements, ce qui nécessite que chaque environnement dispose d’un fichier Web.config unique. Ce tutoriel examine les différences de configuration classiques et examine les stratégies de gestion des informations de configuration distinctes.

Introduction

Les deux derniers tutoriels ont décrit le déploiement d’une application web simple. Le tutoriel Déploiement de votre site à l’aide d’un client FTP a montré comment utiliser un client FTP autonome pour copier les fichiers nécessaires de l’environnement de développement jusqu’à la production. Le tutoriel précédent, Déploiement de votre site à l’aide de Visual Studio, a examiné le déploiement à l’aide de l’outil Copier un site web et de l’option Publier de Visual Studio. Dans les deux didacticiels, chaque fichier de l’environnement de production était une copie d’un fichier sur l’environnement de développement. Toutefois, il n’est pas rare que les fichiers de configuration dans l’environnement de production diffèrent de ceux de l’environnement de développement. La configuration d’une application web est stockée dans le Web.config fichier et inclut généralement des informations sur les ressources externes, telles que les serveurs de base de données, web et de messagerie. Il décrit également le comportement de l’application dans certaines situations, comme la ligne de conduite à suivre lorsqu’une exception non prise en charge se produit.

Lors du déploiement d’une application web, il est important que les informations de configuration correctes se retrouvent dans l’environnement de production. Dans la plupart des cas, le Web.config fichier dans l’environnement de développement ne peut pas être copié dans l’environnement de production tel qu’il est. Au lieu de cela, une version personnalisée de Web.config doit être chargée en production. Ce tutoriel passe brièvement en revue certaines des différences de configuration les plus courantes ; il résume également certaines techniques permettant de gérer différentes informations de configuration entre les environnements.

Différences de configuration classiques entre les environnements de développement et de production

Le Web.config fichier inclut un assortiment d’informations de configuration pour une application ASP.NET. Certaines de ces informations de configuration sont les mêmes quel que soit l’environnement. Par instance, les paramètres d’authentification et les règles d’autorisation d’URL énoncés dans les Web.config éléments et <authorization> du <authentication> fichier sont généralement les mêmes quel que soit l’environnement. Toutefois, les autres informations de configuration, telles que les informations sur les ressources externes, diffèrent généralement en fonction de l’environnement.

Les chaînes de connexions de base de données sont un excellent exemple d’informations de configuration qui diffèrent en fonction de l’environnement. Lorsqu’une application web communique avec un serveur de base de données, elle doit d’abord établir une connexion, qui s’effectue via une chaîne de connexion. Bien qu’il soit possible de coder en dur la base de données chaîne de connexion directement dans les pages web ou dans le code qui se connecte à la base de données, il est préférable de placer son Web.config<connectionStrings> élément afin que les informations chaîne de connexion se trouvent dans un emplacement unique et centralisé. Souvent, une base de données différente est utilisée pendant le développement de celle utilisée en production ; par conséquent, les informations chaîne de connexion doivent être uniques pour chaque environnement.

Notes

Les prochains tutoriels explorent le déploiement d’applications pilotées par les données. À ce stade, nous aborderons les spécificités de la façon dont les chaînes de connexion de base de données sont stockées dans le fichier de configuration.

Le comportement prévu des environnements de développement et de production diffère considérablement. Une application web dans l’environnement de développement est en cours de création, de test et de débogage par un petit groupe de développeurs. Dans l’environnement de production, cette même application est visitée par de nombreux utilisateurs simultanés différents. ASP.NET inclut un certain nombre de fonctionnalités qui aident les développeurs à tester et à déboguer une application, mais ces fonctionnalités doivent être désactivées pour des raisons de performances et de sécurité dans l’environnement de production. Examinons quelques-uns de ces paramètres de configuration.

Paramètres de configuration ayant un impact sur les performances

Lorsqu’une page ASP.NET est visitée pour la première fois (ou la première fois après sa modification), son balisage déclaratif doit être converti en classe et cette classe doit être compilée. Si l’application web utilise la compilation automatique, la classe code-behind de la page doit également être compilée. Vous pouvez configurer un assortiment d’options de compilation via l’élément Web.config du <compilation>fichier.

L’attribut de débogage est l’un des attributs les plus importants de l’élément <compilation> . Si l’attribut debug est défini sur « true », les assemblys compilés incluent des symboles de débogage, qui sont nécessaires lors du débogage d’une application dans Visual Studio. Toutefois, les symboles de débogage augmentent la taille de l’assembly et imposent des exigences de mémoire supplémentaires lors de l’exécution du code. En outre, lorsque l’attribut debug est défini sur « true », tout contenu retourné par WebResource.axd n’est pas mis en cache, ce qui signifie que chaque fois qu’un utilisateur visite une page, il doit télécharger à nouveau le contenu statique retourné par WebResource.axd.

Notes

WebResource.axd est un gestionnaire HTTP intégré introduit dans ASP.NET 2.0 que les contrôles serveur utilisent pour récupérer des ressources incorporées, telles que des fichiers de script, des images, des fichiers CSS et d’autres contenus. Pour plus d’informations sur le fonctionnement WebResource.axd et la façon dont vous pouvez l’utiliser pour accéder aux ressources incorporées à partir de vos contrôles serveur personnalisés, consultez Accès aux ressources incorporées via une URL à l’aide WebResource.axdde .

L’attribut <compilation> de l’élément debug est généralement défini sur « true » dans l’environnement de développement. En fait, cet attribut doit être défini sur « true » pour pouvoir déboguer une application web ; si vous essayez de déboguer une application ASP.NET à partir de Visual Studio et que l’attribut debug est défini sur « false », Visual Studio affiche un message expliquant que l’application ne peut pas être déboguée tant que l’attribut debug n’est pas défini sur « true » et propose d’apporter cette modification pour vous.

L’attribut ne doit jamais avoir la debug valeur « true » dans un environnement de production en raison de son impact sur les performances. Pour une discussion plus approfondie sur ce sujet, consultez le billet de blog de Scott Guthrie, Ne pas exécuter la production ASP.NET applications avec debug="true" activé.

Erreurs personnalisées et suivi

Lorsqu’une exception non prise en charge se produit dans une application ASP.NET, elle bulle jusqu’au runtime, à quel moment l’une des trois choses se produit :

  • Un message d’erreur d’exécution générique s’affiche. Cette page informe l’utilisateur qu’il y a eu une erreur d’exécution, mais ne fournit pas de détails sur l’erreur.
  • Un message de détails d’exception s’affiche, qui inclut des informations sur l’exception qui vient d’être levée.
  • Une page d’erreur personnalisée s’affiche, qui est une page ASP.NET que vous créez qui affiche le message que vous souhaitez.

Ce qui se passe en cas d’exception non prise en charge dépend de la Web.config section du <customErrors>fichier.

Lors du développement et du test d’une application, il est utile d’afficher les détails de toute exception dans le navigateur. Toutefois, l’affichage des détails des exceptions dans une application en production constitue un risque potentiel pour la sécurité. En outre, il est peu flatteur et rend votre site web peu professionnel. Dans l’idéal, en cas d’exception non prise en charge, une application web dans l’environnement de développement affiche les détails de l’exception tandis que la même application en production affiche une page d’erreur personnalisée.

Notes

Le paramètre de section par défaut <customErrors> affiche le message de détails de l’exception uniquement lorsque la page est visitée via localhost, et affiche la page d’erreur d’exécution générique dans le cas contraire. Ce n’est pas idéal, mais cela garantit que le comportement par défaut ne révèle pas les détails des exceptions aux visiteurs non locaux. Un prochain tutoriel examine la <customErrors> section plus en détail et montre comment afficher une page d’erreur personnalisée lorsqu’une erreur se produit en production.

Une autre fonctionnalité ASP.NET utile pendant le développement est le suivi. Le suivi, s’il est activé, enregistre des informations sur chaque requête entrante et fournit une page web spéciale, Trace.axd, pour afficher les détails de la demande récente. Vous pouvez activer et configurer le suivi via l’élément<trace> dans Web.config.

Si vous activez le suivi, assurez-vous qu’il est désactivé en production. Étant donné que les informations de trace incluent des cookies, des données de session et d’autres informations potentiellement sensibles, il est important de désactiver le suivi en production. La bonne nouvelle est que, par défaut, le suivi est désactivé et que le Trace.axd fichier n’est accessible que via localhost. Si vous modifiez ces paramètres par défaut dans le développement, assurez-vous qu’ils sont de nouveau désactivés en production.

Techniques de gestion des informations de configuration distinctes

Le fait d’avoir différents paramètres de configuration dans les environnements de développement et de production complique le processus de déploiement. Dans les deux didacticiels précédents, le processus de déploiement consistait à copier tous les fichiers nécessaires du développement à la production, mais cette approche ne fonctionne que si les informations de configuration sont identiques dans les deux environnements. Il existe diverses techniques de déploiement d’une application avec des informations de configuration variables. Nous allons cataloguer certaines de ces options pour les applications web hébergées.

Déploiement manuel du fichier de configuration de l’environnement de production

L’approche la plus simple consiste à gérer deux versions du Web.config fichier : l’une pour l’environnement de développement et l’autre pour l’environnement de production. Le déploiement d’un site en production implique la copie de tous les fichiers sur le serveur de production dans l’environnement de développement, à l’exception du Web.config fichier. Au lieu de cela, le fichier spécifique à l’environnement Web.config de production est copié en production.

Cette approche n’est pas très sophistiquée, mais elle est facile à implémenter, car les informations de configuration changent rarement. Il fonctionne mieux pour les applications avec une petite équipe de développement qui sont hébergées sur un serveur web unique et dont les informations de configuration sont rarement modifiées. Il est plus tenable lors du déploiement manuel des fichiers d’application à l’aide d’un client FTP autonome. Lorsque vous utilisez l’outil Copier le site web ou l’option Publier de Visual Studio, vous devez d’abord échanger le fichier spécifique Web.config au déploiement avec celui spécifique à la production avant le déploiement, puis les échanger une fois le déploiement terminé.

Modifier la configuration pendant le processus de génération ou de déploiement

Jusqu’à présent, les discussions ont supposé un processus de génération et de déploiement ad hoc. De nombreux grands projets logiciels ont des processus plus formalisés qui utilisent des outils open source, maison ou tiers. Pour de tels projets, vous pouvez probablement personnaliser le processus de génération ou de déploiement afin de modifier de manière appropriée les informations de configuration avant qu’elles ne soient envoyées en production. Si vous générez votre application web à l’aide de MSBuild, de NAnt ou d’un autre outil de génération, vous pouvez probablement ajouter une étape de génération pour modifier le Web.config fichier afin d’inclure les paramètres propres à la production. Ou votre workflow de déploiement peut se connecter par programmation au serveur de contrôle de code source et récupérer le fichier approprié Web.config .

L’approche réelle pour obtenir les informations de configuration appropriées en production varie considérablement en fonction de vos outils et de votre workflow. Par conséquent, nous n’allons pas approfondir ce sujet. Si vous utilisez un outil de génération populaire comme MSBuild ou NAnt, vous pouvez trouver des articles de déploiement et des tutoriels spécifiques à ces outils via une recherche web.

Gestion des différences de configuration via le projet de déploiement web Add-In

En 2006, Microsoft a publié le projet de développement web Add-In pour Visual Studio 2005. Un Add-In pour Visual Studio 2008 a été publié en 2008. Cette Add-In permet aux développeurs ASP.NET de créer un projet de déploiement web distinct en même temps que leur projet d’application web qui, une fois généré, compile explicitement l’application web et copie les fichiers à déployer dans un répertoire de sortie local. Le projet d’application web utilise MSBuild en arrière-plan.

Par défaut, le fichier de l’environnement de Web.config développement est copié dans le répertoire de sortie, mais vous pouvez configurer le projet de déploiement web pour personnaliser le

informations de configuration qui sont copiées dans ce répertoire des manières suivantes :

  • Via Web.config le remplacement de section de fichier, dans lequel vous spécifiez la section à remplacer et un fichier XML qui contient le texte de remplacement.
  • En fournissant un chemin d’accès à un fichier source de configuration externe. Lorsque cette option est sélectionnée, le projet de déploiement web copie un fichier particulier Web.config dans le répertoire de sortie (plutôt que dans le Web.config fichier utilisé dans l’environnement de développement).
  • En ajoutant des règles personnalisées au fichier MSBuild utilisé par le projet de déploiement web.

Pour déployer l’application web, générez le projet de déploiement web, puis copiez les fichiers du dossier de sortie du projet dans l’environnement de production.

Pour en savoir plus sur l’utilisation du projet de déploiement web case activée cet article sur les projets de déploiement web du numéro d’avril 2007 de MSDN Magazine, ou consultez les liens de la section Autres lectures à la fin de ce didacticiel.

Notes

Vous ne pouvez pas utiliser le projet de déploiement web avec Visual Web Developer, car le projet de déploiement web est implémenté en tant que Add-In Visual Studio et les éditions Visual Studio Express (y compris Visual Web Developer) ne prennent pas en charge les compléments.

Résumé

Les ressources externes et le comportement d’une application web en développement sont généralement différents de ceux d’une même application en production. Par instance, les chaînes de connexion de base de données, les options de compilation et le comportement lorsqu’une exception non gérée se produit diffèrent généralement d’un environnement à l’autre. Le processus de déploiement doit tenir compte de ces différences. Comme nous l’avons vu dans ce tutoriel, l’approche la plus simple consiste à copier manuellement un autre fichier de configuration dans l’environnement de production. Des solutions plus élégantes sont possibles lors de l’utilisation du projet de déploiement web Add-In ou avec un processus de génération ou de déploiement plus formalisé qui peut prendre en charge ces personnalisations.

Bonne programmation !

En savoir plus

Pour plus d’informations sur les sujets abordés dans ce didacticiel, consultez les ressources suivantes :

PrécédentSuivant