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 le site Web ASP.NET) à la production?

Je suis particulièrement intéressé par le stream de travail qui se produit entre le moment où le serveur Continuous Integration Build supprime les fichiers binarys à un endroit donné et le moment où la première requête utilisateur rencontre ces fichiers binarys.

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

  2. Lorsqu’une application est déployée pour la première fois, comment configurez-vous 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’application entière ou uniquement la ressource modifiée? Qu’en est-il quand une page d’assemblage / ASPX change?

  4. Suivez-vous toutes les versions déployées pour une application donnée et, en cas de problème, avez-vous des procédures pour restaurer l’application dans un état de fonctionnement connu?

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 nous le configurons pour créer l’application Web ASP.NET
  2. Nous ajoutons un projet d’installation ( PAS de projet de configuration Web) à la solution et le configurons 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 génération 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 exécuté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 d’identités pour les pools d’applications.
  4. Nous ajoutons une tâche personnalisée dans TFS pour générer le projet d’installation (TFS ne prend pas en charge les projets d’installation. Nous avons donc dû utiliser devenv.exe pour générer 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 en utilisant Setup Factory. Si quelque chose doit changer, nous redéplions toute la solution. Cela semble exagéré pour un fichier css, mais il maintient absolument tous les environnements en synchronisation, et nous soaps exactement ce qui est en production (nous déployons de la même manière sur tous les environnements de test et de configuration).

Nous effectuons un déploiement continu sur les serveurs en direct, nous n’utilisons donc pas de projets d’installation; nous avons quelque chose de plus comme CI:

  • “live” build-server construit à partir de la source approuvée (pas le “HEAD” du repo)
  • (après avoir effectué une sauvegarde ;-p)
  • robocopy publie sur un serveur de transfert (“live”, mais pas dans le cluster F5)
  • validation finale effectuée sur le serveur de transfert, souvent avec des hacks “hôtes” pour émuler le plus fidèlement possible
  • robocopy / L est utilisé automatiquement pour dissortingbuer une liste des modifications dans le prochain “push”, pour alerter les éventuelles erreurs
  • Dans le cadre d’un processus planifié, le cluster est soumis à un cycle, déployé sur les nœuds du cluster via robocopy (lorsqu’ils sont hors du cluster)

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

Re le pool d’applications, etc. J’aimerais que cela soit automatisé ( voir cette question ), mais pour le moment c’est manuel. Je veux vraiment changer cela, cependant.

(cela aide probablement que nous ayons notre propre centre de données et notre propre batterie de serveurs “sur site”, de sorte que nous ne sums pas obligés de traverser de nombreux obstacles)

Site Internet

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

Je publie un site Web dans un dossier local, le compresse, puis le télécharge sur FTP. Deployer sur le serveur extrait ensuite 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, firebase database, mais après cela, la publication des mises à jour est un jeu d’enfant.

Base de données

Pour maintenir la synchronisation des bases de donné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 nécessaire pour 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 pour les plus petits changements. Voici mon workflow standard:

  • J’utilise un référentiel de code source (comme Subversion)
  • Sur le serveur, j’ai un script bash qui effectue les opérations suivantes:
    • Vérifie le dernier code
    • Fait une génération (crée les DLL)
    • Filtre les fichiers à l’essentiel (supprime les fichiers de code par exemple)
    • Sauvegarde la firebase database
    • Déploie les fichiers sur le serveur Web dans un répertoire nommé avec la date actuelle
    • Met à jour la firebase database si un nouveau schéma est inclus dans le déploiement
    • Rend la nouvelle installation par défaut pour qu’elle soit servie avec le prochain hit

Checkout est fait avec la version de ligne de commande de Subversion et la construction est faite avec xbuild (msbuild de travail similaire au projet Mono). La majeure partie de la magie est faite dans ReleaseIt.

Sur mon serveur de développement, je suis essentiellement en continuous integration mais en ce qui concerne la production, je me connecte au serveur SSH et lance le déploiement manuellement en exécutant le script. Mon script s’appelle intelligemment “deploy”, c’est ce que je tape à l’invite bash. Je suis très créatif. Ne pas.

En production, je dois taper «deploy» deux fois: une fois pour l’extraction, la génération et le déploiement dans un répertoire daté et une fois pour que ce répertoire soit l’instance par défaut. Étant donné que les répertoires sont datés, je peux revenir à tout déploiement précédent en tapant simplement «deploy» dans le répertoire approprié.

Le déploiement initial prend quelques minutes et le retour à une version antérieure 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:

http://releaseit.codeplex.com/

Simple XCopy pour ASP.NET. Zip-up, sftp au serveur, extraire 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 DLL et les pages ASPX modifiées.
  4. Oui et oui.

Le garder beau et simple nous a évité beaucoup de maux de tête jusqu’à présent.

Utilisez-vous des outils spécifiques ou XCOPY? Comment l’application est-elle empaquetée (ZIP, MSI, …)?

En tant que développeur pour BuildMaster , c’est naturellement ce que j’utilise. Toutes les applications sont créées et intégrées à 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 configurez-vous 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 au sein de l’outil qui nous rappelle les étapes exactes à effectuer dans les environnements futurs lorsque 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 simple de consacrer une minute à la création manuelle du site.

Lorsqu’une ressource statique change (CSS, JS ou fichier image), redéployez-vous l’application entière ou uniquement la ressource modifiée? Qu’en est-il quand une page d’assemblage / 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 les fichiers CSS, les fichiers JavaScript, les pages ASPX et les assemblys liés.

Suivez-vous toutes les versions déployées pour une application donnée et, en cas de problème, avez-vous des procédures pour restaurer l’application dans un état de fonctionnement connu?

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

projets d’installation / installation Web – vous pouvez donc facilement le désinstaller si quelque chose ne va pas

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 cet article 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 code source, créer, créer le pool d’applications, configurer IIS, etc.
  • versions basées sur ce qui est dans le contrôle de source
  • il a des tâches accrochées , donc le comportement par défaut peut être facilement étendu ou modifié
  • il a rollback
  • c’est tout 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 empaquetée (ZIP, MSI, …)?

    Git (ou un autre scm) est le moyen par défaut pour obtenir l’application sur la machine cible. Vous pouvez également effectuer une génération locale et copier le résultat sur la connexion distante Powereshell.

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

    Unfold configure l’application du pool d’applications et du site Web à l’aide du module WebAdministration 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’application entière ou uniquement la ressource modifiée? Qu’en est-il quand une page d’assemblage / ASPX change?

    Oui dépliez-le, 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 du contrôle de code source.

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

    Oui, déplier conserve les anciennes versions autour. Pas toutes les versions, mais plusieurs versions. Cela rend le retour presque sortingvial.

Nous avons amélioré notre processus de publication au cours de l’année écasting et nous l’avons maintenant fait. J’utilise Jenkins pour gérer toutes nos versions et versions automatisées, mais je suis sûr que vous pourriez utiliser TeamCity ou CruiseControl.

Donc, lors de l’enregistrement, notre build “normal” fait ce qui suit:

  • Jenkins effectue une mise à jour SVN pour récupérer la dernière version du code
  • Une restauration de paquetage NuGet est effectuée sur notre propre repository local NuGet
  • L’application est compilée à l’aide de MsBuild. Configurer cela est une aventure, car vous devez installer le correct MsBuild, puis les DLL ASP.NET et MVC sur votre boîte de construction. (En guise de remarque, lorsque true entré dans mes fichiers .csproj pour comstackr les vues, msbuild se plantait aléatoirement, donc je devais 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 (quelques commandes XCOPY de base pour copier les fichiers nécessaires), puis redémarre IIS (des problèmes sont survenus avec les fichiers de locking IIS. 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). Donc, le fichier web.config correct est également copié à travers
  • J’utilise ensuite PhantomJS pour exécuter une série 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 d’intégration ont réussi, la génération réussit

Si quelqu’un clique sur “Déployer vers UAT”:

  • Si la dernière version a réussi, Jenkins effectue une autre mise à jour SVN
  • L’application est compilée en utilisant 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 boite de construction et UAT
  • J’envoie une requête HTTP au serveur UAT et vérifie que je récupère 200
  • Cette révision est balisée dans SVN comme UAT-datetime
  • Si nous avons jusqu’ici, la construction est réussie!

Quand on clique sur “Déployer vers Prod”:

  • L’utilisateur sélectionne une balise UAT précédemment créée
  • Le tag est “commuté” sur
  • Le code est compilé et synchronisé avec le serveur Prod
  • Http demande au serveur Prod
  • Cette révision est balisée en SVN comme Prod-datetime
  • La version est compressée et stockée

Une production complète prend environ 30 secondes, ce dont je suis très très heureux.

Des améliorations à cette solution:

  • C’est rapide
  • Les tests unitaires doivent détecter les erreurs logiques
  • Quand un bug de l’interface utilisateur entre en production, les captures d’écran montreront, espérons-le, quel numéro de révision a causé le problème.
  • UAT et Prod sont synchronisés
  • Jenkins vous montre un excellent historique de publication pour UAT et Prod avec tous les messages de validation
  • Les versions UAT et Prod sont toutes étiquetées automatiquement
  • Vous pouvez voir quand les sorties arrivent et qui les a faites

Les principaux inconvénients de cette solution sont les suivants:

  • Chaque fois que vous faites une sortie vers Prod, vous devez faire une sortie vers UAT. C’était une décision consciente que nous avions prise parce que nous voulions toujours nous assurer que l’UAT est toujours à jour avec Prod. C’est quand même douloureux.
  • Il y a pas mal de fichiers de configuration qui circulent. J’ai essayé de tout avoir dans Jenkins, mais il y a quelques fichiers de commandes nécessaires dans le cadre du processus. (Ceux-ci sont également archivés).
  • Les scripts de mise à niveau et de mise à niveau vers la firebase database font partie de l’application et s’exécutent au démarrage de l’application. Cela fonctionne (principalement), mais c’est une douleur.

J’aimerais entendre d’autres améliorations possibles!

En 2009, d’où vient cette réponse, nous avons utilisé CruiseControl.net pour nos builds d’continuous integration, qui ont également généré Release Media.

À partir de là, nous avons utilisé le logiciel Smart Sync pour comparer un serveur de production qui ne faisait pas partie du pool équilibré de la charge, et déplacé les modifications.

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

Dans la dernière société pour laquelle je travaillais, nous utilisions 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 append des listes d’exclusion pour exclure des fichiers spécifiques ou des modèles de noms de fichiers. Ainsi, l’exclusion de tous nos fichiers .cs, de nos solutions et de nos projets est très simple, par exemple.

Nous utilisions TortoiseSVN pour le contrôle de version, et il était donc agréable de pouvoir écrire plusieurs commandes SVN pour accomplir les tâches suivantes:

  • Tout d’abord, vérifiez que l’utilisateur a la dernière révision. Sinon, invitez-les à mettre à jour ou à exécuter la mise à jour immédiatement.
  • Téléchargez un fichier texte du serveur appelé “synclog.txt” qui détaille qui est l’utilisateur SVN, quel numéro de révision il télécharge et la date et l’heure du téléchargement. Ajoutez une nouvelle ligne pour le téléchargement en cours, puis renvoyez-la au serveur avec les fichiers modifiés. Cela rend extrêmement facile la recherche de la version du site à restaurer en cas de problème.

En plus de cela, il existe un deuxième fichier batch qui vérifie uniquement les différences de fichiers sur le serveur en direct. Cela peut mettre en évidence le problème commun auquel quelqu’un pourrait télécharger mais ne pas commettre ses modifications sur SVN. Combiné au journal de synchronisation mentionné ci-dessus, nous avons pu déterminer qui était le coupable probable et leur demander de s’engager.

Et enfin, rSync vous permet de faire une sauvegarde des fichiers qui ont été remplacés lors du téléchargement. Nous l’avons déplacé dans un dossier de sauvegarde Si vous avez soudainement réalisé que certains fichiers ne devaient pas être remplacés, vous pouvez trouver la dernière version de sauvegarde de chaque fichier dans ce dossier.

Alors que la solution me semblait un peu maladroite à l’époque, je l’apprécie beaucoup plus quand je travaille dans des environnements où la méthode de téléchargement est beaucoup moins élégante (bureau distant, copier et coller le site entier, par exemple). .

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

  • Rapide pour revenir si nécessaire
  • Pas besoin d’arrêter IIS ou le pool d’applications pour éviter les problèmes de locking
  • Aucun risque de fichiers anciens causant des problèmes
  • Plus ou moins de temps d’arrêt (généralement juste une pause lors de l’initialisation du nouveau domaine d’application)

Le seul problème que nous avons rencontré concerne la mise en cache des ressources si vous ne redémarrez pas le pool d’applications et que vous utilisez le commutateur automatique d’appli.