Penso che ci siano due parti in questo problema.
Il primo è la gestione dello schema del database e le sue modifiche. Lo facciamo utilizzando South, mantenendo sia i modelli di lavoro che i file di migrazione nel nostro repository SCM. Per sicurezza (o paranoia), eseguiamo un dump del database prima (e se siamo davvero spaventati, dopo) eseguire qualsiasi migrazione. Finora il sud è stato adeguato a tutte le nostre esigenze.
Il secondo è la distribuzione della modifica dello schema che va oltre la semplice esecuzione del file di migrazione generato da South. Nella mia esperienza, una modifica al database richiede normalmente una modifica al codice distribuito. Se si dispone anche di una piccola Web farm, mantenere il codice distribuito sincronizzato con la versione corrente dello schema del database potrebbe non essere banale:ciò peggiora se si considerano i diversi livelli di memorizzazione nella cache e l'effetto su un utente del sito già attivo. Siti diversi gestiscono questo problema in modo diverso e non credo che ci sia una risposta valida per tutti.
Risolvere la seconda parte di questo problema non è necessariamente semplice. Non credo che ci sia un approccio valido per tutti e non ci siano abbastanza informazioni sul tuo sito Web e sull'ambiente per suggerire una soluzione che sarebbe più adatta alla tua situazione. Tuttavia, penso che ci siano alcune considerazioni che possono essere tenute a mente per aiutare a guidare l'implementazione nella maggior parte delle situazioni.
Portare offline l'intero sito (server Web e database) è un'opzione in alcuni casi. È sicuramente il modo più semplice per gestire gli aggiornamenti. Tuttavia, frequenti tempi di inattività (anche se pianificati) possono essere un buon modo per svolgere rapidamente la nostra attività, rendere noioso l'implementazione anche di piccole modifiche al codice e potrebbero richiedere molte ore se si dispone di un set di dati di grandi dimensioni e/o di una migrazione complessa. Detto questo, per i siti che aiuto a gestire (che sono tutti interni e generalmente utilizzati solo durante l'orario di lavoro nei giorni lavorativi) questo approccio funziona a meraviglia.
Fai attenzione se apporti le modifiche su una copia del database principale. Il problema principale qui è che il tuo sito è ancora attivo e presumibilmente accetta scritture nel database. Cosa succede ai dati scritti nel database master mentre sei impegnato a migrare il clone per un uso successivo? Il tuo sito deve essere inattivo per tutto il tempo o metterlo temporaneamente in uno stato di sola lettura, altrimenti lo perderai.
Se le tue modifiche sono compatibili con le versioni precedenti e hai una web farm, a volte puoi farla franca aggiornando il server del database di produzione live (che penso sia inevitabile nella maggior parte delle situazioni) e quindi aggiornando in modo incrementale i nodi nella farm rimuovendoli dal bilanciamento del carico per un breve periodo. Questo può funzionare bene, tuttavia il problema principale qui è se un nodo che è già stato aggiornato invia una richiesta per un URL che non è supportato da un nodo precedente, otterrai un errore poiché non puoi gestirlo a livello di bilanciamento del carico.
Ho visto/sentito un paio di altri modi che funzionano bene.
Il primo consiste nel racchiudere tutte le modifiche al codice in un blocco delle funzionalità che è quindi configurabile in fase di esecuzione tramite alcune opzioni di configurazione a livello di sito. Ciò significa essenzialmente che puoi rilasciare il codice in cui tutte le modifiche sono disattivate e quindi, dopo aver apportato tutti gli aggiornamenti necessari ai tuoi server, modificare l'opzione di configurazione per abilitare la funzione. Ma questo rende il codice piuttosto pesante...
Il secondo è lasciare che il codice gestisca la migrazione. Ho sentito parlare di siti in cui le modifiche al codice sono scritte in modo tale da gestire la migrazione in fase di esecuzione. È in grado di rilevare la versione dello schema in uso e il formato dei dati recuperati - se i dati provengono dal vecchio schema esegue la migrazione sul posto, se i dati provengono già dal nuovo schema non fa nulla . Dall'utilizzo naturale del sito, una parte elevata dei tuoi dati verrà migrata dalle persone che utilizzano il sito, il resto lo puoi fare con uno script di migrazione quando vuoi.
Ma penso che a questo punto Google diventi tuo amico, perché, come ho detto, la soluzione è molto specifica per il contesto e sono preoccupato che questa risposta inizi a diventare priva di significato ... Cerca qualcosa come "implementazione zero tempi di inattività" e tu ' Otterrai risultati come questo con tante idee...
