Approccio migliore per l'aggiornamento del sito web dal vivo sul server

2

Seguo un approccio molto crudo mentre aggiorno il mio sito web sul server. L'approccio che seguo non sembra corretto, quindi sono interessato a conoscere un metodo consigliato per aggiornare un progetto LIVE , sia su un host condiviso che su un server dedicato.

Al momento, per eventuali modifiche in Visualizza, semplicemente carico e sovrascrivo i file di visualizzazione sul server. Allo stesso modo per eventuali modifiche al codice, carico e sovrascrivo i file .dll e .pdb. Attualmente il mio sito web non ha traffico quindi non ci sono stati problemi fino ad ora. Ma, questo è un approccio consigliato per un sito web con una buona quantità di traffico. E se no, allora come dovrebbe un approccio di aggiornamento sul server.

    
posta Pankaj Upadhyay 11.01.2012 - 12:19
fonte

2 risposte

6

Quello che molti siti ad alto traffico fanno è distribuire usando una web farm.

Il flusso di lavoro generale è simile a questo:

  • Prendi metà dei server dalla farm
  • Aggiorna questi server e prova
  • Rimetti i server nella farm e rimuovi i server rimanenti dalla farm
  • Aggiorna questi server e prova
  • Rimetti i server rimanenti nella farm

Se ciò non è possibile, suggerisco di creare due siti sul tuo server live - un sito attivo e un sito di distribuzione di applicazioni e directory web:

  • Distribuisci al sito di implementazione
  • Prova
  • Modifica la configurazione di IIS in questo modo:
    • Il sito live ora punta alla directory del sito di implementazione
    • Il sito di implementazione ora punta alla directory del sito precedentemente pubblicato
risposta data 11.01.2012 - 12:35
fonte
2

Dalla tua domanda sembra che tu abbia un solo server, che pone la domanda "Come collaudi le tue modifiche?"

Un flusso di lavoro migliore sarebbe quello di apportare le modifiche sul PC di sviluppo e caricarle prima su un server di test e quindi testare le modifiche lì. Questo "server di prova" non deve essere un server fisico; potrebbe essere una macchina virtuale sulla tua casella di sviluppo. Il punto è che i cambiamenti devono essere testati su una sorta di server web con il motore di database appropriato o qualunque sia il sito web richiesto. Idealmente avresti una sorta di regressione automatica e controllo dei link, ecc. Per assicurarti che le modifiche apportate non abbiano infranto nulla.

Una volta che ti senti felice con le tue modifiche, queste verranno spostate in un sito di gestione temporanea per il fatturato fino alla produzione. Il sito di staging dovrebbe essere il più vicino possibile al tuo ambiente di produzione. Inoltre, dovrebbe essere accessibile ai tuoi clienti e utenti in modo che possano esaminare e approvare le modifiche prima di essere messe in produzione.

Una volta che tutti hanno avuto una modifica per esaminare e approvare le modifiche sul sito di staging, il passaggio successivo è spostarle sul server di produzione. A seconda delle modifiche, ciò potrebbe essere semplice come copiare i file o potrebbe comportare modifiche dello schema alle tabelle del database ecc.

La chiave per spostare correttamente dal sito di staging al sito di produzione è assicurare: 1) Hai un backup completo del sito di produzione. 2) Avere un piano per annullare le modifiche (forse ripristinare i file di backup) se le tue modifiche causano un problema.

Per un sito ad alto volume o mission critical potresti avere più set di server di produzione con le modifiche spostate dalla gestione temporanea a metà dei server alla volta in modo che il sito Web non scenda mai. Per la maggior parte dei siti che pianificano 5 minuti di inattività nel bel mezzo della notte per eseguire il backup dei file e spostare le modifiche su un singolo server di produzione è probabilmente più che sufficiente.

    
risposta data 11.01.2012 - 12:55
fonte

Leggi altre domande sui tag