Come deve essere migrato lo schema del database?

0

Sto usando un gruppo di programmatori freelance per sviluppare un'applicazione web. Siamo nelle prime fasi di sviluppo, il che significa che stiamo apportando molte modifiche al nostro schema di database. Abbiamo un database di test e un database di produzione, abbiamo anche una replica del database live, che ottiene un clone del database live ogni notte (utilizzato principalmente per rendere più facile la creazione di bug trovati nell'applicazione web dal vivo. molti freelance, che non conosco, spesso non si fidano delle loro capacità di database e non hanno alcuna comprensione dell'importanza estrema dei dati nel nostro database live.

La mia domanda è quale tipo di processo consiglieresti dopo che un libero professionista determina la necessità di apportare modifiche in un database. Al momento, commetteranno modifiche al nostro schema di database insieme alla loro richiesta di pull (su GitHub), così posso rivedere le loro modifiche al database proposte. Sono anche liberi di applicare le modifiche al nostro database live. La mia domanda è quindi come dovrei migrare i dati in tempo reale al nuovo schema. Ho pensato di chiedere allo sviluppatore di una patch di creare anche un'istruzione alter table, che avrei eseguito sul database live, ma non mi fido che siano abbastanza prudenti. Preferisco che tale migrazione sia automatica (almeno nella maggior parte dei casi) per poter essere distribuita su base giornaliera, ma non so se sia del tutto realistico. Ho anche bisogno di un processo che mi fidi così tanto che non ho bisogno di fare test sul sistema live se ho testato una richiesta di pull sul nostro sistema di test (lavorando con il nostro database di test).

Come si può fare?

    
posta David 05.04.2014 - 12:32
fonte

3 risposte

1

Se non ti fidi degli sviluppatori, non vedo come puoi permetterli di apportare modifiche al database live.

Invitali a modificare il database dell'istantanea, esaminarlo e verificarlo, quindi applicare le modifiche al database di produzione.

Inoltre, potrebbe essere utile valutare se è possibile ridurre il numero di modifiche da apportare allo schema del database con una pianificazione leggermente migliore o anche se è davvero necessario distribuire quotidianamente sul sito attivo.

    
risposta data 05.04.2014 - 12:59
fonte
1

Sembra che tu possa beneficiare di una separazione tra architettura, progettazione del sistema, esperienza utente e ingegneria.

Gli architetti forniscono indicazioni generali per la soluzione tecnologica, ad esempio "useremo un servizio Web SOAP .NET qui" e "usiamo un'applicazione off the shelf per questo".

Il team di System Design prende la guida degli architetti e crea soluzioni tecnologiche concrete:

Crea un servizio web Prodotti:

  • WCF, .NET 4.5
  • Serve una tabella "prodotti" con le colonne x, y e z
  • L'autenticazione è gestita da Foo

Quindi coinvolgi User Experience per progettare l'interfaccia utente.

Infine, trasmetti tutte queste informazioni e progetti visivi agli ingegneri freelance non fidati che mettono le dita sulla tastiera e fanno in modo che ciò accada.

In questo modo, gli ingegneri non stanno prendendo decisioni progettuali e architettoniche --- il che non vuol dire che non dovrebbero essere autorizzati a prendere queste decisioni. Se un ingegnere presenta un problema che System Design o User Experience non hanno tenuto conto, è necessario parlare con lo sviluppatore principale (tu). Da lì dovrai afferrare lo sviluppatore e chattare con System Design o UX per estrarre la soluzione, che l'ingegnere implementa.

Potresti non avere persone singole per ogni ruolo. I negozi di software più piccoli probabilmente avranno persone che indossano più di un cappello (architetto, progettista di sistemi e lead developer potrebbero essere una sola persona), ma definire chiaramente quei ruoli e chi li riempie può aiutare a gestire una forza lavoro ingegneristica disgiunta.

    
risposta data 08.04.2014 - 22:51
fonte
0

Esistono Creazione guidata Database di applicazioni che potrebbero probabilmente aiutarti ad automatizzare il processo; Tuttavia, il processo generale di aggiornamento del database dovrebbe essere come questo:

Per prima cosa è necessario uno script Upgrade , in cui è possibile aggiornare in modo sicuro il database Schema e Data dalla versione 2.8.13 alla 2.8.14 , per esempio.

Lo script dovrebbe essere totalmente SQL - idealmente, e dovrebbe accuratamente selezionare i dati esistenti nel database, creare una nuova tabella o modificare quelli esistenti, Modifica i dati esistenti per adattarsi ai nuovi tipi di colonna, ecc. se necessario, quindi Inserisci i dati nella nuova tabella.

Quindi, ovviamente, creare un back-up / snapshot del database è indispensabile prima di applicare qualsiasi modifica sul server di produzione.

Questo dovrebbe rendere gli aggiornamenti sul server di produzione molto più semplici, se aggiorni costantemente il database e non elimini nessuno degli script di aggiornamento, altrimenti l'aggiornamento da 2.8.13 a 2.9.3 potrebbe essere un po 'più di lavoro. Lo script di aggiornamento potrebbe essere scritto manualmente dagli sviluppatori / DBA o essere uno script generato automaticamente tramite uno strumento di terze parti. In entrambi i casi è necessario verificarlo manualmente per assicurarsi che non si rompa nulla e applicarlo sull'ambiente Staging prima del database Production effettivo.

Nota: probabilmente la versione del tuo database non corrisponderà alla versione dell'applicazione. Quindi non è necessario avere uno script di aggiornamento basato sulla versione dell'applicazione. Ne hai bisogno solo quando lo schema del database è stato modificato.

    
risposta data 05.04.2014 - 13:38
fonte

Leggi altre domande sui tag