Gestione di un database di sviluppo in un progetto di gruppo

3

Lavoro per una piccola società di sviluppo web e vogliamo creare ambienti di sviluppo. Useremo il framework Laravel in combinazione con Homestead. Ora Homestead dispone di un proprio database e può lavorare con le migrazioni di Laravel, il che significa che qualsiasi modifica al database esistente da versioni precedenti può essere aggiornata con un singolo comando di terminale. La più grande truffa alle migrazioni di Laravel è che tutti i dati precedentemente memorizzati nel database andranno persi per ogni migrazione, il che significa che dovrai riempirlo di nuovo.

Come puoi immaginare, non vogliamo continuare a ricaricare il nostro database ogni volta che cambiamo qualcosa. Quindi abbiamo pensato di ospitare un singolo database di sviluppo, ma anche questo comporta degli svantaggi. Qualcuno nel nostro progetto potrebbe cambiare qualcosa nel database, il che significa che tutti gli altri nel nostro progetto potrebbero avere il loro codice non funzionante nel loro ambiente di sviluppo locale, a causa del cambio del database.

Abbiamo un solido design di database, ma sono solo preoccupato che qualcosa possa ancora andare storto durante lo sviluppo. Come potremmo continuare a gestire correttamente il nostro database di sviluppo senza perdita di dati e senza problemi quando qualcosa cambia?

    
posta Audite Marlow 18.03.2016 - 09:33
fonte

1 risposta

2

Non sono un esperto Laravel, ma il problema che descrivi non è molto speciale per quel framework. Hai diverse istanze di un database e devi assicurarti che le modifiche dello schema debbano essere applicate, cioè

  • tutte le istanze di database ottengono gli stessi aggiornamenti dello schema

  • i dati esistenti non vengono persi e, se necessario, verrà eseguita la migrazione alla nuova versione dello schema

(se quello è un db di produzione, un db di test o un db di sviluppo non ha molta importanza).

Sembra che tu abbia l'impressione che Laraval indirizzi solo il primo punto, ma penso che non sia corretto, vedi sotto.

La soluzione standard a questi problemi è la scrittura di script SQL con gli aggiornamenti dello schema e le migrazioni dei dati per ogni passaggio e mantenendo tali script nel codice! Non (!) gli aggiornamenti dello schema di "strumenti come PHPMyAdmin", come hai scritto nel tuo commento, che non diventeranno riproducibili. Questi script SQL devono essere incorporati in una sorta di linguaggio o framework host, in modo da renderli affidabili contro l'esecuzione fuori sequenza, l'esecuzione ripetuta o la gestione degli errori. Ed è qui che entrano in gioco strumenti come Laravel.

Con una breve ricerca web, ho trovato questo vecchio post SO dove è dimostrato come le migrazioni di Laravel può essere utilizzato anche per migrare i dati. Quindi la tua premessa iniziale sembra essere sbagliata, si possono scrivere migrazioni che effettivamente mantengono i dati esistenti o trasformano i dati. Naturalmente, si deve fare attenzione quando si scrivono le migrazioni, non eliminando accidentalmente una colonna con i dati (ma ciò non è diverso con qualsiasi altro tipo di SQL scritto a mano o lingua host).

Inoltre, devi stare attento con l'uso dei rollback dello schema. Ad esempio, quando aggiungi una nuova colonna, potrebbe essere possibile non annullare facilmente la modifica dello schema dopo aver aggiunto alcuni dati a quella colonna e alcuni dati di riferimento altrove nel db.

Quindi, se si desidera utilizzare le migrazioni di Laravel, eseguire questa operazione, ma con attenzione. Raccomando di testare l'intera sequenza di migrazioni ogni volta che ne aggiungi uno su un piccolo database di backup prima di distribuire le modifiche all'intero team. Inoltre, assicurati che tutti i tuoi database che contengono dati che non puoi ottenere facilmente altrove, siano inclusi nei tuoi backup giornalieri.

    
risposta data 20.03.2016 - 18:27
fonte

Leggi altre domande sui tag