Come gestite le dimensioni del database in costante cambiamento?

9

Negli ultimi due mesi ho cercato soluzioni o pratiche per gestire la gestione dei rilasci all'interno dei database. Sto cercando quello che la gente considera il processo migliore per gestirlo.

Abbiamo 3 ambienti per i nostri database:

Sviluppo
Test di accettazione dell'utente (UAT)
Produzione

Il problema è che a volte stiamo apportando modifiche a diverse cose all'interno del nostro database di sviluppo e che è giunto il momento di distribuirlo, alcune delle funzionalità potrebbero non essere pronte per essere rilasciate a UAT.

Di recente abbiamo iniziato a utilizzare il controllo del codice sorgente Red Gate SQL per l'archiviazione di tutte le nostre entità (con commit regolari).

Stavo pensando di basarmi sui changeset (ovvero dire che tutto, dal changeset X e viceversa, viene ora trasferito a UAT), ciò significa che le persone controllano il loro codice nel controllo del codice sorgente appena prima di effettuare una distribuzione che può creare confusione ( soprattutto perché le persone sono smemorate). Un altro problema derivante dall'approccio con il changeset è se c'è un bug in una procedura memorizzata che deve essere riparato, il numero del changeset finirà per essere fuori dall'ambito del nostro changeset massimo per la revisione, quindi rendendolo così che se dobbiamo ricreare il database da un massimo changeset, elimineremo nuovamente il bug.

Qualche suggerimento su un processo?

Grazie

— judda
fonte

Sembra che gli script del tuo database non siano nello stesso controllo del codice sorgente del tuo codice "reale". Perchè è questo? Riesci a trattarlo come "codice sorgente" e metterlo con i singoli rami?

— Mike M.

Al momento archiviamo solo la versione di sviluppo degli script nel controllo del codice sorgente e UAT / Production entrambi non sincronizzati con lo sviluppo attivo. Ciascuno degli script nel controllo del codice sorgente viene aggiornato ogni volta che uno sviluppatore esegue un commit. Il problema con i singoli rami è che abbiamo 1 database centralizzato che tutti usano (per grandi cambiamenti ramifichiamo i database separati).

1

È possibile creare un ramo per la versione e solo impegnare le modifiche relative alla versione. Tutte le altre modifiche devono essere apportate al trunk. Per raggiungere questo obiettivo sono necessari due database di sviluppo. questo sarebbe un problema?

Sembra che uno probabilmente si esaurirà abbastanza rapidamente. No? Per uno dei miei progetti siamo nel bel mezzo di una massiccia revisione del database, quindi l'abbiamo ramificato in modo tale che lo sviluppo attivo possa ancora avvenire nella versione non modificata del database. Tuttavia, ogni giorno vedo che la nostra versione ramificata sta diventando sempre più obsoleta e non sono sicuro che sia ok o no ... Non ho mai avuto a che fare con situazioni come questa prima.

— judda,

5

migrazioni

Un su e un giù, che sono nel tuo repository e taggati insieme alla tua app.

Puoi persino fare il fai-da-te con flatfile sql che modificano il tuo schema e aggiornano la versione dello schema. Tutto quello che devi fare è:

mantieni le tue migrazioni vicino al codice sorgente, dovrebbero essere versionate e taggate insieme
utilizzare sempre le modifiche gestite (migrazioni) in tutti gli ambienti
non consentire mai modifiche ad hoc in nessun ambiente

Bene, puoi fare cambiamenti di sviluppo in sviluppo, ma dovresti sempre spazzare via il tuo db e ricostruirlo con le migrazioni dopo aver acquisito il cambiamento.

— dietbuddha
fonte

Cosa succederebbe se negli script fosse trovato un bug? Torna allo script sql e lo aggiorni?

— judda

1

No, crei una nuova migrazione (che aumenta la versione dello schema). Ecco come sai che la correzione è stata distribuita, guardando la versione dello schema nel database.

— dietbuddha,

Grazie per l'aiuto. A prima vista questo sembra essere un approccio molto solido e simile alla nostra strategia di ramificazione.

— judda

2

Controllo della fonte!

Non distribuisci i tuoi binari di sviluppo direttamente alla produzione senza passare tramite svn / git / p4, quindi perché i tuoi soli database dovrebbero farlo? Ottieni istanze private per gli sviluppatori per testare le loro modifiche locali, ma quando deve andare al db di sviluppo, deve passare attraverso i file ddl registrati. Puoi anche scrivere strumenti per applicare automaticamente queste modifiche ddl (non conosco alcun modo esistente per farlo correttamente).

Una volta che hai posto in atto le restrizioni sulle modifiche allo schema di db (Non più sqlplus -> issue ddl!) E hai un controllo rigoroso dell'account (nessun accesso ddl a tutti), questo dovrebbe diventare più gestibile.

— Subu Sankara Subramanian
fonte

1

Purtroppo i nostri database sono troppo grandi per essere passati tra gli sviluppatori per far funzionare le sessioni private. Inoltre, non sembra propendere per uno sviluppo più basato sul team, perché in questo momento faccio lo sviluppo del back-end mentre parlo con le persone per il lavoro dell'interfaccia utente che collega i due. Avrei bisogno di iniziare controllando tutte le modifiche e poi ottenendole per ottenere le ultime novità sul database, che sembra essere una seccatura piuttosto grande.

— judda,

Perché il tuo db di sviluppo deve avere le stesse dimensioni del db di produzione? Possono avere lo stesso schema e puoi anche avere una flotta di test di carico speciale con tutti i dati, ma i database degli sviluppatori locali potrebbero essere piccoli. Ciò previene anche i problemi di perdita di dati, ecc. - In teoria, i dati di produzione non dovrebbero assolutamente colpire lo sviluppo.

— Subu Sankara Subramanian,

Tutti i nostri dati vengono caricati attraverso il nostro processo di caricamento dei dati che elabora i file forniti dal client e li trasforma in dati di cui abbiamo bisogno. Quindi è impossibile per noi separare i dati di sviluppo e sviluppo dato che tutti i carichi di dati devono comunque essere verificati nello sviluppo. Immagino che non abbia bisogno della stessa dimensione, tuttavia ha bisogno di quantità comparabili di dati affinché i report che creiamo per generare informazioni significative.

— judda,

Non è necessario replicare l'intero DB. In Oracle ogni utente ha il proprio schema e noi abbiamo uno schema di applicazione. Crea sinonimi pubblici per tutti gli oggetti nello schema dell'applicazione. Quindi ogni utente può modificare gli oggetti (tabelle, SP) nel proprio schema e se si connettono come se stessi verranno utilizzati i nomi degli oggetti. Per gli oggetti che non sono presenti nello schema, verranno utilizzati i sinonimi. Ecco come lavoriamo.

— softveda,

0

Seguendo il suggerimento di usare le migrazioni ... forse usare un O / RM che supporti le migrazioni come Ruby on Rails e Entity Framework 4.3 Il problema con entrambi gli approcci è che una migrazione è totale o nulla. Non puoi (di solito) selezionare quali migrazioni vengono applicate come puoi in termini di set di modifiche.

Un'altra opzione praticabile (se sei nello stack di Microsoft, non hai mai menzionato la piattaforma) è gestire il tuo SQL con gli strumenti del database di Visual Studio. Ha incorporato il refactoring (rinomina / rimuovi colonne, ecc.) Ed esegue la verifica del modello. Se, ad esempio, un proc memorizzato fa riferimento a una colonna che non c'è più, ti informerà.

— Michael Brown
fonte