Comment déployez-vous vos applications ASP.NET sur des serveurs actifs?

Je recherche différentes techniques / outils que vous utilisez pour déployer un projet d'application Web ASP.NET ( PAS un site Web ASP.NET) en production?

Je suis particulièrement intéressé par le flux de travail qui se produit entre le moment où votre serveur Continuous Integration Build supprime les binaires à un endroit et le moment où la première demande de l'utilisateur atteint ces binaires.

1. Utilisez-vous des outils spécifiques ou simplement XCOPY? Comment l'application est-elle packagée (ZIP, MSI, ...)?

2. Lorsqu'une application est déployée pour la première fois, comment configurer le pool d'applications et le répertoire virtuel (les créez-vous manuellement ou avec un outil)?

3. Lorsqu'une ressource statique change (CSS, JS ou fichier image), redéployez-vous l'ensemble de l'application ou uniquement la ressource modifiée? Que diriez-vous quand une page d'assembly / ASPX change?

4. Gardez-vous une trace de toutes les versions déployées pour une application donnée et en cas de problème, avez-vous des procédures de restauration de l'application à un état de fonctionnement connu antérieur?

N'hésitez pas à compléter la liste précédente.

Et voici ce que nous utilisons pour déployer nos applications ASP.NET:

1. Nous ajoutons un projet de déploiement Web à la solution et le configurons pour créer l'application Web ASP.NET
2. Nous ajoutons un projet de configuration ( PAS un projet de configuration Web) à la solution et le définissons pour prendre la sortie du projet de déploiement Web
3. Nous ajoutons une action d'installation personnalisée et dans l'événement OnInstall, nous exécutons un assembly .NET de build personnalisé qui crée un pool d'applications et un répertoire virtuel dans IIS à l'aide de System.DirectoryServices.DirectoryEntry (cette tâche est effectuée uniquement la première fois qu'une application est déployée) . Nous prenons en charge plusieurs sites Web dans IIS, l'authentification pour les répertoires virtuels et la définition des identités pour les pools d'applications.
4. Nous ajoutons une tâche personnalisée dans TFS pour créer le projet d'installation (TFS ne prend pas en charge les projets d'installation, nous avons donc dû utiliser devenv.exe pour créer le MSI)
5. Le MSI est installé sur le serveur live (s'il existe une version précédente du MSI, il est d'abord désinstallé)

Nous avons tout notre code déployé dans les MSI à l'aide de Setup Factory. Si quelque chose doit changer, nous redéployons toute la solution. Cela semble excessif pour un fichier css, mais cela maintient absolument tous les environnements synchronisés, et nous savons exactement ce qui est en production (nous déployons sur tous les environnements de test et uat de la même manière).

Nous effectuons un déploiement progressif sur les serveurs actifs, nous n'utilisons donc pas de projets d'installation; nous avons quelque chose de plus comme CI:

• Build-server "live" builds à partir de la source approuvée (pas la "HEAD" du dépôt)
• (après avoir effectué une sauvegarde ;-p)
• robocopy publie sur un serveur intermédiaire ("en direct", mais pas dans le cluster F5)
• validation finale effectuée sur le serveur de test, souvent avec des hacks «hôtes» pour émuler le tout le plus fidèlement possible
• robocopy / L est utilisé automatiquement pour distribuer une liste des changements dans le prochain "push", pour alerter de toute gaffe
• dans le cadre d'un processus planifié, le cluster est cyclé, se déployant vers les nœuds du cluster via robocopy (lorsqu'ils sont hors du cluster)

robocopy garantit automatiquement que seules les modifications sont déployées.

Concernant le pool d'applications, etc. J'adore ce soit automatisé ( voir cette question ), mais au moment où il est manuel. Je veux vraiment changer cela, cependant.

(il est probablement utile que nous ayons notre propre centre de données et notre propre ferme de serveurs "sur site", nous n'avons donc pas à franchir de nombreux obstacles)

Site Internet

Deployer: http://www.codeproject.com/KB/install/deployer.aspx

Je publie le site Web dans un dossier local, je le zip, puis je le télécharge via FTP. Deployer sur le serveur extrait ensuite le zip, remplace les valeurs de configuration (dans Web.Config et d'autres fichiers), et c'est tout.

Bien sûr, pour la première exécution, vous devez vous connecter au serveur et configurer IIS WebSite, base de données, mais après cela, publier des mises à jour est un jeu d'enfant.

Base de données

Pour garder les bases de données synchronisées, j'utilise http://www.red-gate.com/products/sql-development/sql-compare/

Si le serveur est derrière un tas de routeurs et que vous ne pouvez pas vous connecter directement (ce qui est une exigence de SQL Compare), utilisez https://secure.logmein.com/products/hamachi2/ pour créer un VPN.

Je déploie principalement des applications ASP.NET sur des serveurs Linux et redéploie tout, même pour le plus petit changement. Voici mon flux de travail standard:

• J'utilise un référentiel de code source (comme Subversion)
• Sur le serveur, j'ai un script bash qui fait ce qui suit:
  • Vérifie le dernier code
  • Fait une compilation (crée les DLL)
  • Filtre les fichiers jusqu'à l'essentiel (supprime les fichiers de code par exemple)
  • Sauvegarde la base de données
  • Déploie les fichiers sur le serveur Web dans un répertoire nommé avec la date actuelle
  • Met à jour la base de données si un nouveau schéma est inclus dans le déploiement
  • Fait de la nouvelle installation celle par défaut afin qu'elle soit servie avec le prochain hit

L'extraction se fait avec la version en ligne de commande de Subversion et la construction se fait avec xbuild (msbuild fonctionne de la même manière à partir du projet Mono). La plupart de la magie se fait dans ReleaseIt.

Sur mon serveur de développement, j'ai essentiellement une intégration continue, mais du côté de la production, je SSH dans le serveur et lance le déploiement manuellement en exécutant le script. Mon script est intelligemment appelé 'deploy', c'est donc ce que je tape à l'invite bash. Je suis très créatif. Ne pas.

En production, je dois taper «déployer» deux fois: une fois pour extraire, construire et déployer dans un répertoire daté et une fois pour faire de ce répertoire l'instance par défaut. Étant donné que les répertoires sont datés, je peux revenir à n'importe quel déploiement précédent simplement en tapant «deploy» à partir du répertoire concerné.

Le déploiement initial prend quelques minutes et le retour à une version précédente prend quelques secondes.

Cela a été une bonne solution pour moi et ne repose que sur les trois utilitaires de ligne de commande (svn, xbuild et releaseit), le client DB, SSH et Bash.

J'ai vraiment besoin de mettre à jour la copie de ReleaseIt sur CodePlex un jour:

http://releaseit.codeplex.com/

XCopy simple pour ASP.NET. Zip-le, sftp sur le serveur, extrayez-le au bon endroit. Pour le premier déploiement, configuration manuelle d'IIS

Répondre à vos questions:

1. XCopy
2. Manuellement
3. Pour les ressources statiques, nous déployons uniquement la ressource modifiée.
   Pour les DLL, nous déployons les pages DLL et ASPX modifiées.
4. Oui et oui.

Rester simple et agréable nous a évité jusqu'à présent beaucoup de maux de tête.

Utilisez-vous des outils spécifiques ou simplement XCOPY? Comment l'application est-elle packagée (ZIP, MSI, ...)?

En tant que développeur pour BuildMaster , c'est naturellement ce que j'utilise. Toutes les applications sont créées et conditionnées dans l'outil sous forme d'artefacts, qui sont stockés en interne sous forme de fichiers ZIP.

Lorsqu'une application est déployée pour la première fois, comment configurer le pool d'applications et le répertoire virtuel (les créez-vous manuellement ou avec un outil)?

Manuellement - nous créons un contrôle des modifications dans l'outil qui nous rappelle les étapes exactes à effectuer dans les futurs environnements à mesure que l'application se déplace dans ses environnements de test. Cela pourrait également être automatisé avec un simple script PowerShell, mais nous n'ajoutons pas de nouvelles applications très souvent, il est donc tout aussi facile de passer la minute nécessaire pour créer le site manuellement.

Lorsqu'une ressource statique change (CSS, JS ou fichier image), redéployez-vous l'ensemble de l'application ou uniquement la ressource modifiée? Que diriez-vous quand une page d'assembly / ASPX change?

Par défaut, le processus de déploiement des artefacts est configuré de telle sorte que seuls les fichiers modifiés sont transférés vers le serveur cible - cela inclut tout, des fichiers CSS, des fichiers JavaScript, des pages ASPX et des assemblys liés.

Gardez-vous une trace de toutes les versions déployées pour une application donnée et en cas de problème, avez-vous des procédures de restauration de l'application à un état de fonctionnement connu antérieur?

Oui, BuildMaster gère tout cela pour nous. La restauration est généralement aussi simple que la réexécution d'une ancienne promotion de build, mais parfois les modifications de la base de données doivent être restaurées manuellement et des pertes de données peuvent survenir. Le processus de restauration de base est détaillé ici: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

projets de configuration / d'installation Web - vous pouvez donc facilement le désinstaller en cas de problème

Unfold est une solution de déploiement de type capistrano que j'ai écrite pour les applications .net. C'est ce que nous utilisons sur tous nos projets et c'est une solution très flexible. Il résout la plupart des problèmes typiques des applications .net, comme expliqué dans ce billet de blog de Rob Conery.

• il est livré avec un bon comportement "par défaut", en ce sens qu'il fait beaucoup de choses standard pour vous: obtenir le code du contrôle de source, construire, créer le pool d'applications, configurer IIS, etc.
• versions basées sur ce qui est dans le contrôle de code source
• il a des crochets de tâches , de sorte que le comportement par défaut peut être facilement étendu ou modifié
• il a un retour en arrière
• tout est PowerShell , donc il n'y a pas de dépendances externes
• il utilise la communication à distance PowerShell pour accéder aux machines distantes

Voici une introduction et quelques autres articles de blog.

Donc, pour répondre aux questions ci-dessus:

• Comment l'application est-elle packagée (ZIP, MSI, ...)?

  Git (ou un autre scm) est le moyen par défaut d'obtenir l'application sur la machine cible. Vous pouvez également effectuer une construction locale et copier le résultat via la connexion à distance Powereshell

• Lorsqu'une application est déployée pour la première fois, comment configurer le pool d'applications et le répertoire virtuel (les créez-vous manuellement ou avec un outil)?

  Unfold configure le pool d'applications et l'application du site Web à l'aide du module d'administration Web de Powershell. Il nous permet (et vous) de modifier n'importe quel aspect du pool d'applications ou du site Web

• Lorsqu'une ressource statique change (CSS, JS ou fichier image), redéployez-vous l'ensemble de l'application ou uniquement la ressource modifiée? Que diriez-vous quand une page d'assembly / ASPX change?

  Oui, un dépliage fait cela, tout déploiement est installé à côté des autres. De cette façon, nous pouvons facilement revenir en arrière lorsque quelque chose ne va pas. Cela nous permet également de retracer facilement une version déployée vers une révision de contrôle de code source.

• Gardez-vous une trace de toutes les versions déployées pour une application donnée?

  Oui, déplier conserve les anciennes versions. Pas toutes les versions, mais un certain nombre de versions. Cela rend le retour en arrière presque trivial.

Nous améliorons notre processus de publication depuis un an et maintenant nous l'avons fait. J'utilise Jenkins pour gérer toutes nos versions et versions automatisées, mais je suis sûr que vous pouvez utiliser TeamCity ou CruiseControl.

Ainsi, lors de l'enregistrement, notre version "normale" effectue les opérations suivantes:

• Jenkins fait une mise à jour SVN pour récupérer la dernière version du code
• Une restauration de package NuGet est exécutée sur notre propre référentiel NuGet local
• L'application est compilée à l'aide de MsBuild. La configuration est une aventure, car vous devez installer le MsBuild correct, puis les DLL ASP.NET et MVC sur votre boîte de construction. (En remarque, lorsque j'ai <MvcBuildViews>true</MvcBuildViews>entré dans mes fichiers .csproj pour compiler les vues, msbuild plantait au hasard, j'ai donc dû le désactiver)
• Une fois le code compilé, les tests unitaires sont exécutés (j'utilise nunit pour cela, mais vous pouvez utiliser tout ce que vous voulez)
• Si tous les tests unitaires réussissent, j'arrête le pool d'applications IIS, déploie l'application localement (juste quelques commandes XCOPY de base pour copier les fichiers nécessaires), puis redémarre IIS (j'ai eu des problèmes avec les fichiers de verrouillage IIS, et cela est résolu il)
• J'ai des fichiers web.config séparés pour chaque environnement; dev, uat, prod. (J'ai essayé d'utiliser les trucs de transformation Web avec peu de succès). Ainsi, le bon fichier web.config est également copié sur
• J'utilise ensuite PhantomJS pour exécuter un tas de tests d'interface utilisateur. Il prend également un tas de captures d'écran à différentes résolutions (mobile, bureau) et tamponne chaque capture d'écran avec des informations (titre de la page, résolution). Jenkins a un excellent support pour gérer ces captures d'écran et elles sont enregistrées dans le cadre de la construction
• Une fois que les tests de l'interface utilisateur d'intégration ont réussi, la construction est réussie

Si quelqu'un clique sur "Déployer vers UAT":

• Si la dernière compilation a réussi, Jenkins fait une autre mise à jour SVN
• L'application est compilée à l'aide d'une configuration RELEASE
• Un répertoire "www" est créé et l'application y est copiée
• J'utilise ensuite winscp pour synchroniser le système de fichiers entre la boîte de construction et UAT
• J'envoie une requête HTTP au serveur UAT et je m'assure de récupérer un 200
• Cette révision est étiquetée dans SVN comme UAT-datetime
• Si nous sommes arrivés jusqu'ici, la construction est réussie!

Lorsque nous cliquons sur "Deploy to Prod":

• L'utilisateur sélectionne une balise UAT qui a été précédemment créée
• La balise est "commutée" sur
• Le code est compilé et synchronisé avec le serveur Prod
• Requête HTTP au serveur Prod
• Cette révision est étiquetée dans SVN comme Prod-datetime
• La version est zippée et stockée

Le montage complet jusqu'à la production prend environ 30 secondes, ce dont je suis très, très satisfait.

Avantages de cette solution:

• C'est rapide
• Les tests unitaires devraient détecter les erreurs de logique
• Lorsqu'un bug de l'interface utilisateur entre en production, les captures d'écran montreront, espérons-le, quelle révision # l'a causé
• UAT et Prod sont synchronisés
• Jenkins vous montre un excellent historique des versions pour UAT et Prod avec tous les messages de validation
• Les versions UAT et Prod sont toutes balisées automatiquement
• Vous pouvez voir quand les sorties ont lieu et qui les a faites

Les principaux inconvénients de cette solution sont:

• Chaque fois que vous faites une version pour Prod, vous devez faire une version pour UAT. C'était une décision consciente que nous avons prise parce que nous voulions toujours nous assurer que UAT est toujours à jour avec Prod. Pourtant, c'est une douleur.
• Il y a pas mal de fichiers de configuration qui flottent. J'ai essayé de tout avoir dans Jenkins, mais il y a quelques fichiers batch de support nécessaires dans le cadre du processus. (Ceux-ci sont également enregistrés).
• Les scripts de mise à niveau et de rétrogradation de la base de données font partie de l'application et s'exécutent au démarrage de l'application. Cela fonctionne (surtout), mais c'est pénible.

J'aimerais entendre toutes les autres améliorations possibles!

En 2009, d'où vient cette réponse, nous avons utilisé CruiseControl.net pour nos builds d'intégration continue, qui ont également produit Release Media.

À partir de là, nous avons utilisé le logiciel Smart Sync pour comparer avec un serveur de production qui n'était pas dans le pool à charge équilibrée, et avons déplacé les modifications vers le haut.

Enfin, après avoir validé la version, nous avons exécuté un script DOS qui utilisait principalement RoboCopy pour synchroniser le code avec les serveurs en direct, arrêtant / démarrant IIS au fur et à mesure.

Dans la dernière entreprise pour laquelle j'ai travaillé, nous avions l'habitude de déployer à l'aide d'un fichier de commandes rSync pour télécharger uniquement les modifications depuis le dernier téléchargement. La beauté de rSync est que vous pouvez ajouter des listes d'exclusion pour exclure des fichiers ou des modèles de nom de fichier spécifiques. Ainsi, exclure tous nos fichiers .cs, nos fichiers de solution et de projet est vraiment facile, par exemple.

Nous utilisions TortoiseSVN pour le contrôle de version, et c'était donc agréable de pouvoir écrire plusieurs commandes SVN pour accomplir ce qui suit:

• Tout d'abord, vérifiez que l'utilisateur dispose de la dernière révision. Sinon, invitez-les à mettre à jour ou exécutez la mise à jour immédiatement.
• Téléchargez un fichier texte depuis le serveur appelé "synclog.txt" qui détaille qui est l'utilisateur SVN, quel numéro de révision il est en train de télécharger et la date et l'heure du téléchargement. Ajoutez une nouvelle ligne pour le téléchargement actuel, puis renvoyez-la au serveur avec les fichiers modifiés. Cela rend extrêmement facile de savoir sur quelle version du site revenir en arrière au cas où un téléchargement poserait des problèmes.

En plus de cela, il existe un deuxième fichier de commandes qui vérifie simplement les différences de fichiers sur le serveur en direct. Cela peut mettre en évidence le problème courant où quelqu'un téléchargerait mais ne validerait pas ses modifications dans SVN. Combiné avec le journal de synchronisation mentionné ci-dessus, nous pourrions découvrir qui était le coupable probable et leur demander de commettre leur travail.

Et enfin, rSync vous permet de faire une sauvegarde des fichiers qui ont été remplacés lors du téléchargement. Nous l'avons fait déplacer dans un dossier de sauvegarde. Donc, si vous vous êtes soudainement rendu compte que certains fichiers n'auraient pas dû être écrasés, vous pouvez trouver la dernière version de sauvegarde de chaque fichier dans ce dossier.

Bien que la solution me paraisse un peu maladroite à l'époque, j'en suis venu à l'apprécier beaucoup plus lorsque je travaille dans des environnements où la méthode de téléchargement est beaucoup moins élégante ou facile (bureau à distance, copier et coller l'ensemble du site, par exemple) .

Je recommanderais de ne PAS simplement écraser les fichiers d'application existants, mais plutôt de créer un répertoire par version et de rediriger l'application IIS sur le nouveau chemin. Cela présente plusieurs avantages:

• Rapide à revenir si nécessaire
• Pas besoin d'arrêter IIS ou le pool d'applications pour éviter les problèmes de verrouillage
• Aucun risque que d'anciens fichiers causent des problèmes
• Temps d'arrêt plus ou moins nul (généralement juste une pause à l'initialisation du nouveau domaine d'application)

Le seul problème que nous ayons eu est la mise en cache des ressources si vous ne redémarrez pas le pool d'applications et que vous comptez sur le changement automatique de domaine d'application.