Come si distribuisce l'applicazione Web .NET? (Consigli, per favore!)

Abbiamo recentemente aggiornato il nostro sito Web ASP.NET a un'applicazione Web e siamo scioccati dall'improvviso salto di difficoltà durante la distribuzione. Considerando quanto deve essere comune un compito, mi chiedevo quali plug-in / software le persone usano per distribuire un progetto in rapida evoluzione, archiviato in remoto (ovvero un sito Web)?

Deve esserci un modo migliore della semplice "Pubblicazione" in Visual Studio e quindi dover FTP manualmente i file che sono stati modificati? Non da ultimo perché il sito si arresta durante il caricamento dei nostri .DLL.

Ci sono così tante eccezioni di file difficili che dovrei piuttosto automatizzare il processo il più possibile, per evitare caricamenti accidentali.

Con la nostra vecchia soluzione (sul nostro sito Web) abbiamo utilizzato Dispatch per ASP che ha scosso completamente e fatto l'intero processo con un clic. Sfortunatamente non è eccezionale per le DLL (come precedentemente menzionato).

Quindi come lo fa la tua squadra?

Grazie per qualsiasi consiglio

PS: ho letto che Visual Studio 2010 dovrebbe affrontare queste carenze in VS2005 / 08, ma fino ad allora ...

Consiglio vivamente di utilizzare l'integrazione continua.

Usiamo una combinazione di TeamCity per CI, Rake e Albacore per automatizzare la build.

TeamCity controllerà il codice dal repository del codice sorgente, quindi, utilizzando Rake, costruirà l'applicazione, eseguirà test unitari ed eseguirà anche gli script del database, se lo desideri. Dopo una compilazione riuscita, puoi impacchettare il tuo codice sorgente in un file zip o copiarlo in una destinazione di tua scelta.

Usiamo Git, sebbene TeamCity funzioni con tutti i sistemi di controllo del codice sorgente.

L'uso di TeamCity e Rake sarebbe simile all'utilizzo di CruiseControl e NANT, senza la modifica del file XML. Ovviamente, puoi usare TeamCity con NANT se preferisci.

Un breve campione estratto da un rakefile.rb che esegue la compilazione. IMHO, più facile da leggere ed eseguire il debug di un file 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 è una suite di attività Rake appositamente creata per la distribuzione di applicazioni .NET.

Su Linux, ho usato fabric (fabfile.org) e capistrano (capify.org) che sono strumenti di automazione per assistere i comandi remoti SSH e SCP. Se hai installato Cygwin sui tuoi host Windows, dovresti essere in grado di riutilizzarli come strumenti di distribuzione.

"Pubblicazione" di un'applicazione Web in Visual Studio può essere eseguita dalla riga di comando come msbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir". La directory di destinazione è un'applicazione Web distribuibile.

Le altre risposte che coprono la tua domanda più ampia sono buone. Aggiungo anche che dovresti guardare diversi progetti di applicazioni web open source e copiare il processo di compilazione che ti piace di più.

Concordo con Scott sul fatto che questo può essere molto complicato e facilmente trascurabile. Anche la strategia di implementazione è molto specifica per l'applicazione. Se l'app è completamente autonoma in una cartella, potrebbe essere più semplice di un'app che fa riferimento al GAC. Che a sua volta potrebbe essere ancora più semplice di un server che deve mantenere più versioni di un'app che fa riferimento a più versioni di assembly il GAC. Non vogliamo iniziare a parlare dei file delle politiche qui :).

Detto questo, combinare lo strumento di distribuzione Web Microsoft con il routing delle richieste dell'applicazione è una buona opzione. In IIS7, è possibile creare pacchetti di installazione utilizzando lo strumento. È anche possibile puntare lo strumento su un'applicazione Web e eseguire il backup dell'intera app in una cartella di archivio dell'applicazione. È quindi possibile distribuire da questa cartella di archivio su un IIS6 o un server Web IIS7 (IIS5 non supportato). Vorrei utilizzare il routing delle richieste dell'applicazione come Scott ha suggerito di separare dal vivo dai siti Web di prova. Una volta verificato che il sito Web appena pubblicato è valido, è possibile impostare ARR per il routing alla nuova versione.

PyroBatchFTP funziona alla grande per questo. Spingerà solo le modifiche e potrai scriverlo in modo da poter fare un doppio clic su un file batch.

In Vaasnet abbiamo impostato la soluzione dei sogni per noi stessi, ma è abbastanza complicato da configurare ma vale la pena usare alcuni o tutti questi elementi se è possibile. Ecco di cosa si tratta:

• SVN su tutte le nostre macchine sviluppatore
• SVN sul nostro server di compilazione / distribuzione
• Cruisecontrol.net controlla le modifiche a SVN e costruirà e metterà in scena solo i file necessari in una cartella di gestione temporanea
• usando PyroBatchFTP, passiamo a un sito di gestione temporanea (attivato da Cruisecontrol in modo che avvenga automaticamente)
• utilizzando IIS7 e Application Request Routing (ARR) e URL Rewrite, abbiamo la seguente configurazione di staging / produzione:
  • L'ARR indirizzerà il traffico verso l'istanza 01 o 02, a seconda di quale sia "in diretta" e quale "messa in scena"
  • l'account FTP è sempre legato alla "messa in scena"
  • Ho un altro mini sito di amministrazione che cambierà la gestione temporanea e vivrà con un solo clic. Ci vuole tutto 1 secondo per passare con zero tempi di inattività e possiamo tornare di nuovo se ci rendiamo conto che qualcosa non andava in quella versione (anche se è raro dal momento che possiamo provarlo così facilmente prima di andare in diretta).

Quindi il risultato netto ci consente di controllare in SVN e farlo costruire automaticamente e spingere alla produzione senza alcuna interazione manuale. Dopo aver testato il nostro URL di gestione temporanea e stabilito che è pronto per essere pubblicato, accediamo a un sito semplice e con 1 clic è attivo.

Per un altro modo che non è stato suggerito, ti rimando a "the Gu" e ai progetti di installazione Web

Questo in pratica crea un programma di installazione MSI per l'applicazione .NET. Questo esempio è per VS2005, ma ho VS2010 e il tipo di progetto è ancora lì. Questo può darti molta personalizzazione se ne hai bisogno, o solo l'installazione di base se non lo fai.

Personalmente dove lavoro eseguiamo solo una distribuzione in stile xcopy, ma alla fine vorrei solo consegnare un pacchetto al gruppo di server, dando loro il controllo su quando e come viene distribuito. (Penso che questo potrebbe anche rendere più semplice eseguire distribuzioni di massa usando qualcosa come una politica di gruppo, ma non ne ho troppa familiarità)

Ci sono molti modi per abbellire questo gatto, dipende davvero da quanto accesso puoi avere sul tuo server. Il mio metodo preferito personale di recente è impostare uno script di compilazione all'interno del progetto (in genere utilizzando MSBUILD) che comprime tutti i file di distribuzione, quindi utilizza SVN per collegarli alla produzione. E alla versione dei file di produzione.

Dal punto di vista del database, la soluzione migliore è utilizzare una sorta di framework di migrazione. Ancora una volta, un gruppo di quelli che correvano e nessuna vera risposta chiara.

Personalmente uso solo uno script vbs che ho scritto da solo per copiare cartelle di tipi di file specifici sul server di sviluppo (es. Tralasciando i file cs, ecc.).

Quando ho lavorato in una grande azienda .com, questo è quello che abbiamo fatto con le nostre distribuzioni .net.

Tutto il nostro codice sorgente e le procedure memorizzate sono state archiviate in SVN. Ogni notte viene eseguito un processo di database che estrae i proc memorizzati di produzione e li inserisce in una directory su SVN in modo che esistesse sempre una versione più recente nel controllo del codice sorgente.

Il giorno della distribuzione di un progetto, utilizzeremmo uno script nAnt per estrarre i progetti da SVN, realizzare una build personalizzata dei progetti e ottenere tutte le dipendenze necessarie per questi progetti. Una volta eseguito lo script nAnt, è stato impacchettato in un file zip autoestraente. I processi memorizzati associati a questa distribuzione sono stati controllati nel controllo del codice sorgente e un foglio di spree Excel è stato aggiornato con gli script da eseguire e in quale ordine.

Quando il deploymenet si è spento, il file zip autoestraente è stato trasferito sul server in cui è stato avviato. Tutti i file sono stati estratti nelle directory corrette e il DBA ha eseguito i proc memorizzati sul database di prodcution.

In una distribuzione tipica che utilizza questo sistema, siamo passati da una distribuzione da cinque a sei ore a meno di un'ora o meno.

Buona fortuna e spero che questo aiuti alcuni a trovare un modo per distribuire l'applicazione.

Deve esserci un modo migliore della semplice "Pubblicazione" in Visual Studio e quindi dover FTP manualmente i file che sono stati modificati?

Il rasoio di Occam è in genere l'approccio preferito: più semplice, meglio è. FTP è facile con poche o nessuna complicazione. Alcune persone usano XCOPY, Filezilla o WSFTP, altre potrebbero usare lo strumento di distribuzione Web MS (di cui non ho ancora familiarità), ma tutto sommato esiste un modo migliore di distribuire app Web ASP.NET (e altro app in generale). IMO, se la distribuzione viene presa in considerazione sin dall'inizio dello sviluppo, la distribuzione può essere integrata con l'app Web, il che consente una distribuzione relativamente indolore e regolare in futuro.

Come sviluppatore .NET che ha lavorato in diverse aziende sviluppando app Web ASP.NET di dimensioni, complessità e numero di utenti (da diverse centinaia a decine di migliaia), la "distribuzione" dell'IMO è spesso l'argomento più "fluido". Alcune organizzazioni si spingono troppo oltre in termini di burocrazia, mentre altre non affrontano alcun problema con la distribuzione. Nella mia esperienza, i problemi con la distribuzione tendono a rientrare in 1 o più di 3 categorie in termini di difficoltà / guasti:

1. La distribuzione viene ignorata / dimenticata in profondità durante la fase di progettazione: la maggior parte delle app Web tende a incorporare un server Web e un database. Oltre al codice dell'applicazione, forse alcune procedure memorizzate e tabelle del database, la distribuzione non ha bisogno di molte considerazioni. ASP.NET è più in grado di aiutare nella distribuzione ma più spesso gli sviluppatori sono distratti in termini di ottenere l'effettiva applicazione in esecuzione e facendo di essa la compito lasciando il modo di distribuzione come una questione separata.

2. La distribuzione è complessa su più sistemi e persone in gioco: la complessità è una cagna. Da MSMQ, T-SQL stored procedure e trigger, Reporting Services, messaggistica SOAP / XML, autenticazione AD, SSAS / SSIS, ecc. Ecc., Il numero di tecnologie in gioco aumenta il numero di persone coinvolte. Peggio ancora, tutti questi diversi componenti sono generalmente gestiti da entità diverse all'interno di un'organizzazione. A meno che tutti non siano sincronizzati tra loro, le implementazioni possono aumentare rapidamente in complessità portando a più punti di errore.

3. Pigrizia, apatia o mancanza di comunicazione e / o gestione: dalla poca o nessuna documentazione alla mancanza di comunicazione e protocollo coordinati, è facile rovinare un processo relativamente semplice. La distribuzione dovrebbe essere una procedura semplice con numerosi controlli in atto per documentare ciò che è stato fatto, ma spesso non è mai così. La maggior parte delle persone vuole solo che questo maledetto sito funzioni. In base alla mia esperienza, alle persone (non programmatori) non importa davvero fino a quando qualcosa non diventa veramente fubar. Raramente la responsabilità ricade su una sola persona per eseguire effettivamente la distribuzione poiché nessuno vuole davvero essere la ragione del fallimento, quindi la responsabilità è generalmente dispersa.

Ci sono così tante eccezioni di file difficili che dovrei piuttosto automatizzare il processo il più possibile, per evitare caricamenti accidentali. Quindi come lo fa la tua squadra?

Non conosco fornitori disponibili per automatizzare la distribuzione, anche se non sarei sorpreso se ce ne fossero alcuni. Probabilmente potresti creare una soluzione tramite VBScript / WMI o scrivere in batch una soluzione, ma la realtà è che devi adattare una soluzione insieme per siti ASP.NET più complessi. Siti semplici costituiti da pagine, connettività di database e nient'altro, non è necessario fare altrettanto, quindi scalare le attività di implementazione in linea con la complessità dell'applicazione stessa.

Finora, al mio attuale lavoro, la distribuzione è ancora eseguita tramite FTP e spostando un mucchio di file. È brutto, facile da rovinare e non ha senso una storia accurata. Concesso che potresti controllare i log FTP, nessuno si preoccupa davvero di farlo. Le nostre app sono abbastanza semplici senza molto bisogno oltre FTP. Il modo in cui il mio team distribuisce le nostre app Web è davvero poco utile per te. Invece, preferirei cogliere questa opportunità per suggerire pratiche migliori .

• Non assumere niente. Account utente, privilegi R / W / X, ACL, firewall, tempistica (quando distribuire e quanto tempo è necessario ) e, se possibile, testare la distribuzione in tutti gli ambienti prima della "data di lancio" finale.
• Prima che lo sviluppo abbia effettivamente inizio, fattore di sviluppo nello sviluppo. Se è un sito semplice, così sia. Se ci sono numerose parti mobili, includetele tutte e costruite effettivamente un piano in cui tutti i componenti (codice, database, report, code, ecc.) Siano tutti sullo stesso piano.
• Coordinare con altre parità e comunicare in modo efficace ed efficiente.
• Documentare quante più informazioni pertinenti, se possibile.
• Ambiente: un web server vs. web farm; 32 bit contro 64 bit; trovare un modo per monitorare i registri / errori / ruotare, ecc.
• Trova (o costruisci) strumenti che possono essere di aiuto nella distribuzione.
• Se possibile per una distribuzione programmabile, selezionare un paradigma e attenersi ad esso. Ad esempio, se si desidera utilizzare un server di database come mezzo principale per eseguire lo stato, la distribuzione, l'accesso e così via di un'applicazione, inserirla nell'applicazione e attenersi ad essa. Se si preferisce leggere i file XML (come web.config) in ogni caso, attenersi a un paradigma coerente di distribuzione dell'applicazione. Un altro esempio: alcune organizzazioni lasciano web.config come file statico in ogni ambiente che non dovrebbe essere distribuito ad altri ambienti. Programma web.config di altri in modo tale da poter essere distribuito su più ambienti senza errori.

Mi rendo conto che questo post potrebbe essere eccessivo per la domanda che è stata inizialmente posta. Sfortunatamente, la distribuzione non è una cosa semplice in quanto le applicazioni possono variare in complessità. Scommetto che la maggior parte delle organizzazioni che implementano app ASP.NET complesse hanno sviluppato nel tempo determinate strategie di lavoro (almeno) in modo affidabile.