Vecchie versioni che ritornano

Succede che si crei una cartella new nel server per ospitare la nuova versione del sito. Si copiano i file e si fanno le prove per vedere che il tutto funzioni correttamente.

Succede poi che si modifichi il file index nella cartella principale del server in modo che ridiriga alla cartella new. A questo punto tutti i visitatori possono apprezzare la nuova versione.

Succede che ci si dimentichi a questo punto di cancellare i vecchi file e le vecchie cartelle perché, tanto, non le vede più nessuno.

Succede che qualcuno cerchi il sito con Google e capiti nella vecchia versione invece che in quella “new”.

Succede, per esempio, con il sito della cittadina di Anghiari. Il primo risultato restituito da Google fino a oggi è la vecchia versione in inglese.

Succede per tanti, tantissimi altri siti.

100 milioni di Internet Explorer 7

Intervento pieno di emozione quello di Tony Chor sul blog di Internet Explorer 7, in cui dà notizia del cento milionesimo download di Internet Explorer 7 in poche settimane.

Mi chiedo però se sia il caso di gioire di un evento forse facilmente prevedibile, visto che IE 7 viene praticamente distribuito che le stesse modalità di un aggiornamento critico di Windows.

Quanti utenti spenderanno tempo per capire di cosa si tratta o si limiteranno invece a cliccare lo scudo giallo in basso a destra che informa della disponibilità di aggiornamenti? A quel punto il più è fatto: molti procederanno, soprattutto perché la schermata di installazione punta il dito sulle enormi migliorie in campo di sicurezza.

L’intervento merita però di essere letto anche per i commenti a volte sorprendentemente ironici e divertenti.

Migrare un sito alla nuova versione

Uno degli aspetti solitamente trascurati quando ci si trova a riprogettare un sito web dinamico è la stesura di un “piano” di migrazione, cioè la definizione di una serie di linee guida che portino la nuova versione del sito in sostituzione della precedente.

Solitamente si pensa che sia sufficiente sovrascrivere la vecchia versione, il motore CMS, le parti di codice, i template, il tutto senza tanti complimenti.

Seguire questo modo di procedere ha in realtà diversi aspetti negativi.

Per prima cosa, in caso di problemi, così facendo è molto difficile poter tornare alla versione precedente del sito, soprattutto se il sito ha un buon bacino di pubblico.

E’ bene accertarsi se il sito sia installato su più server bilanciati e compiere l’operazione prima su una delle macchine, testare il sito con una piccola percentuale di utenza, e poi ripetere la stessa operazione sugli altri server.

Ma la migrazione di un sito va pensata già in fase di progetto. Spesso ci si dimentica che una buona percentuale del traffico di un sito proviene dai motori di ricerca, e nel convertire contenuti e parte di codice alla nuova versione non vengono mantenuti gli stessi URL della versione precedente. Vi accorgerete presto di questa dimenticanza quando, analizzando il traffico del sito, noterete un crollo degli accessi. In un precedente intervento abbiamo visto come sia possibile evitare che questo succeda, presentando gli accorgimenti usati durante la migrazione di Fucinaweb.

In base al traffico e all’importanza del sito, la messa online potrebbe essere suddivisa in più passi incrementali. In questo fanno scuola i grandi, Google per primo. Nel rilasciare la nuova versione di Blogger, gli ingegneri di Google si sono preoccupati di limitare i traumi per chi gestisce il proprio weblog con la nuova piattaforma. Per prima cosa, ancora ad Agosto, hanno annunciato il rilascio del nuovo servizio, limitando gli inviti e integrando il login di Google Accounts (quella della registrazione, abbiamo visto qualche mese fa, è una delle operazioni più delicate da integrare). Nel corso delle settimane l’integrazione tra il vecchio servizio e il nuovo è via via aumentata, così come le nuove funzionalità: la beta è stata aggiornata, sono state migrate alcune importanti funzioni della vecchia versione, è stata migliorata la funzione di login, e via via, fino ad arrivare a Novembre, dove la migrazione è in stato avazato e non ancora conlusa.

Non dico che per i nostri progetti web dobbiamo prevedere mesi e mesi di migrazione, ma ricordate di non ragionare mai come se il sito dinamico attuale vada in completa sostituzione del precedente, come nello sovrascrivere un file. La procedura di aggiornamento va studiata caso per caso, e visto che partecipa ad aumentare i tempi di rilascio, va attentamente pianificata.