Comment déployez-vous votre application Web .NET? (Recommandations, s'il vous plaît!)

Nous avons récemment mis à niveau notre site Web ASP.NET vers une application Web et nous sommes choqués par le saut soudain de difficulté lors de son déploiement. Compte tenu de la fréquence de cette tâche, je me demandais quels plug-ins / logiciels les gens utilisent pour déployer un projet évoluant rapidement et stocké à distance (c'est-à-dire un site Web)?

Il doit y avoir un meilleur moyen que de simplement "publier" dans Visual Studio et de devoir ensuite FTP manuellement les fichiers qui ont changé? Notamment parce que le site tombe en panne lorsque nous téléchargeons nos fichiers .DLL.

Il y a tellement d'exceptions de fichiers délicates que je devrais plutôt automatiser le processus autant que possible, pour éviter les téléchargements accidentels.

Avec notre ancienne solution (sur notre site Web), nous avons utilisé Dispatch for ASP qui a totalement basculé et a fait tout le processus en un seul clic. Malheureusement, ce n'est pas idéal pour les DLL (comme mentionné précédemment).

Alors, comment fait votre équipe?

Merci pour tout conseil.

PS - J'ai lu que Visual Studio 2010 est censé combler ces lacunes dans VS2005 / 08, mais jusque-là ...

Je recommande fortement d'utiliser l'intégration continue.

Nous utilisons une combinaison de TeamCity pour CI, Rake et Albacore pour automatiser la construction.

TeamCity vérifiera le code de votre référentiel de code source, puis, en utilisant Rake, construira l'application, exécutera des tests unitaires et même exécutera vos scripts de base de données si vous le souhaitez. Après une construction réussie, vous pouvez empaqueter votre code source dans un fichier zip ou le copier vers la destination de votre choix.

Nous utilisons Git, bien que TeamCity fonctionne avec tous les systèmes de contrôle de source.

L'utilisation de TeamCity et de Rake serait similaire à l'utilisation de CruiseControl et NANT, sans modification du fichier XML. Bien sûr, vous pouvez utiliser TeamCity avec NANT si vous préférez.

Un court échantillon extrait d'un rakefile.rb qui effectue la construction. À mon humble avis, plus facile à lire et à déboguer qu'un fichier XML.

require 'albacore'
require 'rexml/document'
require 'find'

VERSION_NO = "1.0"

OUTPUT_PATH = "output"
WEBOUTPUT_PATH = "output/web"
ADMINOUTPUT_PATH = "output/admin"

CONFIG = "Release"

WEB_PATH = "app/Company.Website.Web"
ADMIN_PATH = "app/Company.Website.Admin"
PACKAGE_PATH = "build/package"
DB_SCRIPT_PATH = "Company.Website.DB"
SOLUTION = "Company.Website.sln"

ARTIFACTS_PATH = "d:/build/artifacts/"

DEPLOY_WEB_PATH = "d:/deploy/company/website/"
DEPLOY_ADMIN_PATH = "d:/deploy/company/admin/"

task :default => ['setuptest','assemblyinfo','config','msbuild','createdb','sqlcmd','deploy']


task :setuptest do |setup|
  if ENV['BuildNumber'].nil? then ENV['BuildNumber'] = "000" end

  VERSION_NO = VERSION_NO + '.' + ENV['BuildNumber']
  puts 'Version Number : ' + VERSION_NO

  ZIPFILE_WEB = 'Company.Website.Web.' + VERSION_NO
  ZIPFILE_ADMIN = 'Company.Website.Admin.' + VERSION_NO  

  DB_SERVER = "WEB2"
  DB_DATABASE = "Website"  
  CREATEDB_SCRIPT = "app/Company.Website.DB/00CreateDatabaseTEST.sql"
end

  assemblyinfotask do |asm|
    asm.version = VERSION_NO
    asm.company_name = "Company Name"
    asm.copyright = "Copyright 2010"
    asm.output_file = "CommonAssemblyInfo.cs"
  end

  task :config do
    FileUtils.cp 'NHibernate.test.config', 'NHibernate.config'
  end

  msbuildtask do |msb|
    msb.properties = { :configuration => :Debug }
    msb.targets [:Clean, :Build]
    msb.solution = "Company.Website.sln"
  end

  sqlcmdtask :createdb do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = "master"
    sql.scripts << CREATEDB_SCRIPT
  end

  sqlcmdtask do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = DB_DATABASE
    sql.scripts << "app/Company.Website.DB/01CreateTables.sql"
    sql.scripts << "app/Company.Website.DB/02InsertReferenceData.sql"
  end

  task :deployprep do

    FileUtils.remove_dir 'app/Company.Website.Web/obj'
    FileUtils.remove_dir 'app/Company.Website.Admin/obj'

  end

  ziptask :zipweb do |zip|
    puts "creating zip package in " + ZIPFILE_WEB
    zip.directories_to_zip = ["app/Company.Website.Web"]
    zip.output_file = ZIPFILE_WEB  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end

  ziptask :zipadmin do |zip|
      puts "creating zip package in " + ZIPFILE_ADMIN
    zip.directories_to_zip = ["app/Company.Website.Admin"]
    zip.output_file = ZIPFILE_ADMIN  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end  

Albacore est une suite de tâches Rake spécialement conçues pour déployer une application .NET.

Sous Linux, j'ai utilisé fabric (fabfile.org) et capistrano (capify.org) qui sont des outils d'automatisation pour aider aux commandes SSH et SCP à distance. Si Cygwin est installé sur vos hôtes Windows, vous devriez pouvoir les réutiliser comme outils de déploiement.

La «publication» d'une application Web dans Visual Studio peut être exécutée à partir de la ligne de commande en tant que msbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir". Le répertoire de destination est une application Web déployable.

Les autres réponses couvrant votre question plus large sont bonnes. J'ajouterais également que vous devriez examiner plusieurs projets d'applications Web open source et copier le processus de construction que vous aimez le plus.

Je suis d'accord avec Scott que cela peut être très compliqué et facilement ignoré. La stratégie de déploiement est également très spécifique à l'application. Si votre application est complètement autonome dans un dossier, cela pourrait être plus facile qu'une application qui fait référence au GAC. Ce qui à son tour pourrait être encore plus facile qu'un serveur qui a besoin de maintenir plusieurs versions d'une application qui fait référence à plusieurs versions des assemblys GAC. Nous ne voulons pas commencer à parler des fichiers de stratégie ici :).

Cela dit, la combinaison de l' outil de déploiement Web Microsoft avec le routage des demandes d' application est une bonne option. Dans IIS7, il est possible de créer des packages d'installation à l'aide de l'outil. Il est également possible de pointer l'outil vers une application Web et de sauvegarder l'intégralité de l'application dans un dossier d'archive d'application. Vous pouvez ensuite déployer ce dossier d'archive sur un serveur Web IIS6 ou IIS7 (IIS5 non pris en charge). J'utiliserais le routage de demande d'application comme Scott l'a suggéré pour séparer les sites Web en direct des tests. Une fois que vous avez vérifié que le site Web nouvellement publié est bon, vous pouvez configurer ARR pour qu'il achemine vers la nouvelle version.

PyroBatchFTP fonctionne très bien pour cela. Il poussera uniquement les modifications et vous pourrez le scripter afin de pouvoir pousser avec un double-clic sur un fichier batch.

Chez Vaasnet, nous avons configuré la solution de rêve pour nous-mêmes, mais il est assez compliqué à installer, mais cela vaut la peine d'utiliser certains ou tous ces éléments si vous le pouvez. Voici ce que c'est:

• SVN sur toutes nos machines de développement
• SVN sur notre serveur de build / déploiement
• Cruisecontrol.net surveille les modifications apportées à SVN et crée et met en scène uniquement les fichiers nécessaires dans un dossier intermédiaire
• en utilisant PyroBatchFTP, nous poussons vers un site intermédiaire (déclenché par Cruisecontrol pour que cela se produise automatiquement)
• en utilisant IIS7 et Application Request Routing (ARR) et URL Rewrite, nous avons la configuration de production / transfert suivante:
  • L'ARR à l'avant dirigera le trafic vers l'instance 01 ou 02, selon celle qui est «en direct» et celle qui est «en transit»
  • le compte FTP est toujours lié à la «mise en scène»
  • J'ai un autre mini-site d'administration qui permutera la mise en scène et vivra en un seul clic. Cela prend 1 seconde pour basculer avec zéro temps d'arrêt et nous pouvons revenir en arrière si nous réalisons que quelque chose n'allait pas avec cette version (bien que ce soit rare car nous pouvons le tester si facilement avant de le mettre en ligne).

Ainsi, le résultat net nous permet de vérifier dans SVN et de le faire automatiquement construire et pousser à la production sans aucune interaction manuelle. Après avoir testé notre URL de transfert et déterminé qu'elle est prête à être mise en ligne, nous nous connectons à un site simple et en 1 clic, elle est en ligne.

Pour une autre manière qui n'a pas été suggérée, je vous renvoie aux projets «Gu» et de configuration Web

Cela crée essentiellement un programme d'installation MSI pour votre application .NET. Cet exemple est pour VS2005, mais j'ai VS2010 et le type de projet est toujours là. Cela peut vous donner beaucoup de personnalisation si vous en avez besoin, ou simplement l'installation de base si vous n'en avez pas.

Personnellement, là où je travaille, nous faisons juste un déploiement de style xcopy, mais j'aimerais finalement remettre un paquet au groupe de serveurs, en leur donnant le contrôle quand et comment il est déployé. (Je pense que cela pourrait également faciliter les déploiements de masse en utilisant quelque chose comme la stratégie de groupe, mais je ne suis pas trop familier avec cela)

Il existe de nombreuses façons d'habiller ce chat, cela dépend vraiment de l'accès que vous pouvez avoir sur votre serveur. Ma méthode préférée récemment est de configurer un script de construction dans le projet (généralement en utilisant MSBUILD) qui empaquette tous les fichiers de déploiement, puis utilise SVN pour les relier à la production. Et pour versionner les fichiers de production.

Au niveau de la base de données, le meilleur pari est d'utiliser une sorte de cadre de migration. Encore une fois, un tas de ceux qui courent et aucune vraie réponse claire.

Personnellement, j'utilise simplement un script vbs que j'ai écrit moi-même pour copier des dossiers de types de fichiers spécifiques sur le serveur de développement (c.-à-d. Exclure les fichiers cs, etc.).

Lorsque j'ai travaillé dans une grande entreprise .com, c'est ce que nous avons fait avec nos déploiements .net.

Tous nos codes source et procédures stockées ont été stockés dans SVN. Chaque nuit, un travail de base de données s'exécute et extrait les proc stockés en production et les glisse dans un répertoire sur SVN afin qu'il y ait toujours une version la plus récente dans le contrôle de source.

Le jour du déploiement d'un projet, nous utiliserions un script nAnt pour extraire les projets de SVN, effectuer une construction personnalisée des projets et extraire toutes les dépendances dont ces projets avaient besoin. Une fois le script nAnt exécuté, il a été empaqueté dans un fichier zip auto-extractible. Les proc stockés qui étaient associés à ce déploiement ont été archivés dans le contrôle de code source et une feuille de présentation Excel a été mise à jour avec les scripts à exécuter et dans quel ordre.

Lorsque le deploymenet s'est éteint, le fichier zip auto-extractible a été transféré vers le serveur où il a été lancé. Tous les fichiers ont été extraits dans les répertoires appropriés et le DBA a exécuté les proc stockés sur la base de données de production.

Sur un déploiement typique utilisant ce système, nous sommes passés d'un déploiement de cinq à six heures à moins d'une heure ou moins.

Bonne chance et j'espère que cela aidera certains à trouver un moyen de déployer votre application.

Il doit y avoir un meilleur moyen que de simplement "publier" dans Visual Studio et de devoir ensuite FTP manuellement les fichiers qui ont changé?

Le rasoir d'Occam est généralement l'approche préférée: le plus simple, le mieux. FTP est facile avec peu ou pas de complications. Certaines personnes utilisent XCOPY, Filezilla ou WSFTP, d'autres peuvent utiliser l'outil de déploiement Web MS (que je ne connais pas encore), mais dans l'ensemble, il existe une meilleure façon de déployer des applications Web ASP.NET (et d'autres applications en général). IMO, si le déploiement est pris en considération dès le début du développement, le déploiement peut être intégré à l'application Web, ce qui permet un déploiement relativement indolore et sans heurt à l'avenir.

En tant que développeur .NET qui a travaillé dans plusieurs sociétés développant des applications Web ASP.NET de taille, de complexité et de nombre d'utilisateurs (de plusieurs centaines d'utilisateurs à des dizaines de milliers), le «déploiement» de l'OMI est souvent le sujet le plus «fluide». Certaines organisations vont trop loin en termes de bureaucratie tandis que d'autres ne résolvent aucun problème de déploiement. D'après mon expérience, les problèmes de déploiement ont tendance à tomber dans 1 ou plusieurs des 3 catégories en termes de difficultés / échecs:

1. Le déploiement est ignoré / oublié en profondeur pendant la phase de conception: la plupart des applications Web ont tendance à incorporer un serveur Web et une base de données. Au-delà du code d'application, peut-être de certaines procédures stockées et de tables de base de données, le déploiement n'a pas besoin de beaucoup de réflexion. ASP.NET est plus que capable d'aider dans le déploiement , mais le plus souvent les développeurs sont distraits en termes d'obtenir l'application réelle en cours d' exécution et faire tâche de tout en laissant la façon de déploiement comme une question distincte.

2. Le déploiement est complexe sur plusieurs systèmes et personnes en jeu: la complexité est une chienne. Depuis MSMQ, les procédures stockées et déclencheurs T-SQL, Reporting Services, la messagerie SOAP / XML, l'authentification AD, SSAS / SSIS, etc., etc., le nombre de technologies en jeu augmente le nombre de personnes impliquées. Pire encore, tous ces différents composants sont généralement gérés par différentes entités au sein d'une organisation. À moins que tout le monde ne soit synchronisé les uns avec les autres, les déploiements peuvent rapidement devenir plus complexes et entraîner de multiples points de défaillance.

3. Paresse, apathie ou manque de communication et / ou de gestion: de peu ou pas de documentation au manque de communication et de protocole coordonnés, il est facile de bousiller un processus relativement simple. Le déploiement devrait être une procédure simple avec de nombreuses vérifications en place tout en documentant ce qui est fait, mais souvent ce n'est jamais le cas. La plupart des gens veulent juste que ce putain de site soit en marche. D'après mon expérience, les gens (non-programmeurs) ne se soucient pas vraiment tant que quelque chose ne va pas vraiment . La responsabilité incombe rarement à une seule personne pour effectuer le déploiement, car personne ne veut vraiment être la raison de l'échec, de sorte que la responsabilité est généralement dispersée.

Il y a tellement d'exceptions de fichiers délicates que je devrais plutôt automatiser le processus autant que possible, pour éviter les téléchargements accidentels. Alors, comment fait votre équipe?

Je ne connais aucun fournisseur disponible pour automatiser le déploiement, bien que je ne serais pas surpris s'il y en avait quelques-uns. Vous pouvez probablement créer un script pour une solution via VBScript / WMI ou un script par lots pour une solution, mais la réalité est que vous devez adapter une solution ensemble pour des sites ASP.NET plus complexes. Sites simples composés de pages, de connectivité à la base de données et rien d'autre, vous n'avez pas besoin d'en faire autant pour adapter vos efforts de déploiement à la complexité de l'application elle-même.

Jusqu'à présent, dans mon travail actuel, le déploiement se fait toujours via FTP et déplace un tas de fichiers. C'est moche, facile à foutre et il n'y a aucun sens d'une histoire précise. Certes, vous pouvez passer au peigne fin les journaux FTP, personne ne dérange vraiment de le faire. Nos applications sont assez simples sans grand besoin de FTP. La façon dont mon équipe déploie nos applications Web ne vous est d'aucune utilité. Au lieu de cela, je préfère profiter de cette occasion pour suggérer de meilleures pratiques.

• N'assume rien. Comptes d'utilisateurs, privilèges R / W / X, ACL, pare-feu, calendrier (quand déployer et combien de temps vous devez le faire), et si possible, tester le déploiement dans tous les environnements avant la "date de lancement" finale.
• Avant que le développement ne commence réellement, intégrez le déploiement au développement. S'il s'agit d'un simple site, qu'il en soit ainsi. S'il y a de nombreuses pièces mobiles, facteur tout cela et fait construire un plan auquel tous les composants (code, base de données, rapports, files d' attente, etc.) sont tous sur le même plan.
• Coordonnez-vous avec les autres parités et communiquez efficacement.
• Documentez autant d'informations pertinentes que possible.
• Environnement: un serveur Web par rapport à une batterie de serveurs Web; 32 bits contre 64 bits; trouver un moyen de surveiller les journaux / erreurs / rotation, etc.
• Trouvez (ou créez) des outils qui peuvent aider au déploiement.
• Si possible pour un déploiement programmable, choisissez un paradigme et respectez-le. Par exemple, si vous souhaitez utiliser un serveur de base de données comme moyen principal pour effectuer l'état, le déploiement, l'accès et ainsi de suite d'une application, intégrez-le dans l'application et respectez-le. Si vous préférez lire les fichiers XML (comme web.config) par tous les moyens, respectez simplement un paradigme cohérent de déploiement de l'application. Autre exemple: certaines organisations laissent web.config en tant que fichier statique dans chaque environnement qui ne doit pas être déployé dans d'autres environnements. Le programme web.config de l'autre de manière à pouvoir être déployé sans erreur dans les environnements.

Je me rends compte que ce message pourrait être exagéré pour la question qui a été initialement posée. Malheureusement, le déploiement n'est tout simplement pas une chose simple car les applications peuvent varier en complexité. Je parierais que la plupart des organisations qui déploient des applications ASP.NET complexes ont au fil du temps développé certaines stratégies de travail (au moins) de manière fiable.