Quale metodo si utilizza per distribuire le applicazioni ASP.Net in modo selvaggio?

Question

Attualmente distribuiamo applicazioni ASP.Net compilate pubblicando il sito Web localmente e inviando per e-mail un file zip all'amministratore di sistema con un (solitamente) lungo set di istruzioni per la distribuzione. Ciò è dovuto al fatto che la prima volta che abbiamo distribuito un'applicazione ASP.Net a un cliente le istanze di sviluppo e test di IIS erano uguali e non è stato possibile distribuire il sito due volte sulla stessa macchina. Questo ha dato il tono per l'implementazione su tutti i progetti successivi.

Attualmente sto valutando i nostri metodi di implementazione e sto cercando in particolare gli strumenti di distribuzione incorporati; in particolare, sto osservando le attività di installazione personalizzate e l'utilizzo della maggior parte delle funzionalità di installazione standard che è possibile (principalmente l'interfaccia utente).

In secondo luogo, sto esaminando la fusione di distribuzioni e aggiornamenti automatici.

Come si distribuisce il software nella propria organizzazione? Quali strumenti usi e quali problemi ti capitano più frequentemente?

Answer 1

applicazioni Web Deploy Utilizzo dello Strumento di copia Web
testo da Kit Formazione Microsoft Based Development Libro Web
Progetti di installazione web sono utili se si sta fornendo un'applicazione Web a molti utenti (per esempio, permettendo alle persone di scaricare l'applicazione dal Web e installarla). Se si è responsabili dell'aggiornamento di un sito Web specifico per la propria organizzazione, non è pratico accedere al server Web e installare un pacchetto di Windows Installer ogni volta che si effettua un aggiornamento. Per le applicazioni interne, è possibile modificare l'applicazione Web direttamente sul server Web. Tuttavia, le modifiche apportate vengono immediatamente implementate nell'applicazione Web di produzione e questo include eventuali bug che potrebbero esserci. Per consentire a te stesso di testare un'applicazione Web, puoi modificare una copia locale dell'applicazione Web sul tuo computer e pubblicare le modifiche al server Web di produzione utilizzando lo strumento Copia Web. È inoltre possibile utilizzare lo strumento Copia Web per pubblicare le modifiche da un server di gestione temporanea a un server Web di produzione o tra due qualsiasi server Web. Lo strumento Copia Web può copiare singoli file o un intero sito Web da o verso un sito Web di origine e un sito Web remoto. È anche possibile scegliere di sincronizzare i file, il che implica copiare solo i file modificati e rilevare possibili conflitti di versione in cui lo stesso file sia sul sito di origine che su quello remoto sono stati modificati separatamente. Lo strumento Copia Web non può unire le modifiche all'interno di un singolo file; solo i file completi possono essere copiati.

Answer 2

Un paio di cose che ho fatto è il seguente:

1) Utilizzare un progetto di distribuzione Web per compilare e pulire l'accumulo e la sostituzione sezione consegna web.config se i cambiamenti di configurazione tra gli ambienti. 2) Utilizzare NAnt per eseguire tutto l'edificio, l'archiviazione e la copia in modo ripetitivo.

Il progetto di distribuzione Web termina creando un file MSBuild che può essere utilizzato al posto di NAnt; tuttavia, sono venuto da una priorità bassa di Java e ho usato Ant tutto il tempo quindi NAnt è la mia preferenza in .Net. Se si aggiungono le attività di Contrib NAnt, sarà possibile distribuire non solo i file ma anche gestire elementi come il controllo del codice sorgente (nel caso in cui non faccia parte delle attività predefinite) e Sql Script Execution per le modifiche.

Attualmente utilizzo entrambe le opzioni insieme. Ho il mio file di build NAnt chiamare il progetto di distribuzione Web tramite MSBuild. Con la configurazione del Configuration Manager per ciascun ambiente, mi consente di gestire automaticamente le sostituzioni della sezione web.config e mantenere comunque un controllo discreto sulla copia e l'archiviazione di una release.

Spero che questo aiuti.

Answer 3

Utilizziamo progetti di distribuzione Web ei progetti VS 2008 per creare un file .msi dall'output degli altri progetti di webdeployment &. Una normale app di Windows chiamata 'setup' è usata per fare molta della creazione di db e roba preliminare, piuttosto che provare a personalizzare i progetti di installazione con passi personalizzati. È molto più semplice farlo da soli rispetto al tentativo di personalizzare il codice MS. Questa app di Windows chiama quindi i file .msi corretti di cui l'utente ha bisogno.

Il build di base del team viene eseguito ogni sera per ricostruire la soluzione e copiare tutto in una directory 'Release CD' a cui chiunque può accedere e fare test sull'ultima 'release'. Per essere onesti, la costruzione di TFS è un po 'esagerata per una piccola squadra come la nostra, e la uso solo perché è ciò a cui sono abituato.

In una società precedente abbiamo utilizzato questo http://www.finalbuilder.com/ e posso consigliarlo per facilità d'uso e per la quantità di software supportato.

Answer 4

1) costruire progetto con MSBUILD

2 file FTP) per ambiente di produzione

3) copia/incolla manualmente per ogni server web

Answer 5

Per i siti intranet, usiamo CruiseControl in collaborazione con SVN per far ricostruire il sito automaticamente.

In teoria è possibile estendere questo modello su una VPN se è possibile mappare un'unità in remoto alla rete intranet di un client. O una soluzione più veloce e sporca potrebbe essere quella di utilizzare uno strumento come SyncBack per sincronizzare la cartella remota contenente le DLL compilate per il sito.

Answer 6

Abbiamo dedicato server DEV, TEST, STAGE e PRODUCTION.

Abbiamo anche una macchina dedicata che esegue Cruise Control.

Il Cruise Control è configurato per una build di integrazione continua, che viene eseguita dopo il check in del codice. È inoltre configurata per attività di sviluppo, controllo qualità, stage e produzione separate.

Per la distribuzione allo sviluppo, il codice viene prima richiamato da SVN e creato, quindi la cartella "Web precompilato" viene copiata nel sito Web di sviluppo e il progetto di servizio Web viene copiato nel server di applicazioni di sviluppo. Cruise Control è anche configurato per "etichettare" il codice sorgente prima che inizi la generazione, in modo che possiamo riprodurre la compilazione in un secondo momento o derivare dal tag se è necessario eseguire una correzione rapida.

Per la distribuzione in QA, i file vengono copiati dalle macchine di sviluppo alle macchine di controllo qualità.

Allo stesso modo, per eseguire il deployment su Stage, i file vengono copiati dalle macchine QA alle macchine Stage.

Infine, per la distribuzione in produzione, i file vengono nuovamente copiati dalle macchine Stage alle macchine di produzione.

Per configurare ciascun ambiente, abbiamo uno strumento personalizzato che fa parte dell'attività di Cruise Control di ogni ambiente che modifica le stringhe di connessione, "debug = true | false", "customErrors = Off | RemoteOnly" e altre impostazioni specifiche dell'ambiente .

Così ogni ambiente può essere schierato con un pulsante spinto dal cruscotto Cruise Control.

Un avvertimento è che al momento la password del database di produzione è configurata nel file di configurazione di Cruise Control ... sarebbe bello spostarlo altrove!

Infine, aggiungo che anche se le nostre macchine di produzione sono in una struttura di hosting dedicata, i server sono accessibili dalla nostra macchina Cruise Control, che rende molto facile fare una distribuzione di produzione. L'unico passaggio manuale consiste nel crittografare i file web.config e rimuovere il file "AppOffline.html" che Cruise Control presenta.

Fatemi sapere se questo aiuta o se avete domande.

Grazie!