Générez une fois et déployez dans plusieurs environnements avec msdeploy et Visual Studio 2012
Travailler sur la centralisation des configurations, des paramètres d'application et des chaînes de connexion, pour plusieurs solutions, tout en passant également à l'utilisation de msdeploy à partir de la ligne de commande pour déployer des applications Web. Idéalement, je voudrais créer les packages une fois et obtenir des configurations à jour au fur et à mesure du déploiement des packages dans chaque environnement. J'ai besoin de quelques conseils sur la meilleure approche à adopter.
- Utilisez le fichier Parameters.xml et SetParameters.xml pour échanger dynamiquement les paramètres et les chaînes de connexion. Voir http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html
- Utilisez les fichiers machine.config ou web.config au niveau du serveur pour stocker les paramètres d'application courants et les chaînes de connexion.
- Utilisez le package packageweb NuGet de https://github.com/sayedihashimi/package-web qui permet d'utiliser les transformations web.config avec msdeploy.
- Utilisez les attributs file ou configSource avec SetParameters pour pointer vers différents fichiers de configuration, mais ils doivent être relatifs par rapport à la racine Web.
- Utilisez des profils de publication. Voir Déploiement d'un package existant à l'aide de profils de publication
Merci
Nous utilisons l'option # 1 et cela fonctionne assez bien. Nous déployons sur environ 30 à 40 sites et applications en utilisant cette approche.
Je pense que l'option # 2 causera des maux de tête pour vous ou pour les développeurs. Vous devrez soit vous assurer que les sections avec les paramètres sont supprimées de la configuration lors du déploiement, soit les verrouiller sur le serveur afin que la configuration locale ne puisse pas les ajouter.
Pour l'option # 3, vous devrez faire plusieurs builds pour obtenir les fichiers de configuration transformés. Ce n'est pas non plus très faisable si vous avez un grand nombre de sites à déployer.
L'option # 4 pourrait fonctionner, mais vous pourriez rencontrer des limitations ici. C'est soit que la section entière est dans un fichier séparé, soit tout dans le fichier principal, donc il n'y a pas d'intermédiaire.
L'option n ° 5 semble intéressante, mais je ne l'ai pas utilisée, je ne peux donc pas en dire grand-chose.
Je peux développer un peu les options # 1/# 3 et les comparer. La réponse précédente n'était pas exacte en déclarant que vous devez générer plusieurs fois avec PackageWeb, vous n'avez besoin de générer qu'une seule fois.
Option 1: Parameters.xml et SetParameters.xml
Dans cette approche, vous allez créer un fichier parameters.xml dans votre projet Web qui déclarera des paramètres Web Deploy supplémentaires.
Lorsque vous créez le package Web Deploy, les paramètres déclarés dans parameters.xml sont créés dans le package. Lorsque ce package de déploiement Web est créé, le fichier web.config sera transformé en fonction de la configuration de construction (et désormais potentiellement une transformation spécifique au profil également ).
Vous pouvez utiliser ce package et un setparameters.xml pour publier le package en spécifiant les valeurs des paramètres Web Deploy. Vous pouvez créer différents fichiers setparameters.xml et les utiliser avec le même package pour publier vers plusieurs destinations. Pour publier à l'aide de cette technique, vous pouvez utiliser le fichier deploy.cmd généré par VS ou appeler msdeploy.exe avec l'ensemble de paramètres correct.
Option 3: PackageWeb
PackageWeb étend le processus de package de sorte que lorsque vous créez un package Web Deploy, les transformations web.config sont incluses dans le package ainsi qu'un assembly qui peut exécuter les transformations.
De plus, lorsque vous créez un package de déploiement Web, un fichier publish-interactive.ps1 est généré. Vous pouvez utiliser ce fichier pour publier votre package. Il vous demandera; la transformation web.config à appliquer, les valeurs des paramètres de déploiement Web et les informations de point de terminaison de déploiement Web elles-mêmes. Lorsque vous exécutez une publication, les valeurs que vous avez fournies sont enregistrées dans publish-configuration.ps1.readme. Vous pouvez supprimer le fichier .readme et publish-interactive.ps1 utilisera les valeurs de ce fichier pour automatiser la publication. Vous pouvez également spécifier le fichier à utiliser pour les paramètres .
Si vous avez créé un fichier parameters.xml lors de la création du package de déploiement Web par VS, les paramètres de déploiement Web seront inclus dans le package. PackageWeb les récupérera et vous en demandera également.
Quelles sont donc les différences entre ces approches?
Avec l'option # 1, le web.config qui entre dans le package est déjà transformé. Vous n'aurez pas la possibilité de transformer à nouveau le fichier. Avec les deux approches, vous pouvez toutefois spécifier des valeurs de paramètres de déploiement Web afin de répondre à vos besoins. Si vous modifiez de gros morceaux de XML d'un env à l'autre, les transformations web.config peuvent être bénéfiques. PackageWeb peut donc être un meilleur choix.
Avec l'option # 1, vous devez créer manuellement le fichier SetParameters.xml. Avec PackageWeb, vous pouvez exécuter le processus à l'aide de l'option WhatIf. Vous serez invité à entrer les valeurs et il créera le fichier de paramètres pour vous.
Vous pouvez facilement automatiser les deux approches. PackageWeb s'appuie essentiellement sur la technique parameters.xml/setparameters.xml et offre un super-ensemble de fonctionnalités.
Si vous voulez garder les choses aussi simples que possible avec le moins de pièces mobiles possible, je recommanderais l'option n ° 1, car vous pouvez appeler directement msdeploy.exe si nécessaire.
Si vous souhaitez simplifier l'automatisation de la publication et que vous préférez PowerShell à une invite de commande standard, essayez PackageWeb.
J'ai une vidéo de 5 minutes sur PackageWeb à http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx . Si vous publiez des packages de déploiement Web, je vous encourage à les essayer. S'il ne répond pas à vos besoins, faites-le moi savoir car nous pourrons utiliser plus tard de manière plus formelle ce que nous apprenons dans PackageWeb.
Nous utilisons # 5 et cela fonctionne très bien. L'utilisation de MSBuild pour publier des profils offre une grande flexibilité (les éléments sont particulièrement utiles).
Dans notre pipeline de déploiement, seuls le package de site Web, les cibles de génération/déploiement et les profils de publication sont mis à la disposition des étapes de déploiement. Le code source, y compris les fichiers de projet, n'est utilisé que par l'étape de génération/test.
Pour info, nous avons choisi de publier des profils spécifiquement car vous rencontrerez rapidement le problème de garder les détails/informations d'identification du serveur spécifiques à l'environnement, les clauses de saut et les valeurs des paramètres ensemble. Les profils WPP/Publish suivent toutes ces choses dans le fichier pubxml, et les fonctionnalités de MSBuild autorisent certains "assistants" de convention sur la configuration de Nice pour les tâches courantes mais "bruyantes".
J'ai fini par résoudre ce problème avec une combinaison de msbuild fonctionnant sur TeamCity pour créer des packages NuGet qui peuvent être consommés par OctopusDeploy .
Octopus permet à une application empaquetée dans un paquet nuget (construit une fois) d'être poussée à travers plusieurs environnements. La configuration peut être transformée par environnement ou même par machine en utilisant des transformations MS standard. Liens vers les documents Octopus pertinents ci-dessous.