Come aggiornare in modo sicuro un sito web in diretta

Question

Abbiamo un sito web basato su Django abbastanza semplice per eseguire operazioni CRUD. Ho eseguito test e sviluppo localmente e poi ho controllato le versioni e le modifiche dello schema del database sul server live una volta terminato il test. Di recente abbiamo riscontrato un problema durante il rilascio di alcuni tipi di modifiche. Immaginate la seguente sequenza di eventi:

1. utente apre un modulo web
2. sito viene aggiornato per richiedere nuovo campo in questo modulo
3. utente invia il modulo che hanno lavorato su
4. Server restituisce un errore perché si aspettava di ricevere il nuovo campo aggiunto al passaggio 2

In che modo altri siti gestiscono questo tipo di problemi? Le mie idee:

• Portare il sito offline durante gli aggiornamenti. Questo non risolve il problema, perché un utente può avere un modulo Web aperto per un periodo di tempo infinito prima di inviarlo, ma dopo un certo periodo di tempo è improbabile che qualcuno possa inviare il modulo.
• Fare aggiornamenti automatici a tempi di traffico molto bassi. Ancora una volta questo non risolve il problema, ma il nostro sito non è così popolare e se avessimo fatto un aggiornamento a 3: 00a dubito che ci sarebbero stati molti utenti. Una preoccupazione con questa tecnica sono gli aggiornamenti automatici che non riescono.
• Moduli di versione in modo che il server riconosca che un modulo precedente è stato inviato e fornisce una risposta più user-friendly. Esistono strumenti automatici che potrebbero aiutare con questo?

Pensieri?

Answer 1

Non riesco a vedere come è possibile ottenere questo risultato senza codificare nella convalida la possibilità che si sia verificato un aggiornamento. per esempio. "anticipando" che i campi potrebbero essere cambiati durante l'invio e impostare i valori di default/rifiutare di conseguenza.

Per quanto riguarda l'invio "ridimensionamento" del contenuto come una finestra di manutenzione si avvicina, per ridurre al minimo gli utenti interessati a coloro che hanno lasciato i loro browser aperti?

Answer 2

Se è davvero un grosso problema, è possibile includere la versione del codice come una sorta di variabile nascosta in ciascuna delle vostre forme. Se la versione inviata non corrisponde alla versione correntemente in esecuzione dell'applicazione, è possibile visualizzare un errore corretto e indurli a compilare tutti i nuovi campi che potrebbero esistere nel modulo. Potresti anche andare un po 'oltre e visualizzare solo i messaggi per i quali il modulo è cambiato. È possibile creare una sorta di hash basato sulla definizione del modulo e utilizzarlo come campo nascosto. Se l'hash è sbagliato, sai che stanno inviando un modulo errato.

Answer 3

Le modifiche a un'API pubblicata (o UI, in questo caso) sono sempre complicate. Se possibile, preserva la retrocompatibilità. Per la maggior parte delle forme, direi che la funzionalità non cambierà tra le versioni. Potresti aggiungere o rimuovere un campo o due, ma questo sarebbe gestito dalla convalida del modulo sul back-end. Questo è essenzialmente ciò che stai descrivendo nel tuo passo 4. Non considero davvero un grosso problema; Gli errori di runtime si verificano di volta in volta - Finché la tua applicazione lo gestisce con garbo e informa l'utente del problema, allora nessun problema in realtà.

Answer 4

Ci sono molti siti che uso (concessi, per lo più interni al mio posto di lavoro) che annunciano qualcosa come "Saremo giù per manutenzione il prossimo fine settimana dalle 18:00 Sabato alle 6:00 Domenica mattina Si prega di pianificare di essere fuori dal sistema in quel momento. " Anche se non è perfetto, niente è, e questo sembra un buon approccio. Basta ritagliare un sacco di tempo per mettere fuori la roba nuova, provarla e tornare al vecchio se necessario. Se ritieni che sia necessario, puoi sempre impostare una semplice pagina che dice "Scusa, non siamo disponibili ora" e indirizzare le persone a questo durante il periodo di inattività. Generalmente nessuno si lamenterà se non hai bisogno di tutto il tempo che hai originariamente dichiarato e sei tornato presto (forse gli scansafatiche che vogliono una scusa per evitare il lavoro sarebbe l'eccezione, ma probabilmente non funzionano comunque).

Answer 5

Il modo "corretto" per farlo è di avere viste ben definite che gestiscono con garbo questa intera classe di insuccessi. Nel caso di aggiungere un nuovo campo al tuo modello che è richiesto (presumo che sia ciò che sta accadendo), la vista dovrebbe occuparsi di ciò con un'eccezione ValidationError che genera un messaggio di errore amichevole e rimanda l'utente al form (che , quando ricaricato, dovrebbe avere il nuovo campo disponibile). Indipendentemente dai campi aggiunti al modello, l'eccezione genera un errore pulito e restituisce l'utente.