La paura di aggiornare
Venerdì 13 Luglio 2007 - 11:11
di Antonio Volpon
Cioè, la paura di aggiornare un sito alla nuova versione che avete appena finito di sviluppare. Non so voi, ma io ogni volta che mi trovo a dover sostituire un sito di una certa complessità avverto sempre qualche sintomo di disagio.
Cerco di cautelarmi in tutti i modi
- con un software per la gestione delle versioni, come subversion
- con un un backup di cartelle e database
- con una replica veritiera dell’ambiente di produzione
- con dei test di carico
- con una serie infinita di test che impiegano anche i colleghi
- con una pagina di cortesia che mi permette di lavorare in tranquillità
Quasi sempre va tutto bene, ma ricordo ancora quella volta in cui il sito (con molto, molto traffico) è crollato dopo quaranta secondi che l’avevamo messo online o altre esperienze a caccia di bug fino a notte tarda.
Le cause sono molte: distrazione, l’impossibilità di lavorare su dati “reali”, la fretta di consegnare, e così via.
Posso chiedervi la vostra strategia per mettere online un sito di una certa complessità? Sono molto curioso.
Categoria: PHP e Open Source | Permalink
Commenti
1
io personalmente lavoro su una copia dell’originale su un dominio di terzo livello col nome di ‘demo’ o ‘test’. Così ho tutta la tranquillità di questo mondo e al contempo non rischio danni al sito originale e basta uno switch sul httpd.conf tra le due cartelle di lavoro ed un restart di apache ( o anche di IIS ) che il sito è in piedi con la copia preservata… dovessero esserci problemi, basta rifare lo switch inverso… voi come fate?
2
Io uso la stessa tecnica di Paolo,
in più quando è possibile apro le porte per in periodo di prova alla versione “beta” del nuovo progetto, invitando gli utenti a visitare anche la nuova versione del sito, in questo modo raccolgo in genere abbastanza feedback e controllo se il tutto funziona in modo coretto anche in situazioni più simili a quelle reali.
Però non sempre è possibile farlo, dipende tanto da che tipo di sito si va ad aggiornare# - postato da Nico - 13 Luglio 2007 - 12:07
3
Scusa ma subversion cosa serve nel dettaglio? Forse potrebbe interessarmi ma non ho molta dimestichezza con l’inglese del sito.
4
La soluzione di Paolo in effetti mi pare quella più corretta, che ti permette di effettuare i test direttamente campo.
Noi per un progetto abbiamo sul server la versione in produzione ed una versione duplicata (con aggiornamento del database on-demand) che ci permette di effettuare test/debug/update senza dover utilizzare courtesy-page e senza blocchi per gli utenti (se non proprio quando sono necessari interventi veramente corposi)# - postato da alessandrobondi - 13 Luglio 2007 - 12:14
5
@sole
http://www.simonecarletti.com/.....on-svn.php@Antonio
Ottimo post, mi sa che quasi quasi ci scrivo due righe.
In breve, nel tempo ho sviluppato una complessa todo list per verificare questo passo.Normalmente procedo come segue
1. procedo con il test della versione finale normalmente preparando un ambiente il più possibile simile
2. se devo cambiare anche server, colgo la palla al balzo e configuro tutto sul nuovo server.
Poi cambiando il file host sul mio PC setto i DNS al nuovo server così sono sicuro di eseguire le pagine allo stesso modo in cui verranno eseguite quando avrò online il nuovo sito.3. eseguo una serie di test. tra i più comuni uso il programma XENU per verificare tutte le URL e la presenza di eventuali errori (5xx o 4xx) nel sito.
4. stresso il server con qualche richiesta o elaborazione pesante.
5. In alcuni (rari) casi ho adottato una tecnica molto casa a Google.
Randomicamente setto un cookie ed offro ad un utente la nuova interfaccia monitorandolo da vicino al fine di “usare” lui come debugger.6. poi procedo alla migrazione.
Se si tratta di un nuovo server è banale, basta un cambio DNS e poi un backup del vecchio a migrazione ultimata.In alternativa backuppo tutto il possibile.
Zip/Tar completo della cartella sul server e di tutti i file.7. Sia per il database sia per l’host normalmente tendo a non “sovrascrivere” ma affiancare instradando l’utente verso la nuyova versione (configurazioni IIS/Apache piuttosto che virtual host).
Quando sono certo che tutto funziona a dovere backuppo e chiudo.8. Se qualcosa va storto semplicemenre rimuovo il reindirizzamento dell’utente e lo riporto alla configurazione stabile.
# - postato da Simone Carletti - 13 Luglio 2007 - 12:45
6
Lavoro sempre sulla copia locale del sito e dopo aver testato le modifiche procedo con l’upload sul server per mettere tutto in funzione. La versione che ho sul server è la precedente quindi mi risparmio di fare dei backup della versione locale ongi volta che devo fare delle modifiche.
# - postato da Luca - 13 Luglio 2007 - 21:50
7
Come Luca…
Comunque sbagliano anche i grandi durante gli aggiornamenti: Il codice di Yahoo!.
8
da questo punto di vista che rails è superlativo: 3 ambienti: development, test e production. Nessun errore ;)