Comment faites-vous les dépôts de sites Web de production IIS?

Donc, je ne sais pas s'il s'agit d'un débordement de pile ou d'une question de défaillance du serveur. Si j'ai un site Web .NET que je souhaite déployer dans l'environnement de production, quelle est la meilleure façon de le faire. Dois-je l'empaqueter en tant que MSI et installer? Utilisez nant pour pousser les fichiers nécessaires vers le haut. Envoyez simplement les fichiers par FTP en utilisant Beyond Compare?

Comment déployez-vous le code de production? Il s'agit d'un cas spécifique à Windows que je regarde ici.

IIS prend en charge le déploiement xcopy, il vous suffit donc de copier les fichiers, sauf si vous avez des exigences particulières.

Une façon de le faire est un script simple qui utilise ROBOCOPY pour copier les nouveaux fichiers sur le serveur.

Si le site est grand et que cela prend trop de temps, utilisez un système de contrôle de version. J'aime Mercurial à cet effet, bien que vous deviez faire attention à ce que les fichiers de configuration du système de contrôle de version ne finissent pas par être rendus publics. Le déploiement consiste alors simplement à valider les modifications, puis à vérifier la dernière version sur le serveur. En plus d'être efficace, cela permet des retours en arrière rapides (si vous avez tagué la dernière bonne version) au cas où votre dernier et plus grand a un bug showstopper.

Pour minimiser les temps d'arrêt, vous pouvez demander au script de copier les fichiers dans un nouveau répertoire, puis de renommer rapidement les répertoires, ou de modifier où IIS pointe vers le nouveau répertoire.

Pensez à utiliser l' outil de déploiement Web de Microsoft. Il a été spécifiquement conçu pour aider à déployer des applications Web et des mises à jour de ces applications Web sur les serveurs Web de production IIS 6 et 7 et il fait un meilleur travail que MSI (Windows Installer), à mon humble avis.

Normalement, vous l'utilisez en créant un site "maître d'or" quelque part, puis en indiquant à l'outil de regrouper les modifications à partir de là. Il examinera ensuite un serveur cible pour le déploiement et apportera les modifications nécessaires pour le faire ressembler au maître d'or (ce qui est utile pour les mises à jour ultérieures). Il est particulièrement utile si vous déployez sur plusieurs serveurs Web (c'est-à-dire une batterie de serveurs), et il prend en charge le déploiement de plus que de simples fichiers (il peut également gérer les modifications de registre, déployer des certificats, des bases de données SQL, etc.).

J'approfondirais la réponse de Joel en suggérant qu'un serveur d'intégration continue récupère vos modifications depuis votre système de contrôle de source. Il va ensuite construire le projet. Demandez-lui ensuite de copier la sortie de la build dans un nouveau dossier. Vous pouvez ensuite effectuer quelques changements de configuration rapides (web.config et app.config). Voila, prêt pour Xcopy!

Découvrez CruiseControl.NET

Ce que j'ai fait chez mon ancien employeur, qui était essentiellement un site de vente aux enchères / e-commerce où nous ne pouvions pas autoriser beaucoup de temps d'arrêt:

• Prenez une version de construction zippée de la version / version à déployer sur le serveur de génération
• Testez-le sur un serveur intermédiaire disposant d'une copie de la base de données de production et de la même version de logiciel que le logiciel de production. Testez que tout s'est bien passé. Sinon, redémarrez le déploiement du serveur de transfert (mais restaurez d'abord une sauvegarde).
• Si tout s'est bien passé: copiez les scripts de build et de mise à niveau de la base de données vers le serveur de production dans un dossier local. Faites une sauvegarde spécifique de la base de données et des fichiers ASP.NET (au cas où quelque chose ne fonctionne toujours pas). Préparez ensuite tout pour que je n'aie qu'à cliquer sur Entrée pour lancer le script de mise à niveau et la copie des fichiers de base de données (notez que je pourrais créer un script pour cela). Puis lancez tout. Ceci est normalement une question de secondes et les utilisateurs ne remarqueront pas beaucoup qu'il y a eu des temps d'arrêt.

Il y a beaucoup de choses plus amusantes à faire en tant que développeur Web. Mais c'était la partie la plus cruciale de mon travail.

oh jeeez, au travail, nous avons toute une équipe pour cela. Ils disposent d'un outil interne qui retire un serveur du cluster / batterie, publie les fichiers, exécute les NUnits et l'ajoute à nouveau au cluster / batterie. Ils le font pour chacun des 16 serveurs. Cela prend des heures. Le reste d'entre nous n'a même pas de "regarder autour de l'accès".

Pour mes projets personnels, je publie depuis VS2005 directement sur mon serveur web. Kinda a une sécurité moins stricte.