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 [~ # ~] ASP Site Web .NET) à la 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 fichiers binaires à un certain emplacement et le moment où la première demande utilisateur atteint ces fichiers binaires.
Utilisez-vous des outils spécifiques ou simplement XCOPY? Comment est packagée l'application (Zip, MSI, ...)?
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)?
Lorsqu'une ressource statique change (CSS, JS ou fichier image) redéployez-vous toute l'application ou seulement la ressource modifiée? Et quand une page Assembly/ASPX change?
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 pour restaurer l'application dans 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:
- Nous ajoutons un Web Deployment Project à la solution et le configurons pour construire l'application Web ASP.NET
- Nous ajoutons un projet d'installation ( [~ # ~] et non [~ # ~] Web Setup Project) à la solution et le configurons pour prendre la sortie de le projet de déploiement Web
- Nous ajoutons une action d'installation personnalisée et dans l'événement OnInstall, nous exécutons un assemblage .NET de génération personnalisé qui crée un pool d'applications et un répertoire virtuel dans IIS using System.DirectoryServices.DirectoryEntry (Cette tâche n'est effectuée que 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.
- 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)
- Le MSI est installé sur le serveur en direct (s'il existe une version précédente du MSI, elle est d'abord désinstallée)
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 exagéré pour un fichier css, mais il garde absolument tous les environnements synchronisés, et nous savons exactement ce qui est en production (nous déployons de la même manière sur tous les environnements de test et uat).
Nous déployons le déploiement sur les serveurs en direct, donc nous n'utilisons pas de projets d'installation; nous avons quelque chose de plus comme CI:
- "live" build-server builds from the approuvé source (pas le "HEAD" du repo)
- (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 transfert, 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é, déployant vers les nœuds du cluster via robocopy (alors qu'ils sont hors du cluster)
robocopy garantit automatiquement que seules les modifications sont déployées.
Re le pool d'applications, etc. J'aimerais aimer que cela soit automatisé ( voir cette question ), mais au moment = c'est manuel. Je veux vraiment changer cela, cependant.
(il est probablement utile que nous ayons notre propre centre de données et ferme de serveurs "sur site", donc nous n'avons pas à franchir de nombreux obstacles)
Site Internet
Deployer: http://www.codeproject.com/KB/install/deployer.aspx
Je publie un site Web dans un dossier local, le zippe, puis le télécharge via FTP. Deployer sur le serveur extrait ensuite Zip, remplace les valeurs de configuration (dans Web.Config et 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, la publication 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 obligatoire 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, même pour le moindre changement. Voici mon workflow 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:
- Extrait le dernier code
- Fait une construction (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
- Rend la nouvelle installation par défaut afin qu'elle soit servie avec le prochain hit
La vérification est effectuée avec la version en ligne de commande de Subversion et la construction se fait avec xbuild (msbuild fonctionne de la même manière que le 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 me connecte réellement au serveur et lance le déploiement manuellement en exécutant le script. Mon script est intelligemment appelé "déployer", c'est donc 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 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 correspondant.
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 moment donné:
XCopy simple pour ASP.NET. Zip-le, sftp sur le serveur, extrayez au bon endroit. Pour le premier déploiement, configuration manuelle d'IIS
Répondre à vos questions:
- XCopy
- Manuellement
- Pour les ressources statiques, nous déployons uniquement la ressource modifiée.
Pour les DLL, nous déployons les pages modifiées DLL et ASPX. - Oui et oui.
Le garder agréable et simple nous a évité beaucoup de maux de tête jusqu'à présent.
Utilisez-vous des outils spécifiques ou simplement XCOPY? Comment est packagée l'application (Zip, MSI, ...)?
En tant que développeur pour BuildMaster , c'est naturellement ce que j'utilise. Toutes les applications sont construites et regroupé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 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 à 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 aussi facile de passer la minute qu'il faut pour créer le site manuellement.
Lorsqu'une ressource statique change (CSS, JS ou fichier image) redéployez-vous toute l'application ou seulement la ressource modifiée? Et quand une page 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 pour restaurer l'application dans 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 génération, mais parfois les modifications de la base de données doivent ê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
Déplier 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 par Rob Conery.
- il est livré avec un bon comportement "par défaut", dans le sens où 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 le contenu du contrôle de code source
- il a hooks de tâches , 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 transmission à distance pour accéder aux machines distantes
Voici un introduction et quelques autres articles de blog.
Donc pour répondre aux questions ci-dessus:
Comment est packagée l'application (Zip, MSI, ...)?
Git (ou une autre scm) est le moyen par défaut d'obtenir l'application sur la machine cible. Vous pouvez également effectuer une génération locale et copier le résultat via 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)?
Déplier configure le pool d'applications et l'application de 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 toute l'application ou seulement la ressource modifiée? Et quand une page Assembly/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 en cas de problème. Il nous permet également de retracer facilement une version déployée jusqu'à une révision du 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 insignifiant.
Nous avons amélioré notre processus de sortie au cours de la dernière année et nous l'avons maintenant terminé. 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 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 build. (En remarque, quand j'avais
<MvcBuildViews>true</MvcBuildViews>entré dans mes fichiers .csproj pour compiler les vues, msbuild se bloquait aléatoirement, 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 sur les fichiers nécessaires), puis redémarre IIS (J'ai eu des problèmes avec IIS verrouillage des fichiers, et cela l'a résolu)
- 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). Le bon fichier web.config est donc également copié
- 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 les tests de l'interface utilisateur réussis, la construction réussit
Si quelqu'un clique sur "Déployer vers UAT":
- Si la dernière build 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 en sommes là, la construction est réussie!
Lorsque nous cliquons sur "Déployer vers Prod":
- L'utilisateur sélectionne une balise UAT créée précédemment
- La balise est "commutée" sur
- Le code est compilé et synchronisé avec le serveur Prod
- Demande HTTP au serveur Prod
- Cette révision est étiquetée dans SVN comme Prod-datetime
- La version est zippée et stockée
Tout un build complet à la production prend environ 30 secondes dont je suis très, très heureux.
Avantages de cette solution:
- C'est rapide
- Les tests unitaires devraient détecter les erreurs logiques
- Lorsqu'un bug d'interface utilisateur entre en production, les captures d'écran montreront, espérons-le, quelle révision # a causé le problème.
- UAT et Prod sont synchronisés
- Jenkins vous montre un excellent historique de 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 sur Prod, vous devez faire une version sur UAT. Ce fut une décision consciente que nous avons prise parce que nous voulions toujours nous assurer que l'UAT est toujours à jour avec Prod. C'est quand même 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 de commandes 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 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'adorerais entendre d'autres améliorations possibles!
projets de configuration/installation Web - vous pouvez donc facilement le désinstaller en cas de problème
En 2009, d'où vient cette réponse, nous avons utilisé CruiseControl.net pour nos versions d'intégration continue, qui ont également produit Release Media.
À partir de là, nous avons utilisé logiciel Smart Sync pour comparer avec un serveur de production qui était hors du pool à charge équilibrée, et avons 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 avec les serveurs en direct, arrêtant/démarrant IIS au fur et à mesure.
Je recommande de ne PAS simplement remplacer les fichiers d'application existants, mais de créer un répertoire par version et de rediriger l'application IIS vers le nouveau chemin d'accès. 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 d'anciens fichiers causant des problèmes
- Temps d'arrêt plus ou moins nul (généralement juste une pause lors de l'initialisation du nouveau domaine d'application)
Le seul problème que nous ayons rencontré est la mise en cache des ressources si vous ne redémarrez pas le pool d'applications et que vous ne comptez pas sur le commutateur de domaine d'application automatique.
Dans la dernière entreprise pour laquelle je travaillais, nous avions l'habitude de déployer à l'aide d'un fichier batch 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 spécifiques ou des modèles de nom de fichier. Il est donc très facile d'exclure tous nos fichiers .cs, nos fichiers de solution et de projet, par exemple.
Nous utilisions TortoiseSVN pour le contrôle de version, et c'était donc bien 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 à partir 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. Il est ainsi extrêmement facile de savoir dans quelle version du site revenir en arrière au cas où un téléchargement causerait 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écharge mais ne valide pas ses modifications sur 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.
Enfin, rSync vous permet d'effectuer 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 réalisez soudainement 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.
Alors que la solution semblait un peu maladroite à l'époque, je l'ai depuis appréciée 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) .