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 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:
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:
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:
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.
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:
<MvcBuildViews>true</MvcBuildViews>
entré dans mes fichiers .csproj pour compiler les vues, msbuild se bloquait aléatoirement, j'ai donc dû le désactiver)Si quelqu'un clique sur "Déployer vers UAT":
Lorsque nous cliquons sur "Déployer vers Prod":
Tout un build complet à la production prend environ 30 secondes dont je suis très, très heureux.
Avantages de cette solution:
Les principaux inconvénients de cette solution sont:
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:
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:
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) .