Come distribuite le vostre applicazioni ASP.NET sui server live?

Sto cercando diverse tecniche / strumenti che usi per distribuire un progetto di applicazione web ASP.NET ( NON un sito web ASP.NET) in produzione?

Sono particolarmente interessato al flusso di lavoro che si verifica tra il momento in cui il server Continuous Integration Build rilascia i file binari in una posizione e il momento in cui la prima richiesta dell'utente raggiunge questi binari.

1. Stai usando alcuni strumenti specifici o solo XCOPY? Come viene confezionata l'applicazione (ZIP, MSI, ...)?

2. Quando un'applicazione viene distribuita per la prima volta, come si configurano il pool di app e la directory virtuale (le si crea manualmente o con qualche strumento)?

3. Quando una risorsa statica cambia (CSS, JS o file immagine) ridistribuisci l'intera applicazione o solo la risorsa modificata? Che ne dici di quando cambia una pagina assembly / ASPX?

4. Tieni traccia di tutte le versioni distribuite per una determinata applicazione e, nel caso in cui qualcosa vada storto, disponi di procedure per ripristinare l'applicazione a un precedente stato di lavoro noto?

Sentiti libero di completare l'elenco precedente.

Ed ecco cosa usiamo per distribuire le nostre applicazioni ASP.NET:

1. Aggiungiamo un progetto di distribuzione Web alla soluzione e lo configuriamo per creare l'applicazione Web ASP.NET
2. Aggiungiamo un progetto di installazione ( NON un progetto di installazione Web) alla soluzione e lo impostiamo per prendere l'output del progetto di distribuzione Web
3. Aggiungiamo un'azione di installazione personalizzata e nell'evento OnInstall eseguiamo un assembly .NET di build personalizzato che crea un pool di app e una directory virtuale in IIS utilizzando System.DirectoryServices.DirectoryEntry (questa attività viene eseguita solo la prima volta che un'applicazione viene distribuita) . Supportiamo più siti Web in IIS, autenticazione per directory virtuali e impostazione di identità per pool di app.
4. Aggiungiamo un'attività personalizzata in TFS per creare il progetto di installazione (TFS non supporta i progetti di installazione, quindi abbiamo dovuto usare devenv.exe per creare l'MSI)
5. L'MSI è installato sul server live (se c'è una versione precedente dell'MSI viene prima disinstallato)

Abbiamo tutto il nostro codice distribuito in MSI utilizzando Setup Factory. Se qualcosa deve cambiare, ridistribuiamo l'intera soluzione. Sembra eccessivo per un file css, ma mantiene assolutamente sincronizzati tutti gli ambienti e sappiamo esattamente cosa è in produzione (distribuiamo allo stesso modo su tutti gli ambienti di test e uat).

Eseguiamo la distribuzione in sequenza sui server live, quindi non utilizziamo progetti di installazione; abbiamo qualcosa di più simile a CI:

• build-server "live" dalla fonte approvata (non "HEAD" del repository)
• (dopo che ha preso un backup ;-p)
• robocopy pubblica su un server di staging ("live", ma non nel cluster F5)
• convalida finale eseguita sul server di staging, spesso con hack "host" per emulare l'intera cosa il più fedelmente possibile
• robocopy / L viene utilizzato automaticamente per distribuire un elenco delle modifiche nel successivo "push", per avvisare di eventuali errori
• come parte di un processo pianificato, il cluster viene ciclato, distribuendosi ai nodi nel cluster tramite robocopy (mentre sono fuori dal cluster)

robocopy garantisce automaticamente che vengano distribuite solo le modifiche.

Re l'App Pool ecc; Mi piace questo per essere automatizzato ( vedi questa domanda ), ma al momento in cui esso è manuale. Voglio davvero cambiare la situazione, però.

(probabilmente aiuta avere il nostro data center e server farm "in loco", in modo da non dover superare molti ostacoli)

Sito web

Deployer: http://www.codeproject.com/KB/install/deployer.aspx

Pubblico il sito web in una cartella locale, lo comprimo e poi lo carico su FTP. Deployer sul server quindi estrae zip, sostituisce i valori di configurazione (in Web.Config e altri file) e il gioco è fatto.

Ovviamente per la prima esecuzione è necessario connettersi al server e configurare IIS WebSite, database, ma dopo che la pubblicazione degli aggiornamenti è un gioco da ragazzi.

Banca dati

Per mantenere i database sincronizzati, utilizzo http://www.red-gate.com/products/sql-development/sql-compare/

Se il server è dietro un gruppo di router e non puoi connetterti direttamente (che è un requisito di SQL Compare), usa https://secure.logmein.com/products/hamachi2/ per creare VPN.

Distribuisco principalmente app ASP.NET su server Linux e ridistribuisco tutto anche per le modifiche più piccole. Ecco il mio flusso di lavoro standard:

• Uso un repository di codice sorgente (come Subversion)
• Sul server, ho uno script bash che fa quanto segue:
  • Controlla l'ultimo codice
  • Crea una build (crea le DLL)
  • Filtra i file fino all'essenziale (rimuove i file di codice, ad esempio)
  • Esegue il backup del database
  • Distribuisce i file al server Web in una directory denominata con la data corrente
  • Aggiorna il database se un nuovo schema è incluso nella distribuzione
  • Rende la nuova installazione quella predefinita in modo che venga pubblicata con l'hit successivo

Il checkout viene eseguito con la versione a riga di comando di Subversion e la compilazione viene eseguita con xbuild (msbuild funziona allo stesso modo dal progetto Mono). La maggior parte della magia viene eseguita in ReleaseIt.

Sul mio server di sviluppo ho essenzialmente un'integrazione continua, ma dal punto di vista della produzione in realtà ho SSH nel server e avvio manualmente la distribuzione eseguendo lo script. Il mio script è abilmente chiamato "deploy", quindi è quello che digito al prompt di bash. Sono molto creativa. Non.

In produzione, devo digitare "deploy" due volte: una per eseguire il check-out, compilare e distribuire in una directory datata e una volta per rendere quella directory l'istanza predefinita. Poiché le directory sono datate, posso tornare a qualsiasi distribuzione precedente semplicemente digitando "deploy" dalla directory pertinente.

La distribuzione iniziale richiede un paio di minuti e il ripristino a una versione precedente richiede alcuni secondi.

È stata una buona soluzione per me e si basa solo sulle tre utilità della riga di comando (svn, xbuild e releaseit), il client DB, SSH e Bash.

Ho davvero bisogno di aggiornare la copia di ReleaseIt su CodePlex qualche volta:

http://releaseit.codeplex.com/

XCopy semplice per ASP.NET. Comprimilo, sftp sul server, estrai nella posizione corretta. Per la prima distribuzione, configurazione manuale di IIS

Rispondere alle tue domande:

1. XCopy
2. manualmente
3. Per le risorse statiche, distribuiamo solo la risorsa modificata.
   Per le DLL distribuiamo la DLL modificata e le pagine ASPX.
4. Sì e sì.

Mantenerlo bello e semplice ci ha risparmiato un sacco di mal di testa finora.

Stai usando alcuni strumenti specifici o solo XCOPY? Come viene confezionata l'applicazione (ZIP, MSI, ...)?

Come sviluppatore per BuildMaster , questo è naturalmente quello che uso. Tutte le applicazioni vengono create e confezionate all'interno dello strumento come artefatti, che vengono archiviati internamente come file ZIP.

Quando un'applicazione viene distribuita per la prima volta, come si configurano il pool di app e la directory virtuale (le si crea manualmente o con qualche strumento)?

Manualmente: creiamo un controllo delle modifiche all'interno dello strumento che ci ricorda i passaggi esatti da eseguire negli ambienti futuri mentre l'applicazione si muove attraverso i suoi ambienti di test. Questo potrebbe anche essere automatizzato con un semplice script PowerShell, ma non aggiungiamo nuove applicazioni molto spesso, quindi è altrettanto facile dedicare 1 minuto alla creazione manuale del sito.

Quando una risorsa statica cambia (CSS, JS o file immagine) ridistribuisci l'intera applicazione o solo la risorsa modificata? Che ne dici di quando cambia una pagina assembly / ASPX?

Per impostazione predefinita, il processo di distribuzione degli artefatti è configurato in modo tale che solo i file modificati vengano trasferiti al server di destinazione, inclusi tutti i file CSS, i file JavaScript, le pagine ASPX e gli assembly collegati.

Tieni traccia di tutte le versioni distribuite per una determinata applicazione e, nel caso in cui qualcosa vada storto, disponi di procedure per ripristinare l'applicazione a un precedente stato di lavoro noto?

Sì, BuildMaster gestisce tutto questo per noi. Il ripristino è per lo più semplice come rieseguire una vecchia promozione di build, ma a volte le modifiche al database devono essere ripristinate manualmente e può verificarsi una perdita di dati. Il processo di ripristino di base è descritto in dettaglio qui: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

progetti di configurazione / installazione web, in modo da poterlo disinstallare facilmente se qualcosa va storto

Unfold è una soluzione di distribuzione simile a capistrano che ho scritto per le applicazioni .net. È ciò che utilizziamo in tutti i nostri progetti ed è una soluzione molto flessibile. Risolve la maggior parte dei problemi tipici delle applicazioni .net come spiegato in questo post del blog di Rob Conery.

• ha un buon comportamento "predefinito", nel senso che fa molte cose standard per te: ottenere il codice dal controllo del codice sorgente, compilare, creare il pool di applicazioni, configurare IIS, ecc.
• versioni basate su cosa c'è nel controllo del codice sorgente
• ha task hook , quindi il comportamento predefinito può essere facilmente esteso o modificato
• ha rollback
• è tutto PowerShell , quindi non ci sono dipendenze esterne
• utilizza la comunicazione remota PowerShell per accedere a macchine remote

Ecco un'introduzione e alcuni altri post del blog.

Quindi, per rispondere alle domande sopra:

• Come viene confezionata l'applicazione (ZIP, MSI, ...)?

  Git (o un altro scm) è il modo predefinito per ottenere l'applicazione sulla macchina di destinazione. In alternativa è possibile eseguire una compilazione locale e copiare il risultato tramite la connessione remota Powereshell

• Quando un'applicazione viene distribuita per la prima volta, come si configurano il pool di app e la directory virtuale (le si crea manualmente o con qualche strumento)?

  Unfold configura il pool di applicazioni e l'applicazione del sito Web utilizzando il modulo di amministrazione Web di Powershell. Consente a noi (ea te) di modificare qualsiasi aspetto del pool di applicazioni o del sito web

• Quando una risorsa statica cambia (CSS, JS o file immagine) ridistribuisci l'intera applicazione o solo la risorsa modificata? Che ne dici di quando cambia una pagina assembly / ASPX?

  Sì, unfold fa questo, qualsiasi deploy viene installato accanto agli altri. In questo modo possiamo facilmente tornare indietro quando qualcosa va storto. Ci consente inoltre di risalire facilmente a una versione distribuita in una revisione del controllo del codice sorgente.

• Tieni traccia di tutte le versioni distribuite per una determinata applicazione?

  Sì, unfold mantiene le vecchie versioni in giro. Non tutte le versioni, ma un certo numero di versioni. Rende il rollback quasi banale.

Abbiamo migliorato il nostro processo di rilascio nell'ultimo anno e ora lo abbiamo abbassato. Sto usando Jenkins per gestire tutte le nostre build e release automatizzate, ma sono sicuro che potresti usare TeamCity o CruiseControl.

Quindi, al momento del check-in, la nostra build "normale" esegue le seguenti operazioni:

• Jenkins esegue un aggiornamento SVN per recuperare l'ultima versione del codice
• Viene eseguito un ripristino del pacchetto NuGet nel nostro repository NuGet locale
• L'applicazione viene compilata utilizzando MsBuild. La configurazione è un'avventura, perché è necessario installare il corretto MsBuild e quindi le dll ASP.NET e MVC sulla tua build box. (Come nota <MvcBuildViews>true</MvcBuildViews>a margine , quando ho inserito i miei file .csproj per compilare le viste, msbuild si arrestava in modo casuale, quindi ho dovuto disabilitarlo)
• Una volta compilato il codice, vengono eseguiti gli unit test (sto usando nunit per questo, ma puoi usare tutto ciò che vuoi)
• Se tutti gli unit test vengono superati, interrompo il pool di app IIS, distribuisco l'app localmente (solo pochi comandi XCOPY di base per copiare i file necessari) e quindi riavvio IIS (ho avuto problemi con i file di blocco IIS e questo ha risolto esso)
• Ho file web.config separati per ogni ambiente; dev, uat, prod. (Ho provato a utilizzare il materiale di trasformazione web con scarso successo). Quindi viene copiato anche il file web.config corretto
• Quindi uso PhantomJS per eseguire una serie di test dell'interfaccia utente. Richiede anche una serie di screenshot a diverse risoluzioni (mobile, desktop) e stampa ogni screenshot con alcune informazioni (titolo della pagina, risoluzione). Jenkins ha un ottimo supporto per la gestione di questi screenshot e vengono salvati come parte della build
• Una volta superati i test dell'interfaccia utente di integrazione, la compilazione ha esito positivo

Se qualcuno fa clic su "Distribuisci a UAT":

• Se l'ultima build ha avuto successo, Jenkins esegue un altro aggiornamento SVN
• L'applicazione viene compilata utilizzando una configurazione RELEASE
• Viene creata una directory "www" e l'applicazione viene copiata in essa
• Quindi uso winscp per sincronizzare il filesystem tra la build box e l'UAT
• Invio una richiesta HTTP al server UAT e mi assicuro di ricevere un 200
• Questa revisione è contrassegnata in SVN come UAT-datetime
• Se siamo arrivati ​​a questo punto, la build ha successo!

Quando facciamo clic su "Distribuisci in Prod":

• L'utente seleziona un tag UAT che è stato creato in precedenza
• Il tag viene "cambiato" in
• Il codice viene compilato e sincronizzato con il server Prod
• Richiesta HTTP al server Prod
• Questa revisione è contrassegnata in SVN come Prod-datetime
• Il rilascio è zippato e conservato

In tutto, una build completa per la produzione richiede circa 30 secondi di cui sono molto, molto soddisfatto.

Vantaggi di questa soluzione:

• È veloce
• I test unitari dovrebbero rilevare gli errori logici
• Quando un bug dell'interfaccia utente entra in produzione, si spera che gli screenshot mostrino quale revisione # l'ha causato
• UAT e Prod vengono mantenuti sincronizzati
• Jenkins mostra una grande cronologia delle versioni a UAT e Prod con tutti i messaggi di commit
• Le versioni UAT e Prod sono tutte contrassegnate automaticamente
• Puoi vedere quando avvengono i rilasci e chi li ha fatti

I principali svantaggi di questa soluzione sono:

• Ogni volta che fai un rilascio a Prod devi fare un rilascio a UAT. Questa è stata una decisione consapevole che abbiamo preso perché volevamo assicurarci sempre che UAT fosse sempre aggiornato con Prod. Tuttavia, è un dolore.
• Ci sono parecchi file di configurazione in giro. Ho tentato di avere tutto in Jenkins, ma sono necessari alcuni file batch di supporto come parte del processo. (Anche questi sono registrati).
• Gli script di upgrade e downgrade del database fanno parte dell'app e vengono eseguiti all'avvio dell'app. Funziona (principalmente), ma è un dolore.

Mi piacerebbe sentire altri possibili miglioramenti!

Nel 2009, da dove proviene questa risposta, abbiamo utilizzato CruiseControl.net per le nostre build di integrazione continua, che ha anche prodotto Release Media.

Da lì abbiamo utilizzato il software Smart Sync per il confronto con un server di produzione che era fuori dal pool di bilanciamento del carico e abbiamo spostato le modifiche verso l'alto.

Infine, dopo aver convalidato il rilascio, abbiamo eseguito uno script DOS che utilizzava principalmente RoboCopy per sincronizzare il codice sui server live, arrestando / avviando IIS man mano che procedeva.

Nell'ultima azienda per cui ho lavorato, distribuivamo utilizzando un file batch rSync per caricare solo le modifiche dall'ultimo caricamento. La bellezza di rSync è che puoi aggiungere elenchi di esclusione per escludere file specifici o modelli di nomi di file. Quindi escludere tutti i nostri file .cs, soluzioni e file di progetto è davvero facile, per esempio.

Stavamo usando TortoiseSVN per il controllo della versione, quindi è stato bello poter scrivere in diversi comandi SVN per ottenere quanto segue:

• Prima di tutto, controlla che l'utente abbia l'ultima revisione. In caso contrario, chiedi loro di aggiornare o esegui l'aggiornamento immediatamente e poi.
• Scarica un file di testo dal server chiamato "synclog.txt" che specifica chi è l'utente SVN, quale numero di revisione sta caricando e la data e l'ora del caricamento. Aggiungi una nuova riga per il caricamento corrente, quindi invialo di nuovo al server insieme ai file modificati. Ciò rende estremamente facile scoprire a quale versione del sito eseguire il rollback nella remota possibilità che un caricamento causi problemi.

Oltre a questo c'è un secondo file batch che controlla solo le differenze di file sul server live. Questo può evidenziare il problema comune in cui qualcuno caricava ma non salvava le proprie modifiche su SVN. In combinazione con il registro di sincronizzazione menzionato sopra, abbiamo potuto scoprire chi era il probabile colpevole e chiedere loro di impegnarsi nel loro lavoro.

Infine, rSync ti consente di eseguire un backup dei file che sono stati sostituiti durante il caricamento. Li abbiamo spostati in una cartella di backup Quindi, se improvvisamente ti sei reso conto che alcuni dei file non avrebbero dovuto essere sovrascritti, puoi trovare l'ultima versione di backup di ogni file in quella cartella.

Anche se la soluzione all'epoca sembrava un po 'goffa, da allora ho imparato ad apprezzarla molto di più quando si lavora in ambienti in cui il metodo di caricamento è molto meno elegante o facile (desktop remoto, copia e incolla l'intero sito, ad esempio) .

Suggerirei NON solo di sovrascrivere i file dell'applicazione esistenti, ma invece di creare una directory per versione e di rinominare l'applicazione IIS nel nuovo percorso. Questo ha diversi vantaggi:

• Veloce da ripristinare se necessario
• Non è necessario arrestare IIS o il pool di app per evitare problemi di blocco
• Nessun rischio che i vecchi file causino problemi
• Tempo di inattività più o meno pari a zero (di solito viene inizializzata solo una pausa al nuovo dominio app)

L'unico problema che abbiamo riscontrato è che le risorse vengono memorizzate nella cache se non riavvii il pool di app e fai affidamento sul cambio automatico del dominio dell'app.