Come si aggiornano i siti Web in tempo reale con modifiche al codice?

Dovresti controllare la distribuzione Web di VS 2010. Se GoGrid lo supporta, il pacchetto di distribuzione Web è una buona soluzione.

link

Al mio precedente datore di lavoro, per implementare le modifiche al codice, abbiamo impostato il bilanciamento del carico per interrompere servizio su un server web. Potrebbero essere necessari 20 minuti per la scadenza delle sessioni sul primo server Web. Dovremmo aggiornare il codice su quel server Web decomprimendo il file zip di implementazione, quindi verificate che le cose funzionino correttamente colpendo l'indirizzo IP diretto per quel primo web server. Quando siamo convinti che funzioni bene, allora imposteremo il bilanciamento del carico in modo che colpisca il server web ora aggiornato e attenda che le sessioni scadano su un altro server e quindi aggiorniamo quella (e così via fino a quando tutte sono state aggiornate). Dopo aver effettuato il check-out ok, avremmo impostato il bilanciamento del carico per tornare a fare il suo lavoro. Ciò si è complicato quando abbiamo avuto fino a 10 server Web connessi al bilanciamento del carico durante i picchi di carico stagionale (quindi aggiornarli uno alla volta potrebbe richiedere ore perché non potevamo chiudere il sito Web live - i clienti dovevano essere in grado di ottenere al sito).

In ASP.NET, se si rilascia qualsiasi file denominato App_Offline.htm nella directory principale di un sito Web, quel websiten scarica ciò che consentirà di aggiornare la DLL (e qualsiasi altra cosa). IIS servirà una pagina denominata "Applicazione offline". Quando il file viene rimosso, rinominato o eliminato, l'applicazione Web verrà riavviata e IIS fornirà pagine Web a tale sito Web. Questo è ciò che fa Visual Studio quando pubblichi un sito web da VS.

In genere quello che faccio è che tengo tutto in un repository SVN. Quando ho finito con alcune modifiche, mi impegno sul sito dev, e poi checkout sulla produzione. Mantiene tutto sincronizzato, è veloce e facile. Se il check-out è troppo complicato, puoi configurare Apache con WebDAV e lo farà per te.

Per ognuna delle mie app web ho una configurazione di repository git con tre rami. Live, Beta, Funzionalità. Dal vivo è naturalmente il sito dal vivo. Beta è il sito utilizzato per correggere i bug o per il test finale delle funzionalità prima dell'implementazione. Poi, come hai detto, faccio un semplice push git, git pull on live per inserire le informazioni. Le funzionalità sono utilizzate per i miglioramenti della "prossima versione".

Stai tentando di risolvere il problema di consegne continuative . Inizialmente avresti iniziato con passaggi manuali, ma presto ti renderai conto dei problemi. Questi sono i più comuni:

1. Il codice funziona sul tuo PC, non funziona sulla produzione
2. Nuova modifica interrompe il vecchio codice
3. Le modifiche incrementali renderanno sempre più difficile l'implementazione, riceverai nuove librerie da allegare, patch da applicare ecc.

Dai un'occhiata a TeamCity (o a qualsiasi strumento simile).

Utilizza uno script di generazione e distribuzione automatizzato

Il modo migliore per farlo è usare uno script di Build e Deploy automatico come MsBuild o Nant.

• link

Il motivo è che puoi semplicemente digitare 1 comando per aprire un sito Web e quindi semplicemente digitare 1 comando per eseguire il rollback. E se si è abbastanza accurati, ciò includerà le migrazioni dello schema del database. (Migrator.Net)

Uno dei motivi principali per cui non utilizzare SVN o GIT per la distribuzione è che l'ambiente può cambiare tra produzione e gestione temporanea. Nel tuo script NANT puoi creare i tuoi file .config appositamente per l'ambiente che stai cercando. Ciò evita di dimenticare di inserire un'impostazione di configurazione in produzione.

Inoltre, automatizza l'intero processo in modo che diventi un affare di comando, e qualsiasi numero di processi manuali diventa un processo semplice.

Prima di tutto, dovresti usare un progetto web. Quali sono le differenze che chiedi?

Un progetto web combina tutti i file di classe C # (code behinds inclusi) in una singola DLL (migliore per la sicurezza e il fatto che sia un file da spostare)

In secondo luogo, è necessario pubblicare l'applicazione e quindi è ancora possibile desktop remoto, trascinare tutti i file nella cartella di pubblicazione e semplicemente impostarlo per sovrascrivere (i nuovi file sostituiranno i vecchi file).

La pubblicazione metterà tutti i file necessari per l'applicazione in una cartella.

Il mio attuale datore di lavoro utilizza il fantoccio . (Qui ci sono altri pacchetti software che risolvono lo stesso problema.)

Il mio precedente datore di lavoro ha utilizzato un sistema di controllo dei lavori personalizzato per gestire la distribuzione del software, il riavvio, ecc. Anche se era disponibile, era un modo eccessivo per le tue esigenze.

Il datore di lavoro che avevo precedentemente aveva script personalizzati per copiare i dati da subversione ai server e fare un riavvio a rotazione.

Diversi posti che ho visto in precedenza avevano creato file per gestire la distribuzione. In genere hanno usato una strategia come tagliare metà dei server web dal bilanciamento del carico, attendere, arrestare quella metà, eseguire il codice, riavviarli, quindi lanciare il bilanciamento del carico, attendere, arrestare l'altra metà, riavviarli, quindi ripristinare il bilanciamento del carico up.

In tutti i luoghi in cui ho lavorato, il roll out del codice era un singolo comando o la mancanza di un singolo comando era riconosciuta come problema da risolvere.

In genere ciò che usiamo per risolvere questo problema con i nostri siti Web è uno strumento incluso con Sistemi Internals chiamato junction.

Usando questo strumento siamo in grado di creare collegamenti da una directory all'altra. La root dell'app sul server contiene 3 cartelle. Rosso, Blu, Corrente. IIS è configurato per guardare sempre Current per i suoi file.

Puoi impartire un comando junction current che ti dirà a quale cartella è attualmente puntata. Supponiamo ad esempio che al momento puntasse verso il blu. Quello che faremmo è accodare i file in rosso per la nuova distribuzione e accertarci che tutta la configurazione fosse pronta per andare.

Una volta che siamo pronti possiamo impartire il comando junction current red per farlo puntare.

Ci sono due cose che rendono questa soluzione così bella

1) Hai tutto il tempo del mondo per mettere in coda le tue modifiche nella cartella. Nessuna fretta e l'unico tempo di inattività è quando il pool di applicazioni si avvia. (C'è un modo per pre-compilare anche questo passaggio.)

2) Se qualcosa va storto con la tua implementazione, tutto quello che devi fare per eseguire il rollback è emettere un comando invece di provare a ripristinare le modifiche. Il comando nel nostro caso sarebbe junction current blue

Speriamo che il nostro modo di fare le cose possa gettare luce su una nuova soluzione per te.

Quello che ho fatto e non sono sicuro che tu abbia lo scopo per questo, ma qui va. Uno sviluppatore controllerebbe il codice in un ramo QA che sarebbe quindi caricato in un ambiente QA da un ingegnere di sistemi, una volta passato QA sarebbe promosso al ramo di produzione. C'erano almeno 2 di ogni sito collegato a un server su una bilancia di bilanciamento del carico pari e dispari in questo caso, uno dei due server verrebbe portato offline, verrà arrestato il sito verrà archiviato e il nuovo sito verrà distribuito insieme a qualsiasi modifica di iis richiesta verrà quindi riavviata e quindi si passerà al server successivo. Questo è stato tutto copiato usando C # nel nostro caso ma è stato fatto in passato usando lo script vb. Spero che aiuti. Saluti