I file di database (script ecc.) Devono essere nel controllo del codice sorgente? In tal caso, qual è il metodo migliore per mantenerlo e aggiornarlo lì?

Esiste persino la necessità che i file di database siano nel controllo del codice sorgente in quanto possiamo metterli su un server di sviluppo in cui tutti possono utilizzarli e apportare modifiche se necessario. Ma allora non possiamo riaverlo se qualcuno lo incasina.

Quale approccio è meglio utilizzato per i database sul controllo del codice sorgente?

Sì. Dovresti essere in grado di ricostruire qualsiasi parte del tuo sistema dal controllo del codice sorgente incluso il database (e direi anche alcuni dati statici).

Supponendo che non si desidera disporre di uno strumento per farlo, suggerirei di voler includere quanto segue:

• Script di creazione per le strutture di tabella di base tra cui schemi, utenti, tabelle, chiavi, valori predefiniti e così via.
• Aggiorna gli script (modificando la struttura della tabella o migrando i dati da uno schema precedente al nuovo schema)
• Script di creazione per stored procedure, indici, viste, trigger (non è necessario preoccuparsi dell'aggiornamento per questi poiché si sovrascrive ciò che era lì con lo script di creazione corretto)
• Script di creazione dei dati per far funzionare il sistema (un singolo utente, tutti i dati dell'elenco di selezione statici, quel genere di cose)

Tutti gli script devono includere le istruzioni di rilascio appropriate ed essere scritti in modo che possano essere eseguiti come qualsiasi utente (inclusi quindi i prefissi di schema / proprietario associati, se pertinenti).

Il processo di aggiornamento / tagging / branching dovrebbe essere esattamente come il resto del codice sorgente: non ha senso farlo se non è possibile associare una versione del database a una versione dell'applicazione.

Per inciso, quando dici che le persone possono semplicemente aggiornare il server di prova, spero che tu intenda il server di sviluppo. Se gli sviluppatori stanno aggiornando il server di test al volo, allora stai osservando un mondo di dolore quando si tratta di capire cosa è necessario rilasciare.

Sì.

qual è il metodo migliore per tenerlo e aggiornarlo lì?

Um. Scrivi uno script per la creazione di schemi. Effettua il check-in dopo aver apportato modifiche. Dai un'occhiata prima di eseguirlo.

È difficile determinare cosa stai chiedendo.

Scrivere script di migrazione dello schema formale. Controllali dopo il test. Controllali prima di eseguirli.

Cosa c'è di più?

Quello che succede è che le modifiche allo schema si trasformano in problemi nodosi perché lo schema si evolve organicamente attraverso una serie di modifiche non documentate.

Questa evoluzione organica rende più difficile la migrazione degli schemi perché non esiste una fonte "autorevole" per ciò che dovrebbe essere lì. Esistono due versioni di produzione leggermente diverse, una versione temporanea, una versione QA e otto versioni di sviluppo. Tutti leggermente diversi.

Se esisteva un'unica fonte autorevole, la migrazione dello schema è solo il delta tra l'ultima versione e questa versione.

sì

Gli script del database (ddl, dml) sono codici. Tutto il codice dovrebbe essere in un sistema di controllo della versione.

migrazioni

• Usa migrazioni di database

Consente di utilizzare gli stessi file db in sviluppo, qa e versioni.

• Rilascio nel database con un numero di rilascio

Conservare il numero di rilascio da qualche parte per il controllo, molti lo memorizzano nel db stesso. Ogni versione sarà composta da migrazioni che porteranno il database alla versione corretta.

Esistono strumenti come la liquibase che hanno lo scopo di fornire il controllo del codice sorgente per i database. Gestire gli script di modifica / aggiornamento nel normale strumento di controllo del codice sorgente è complicato, come fanno molte aziende e non è sempre possibile ridistribuire il database da zero.

Abbiamo anche cercato di automatizzare questo con strumenti di confronto di database (confronta master e cliente db) e questo ci ha aiutato, ma non puoi fidarti di tali strumenti al 100%, sicuramente hai bisogno anche di un processo di revisione.

sì

Inoltre, vorrai rami .

Uso Git per i rami:

• per sviluppo per funzionalità (come facciamo per lo sviluppo regolare del resto dell'applicazione)

• e uno anche per il server di produzione perché anche i clienti che utilizzano l'applicazione creano contenuti.

In questo modo, si ottengono i vantaggi del controllo e della diramazione del codice sorgente sia per il codice sorgente che per il database (e qualunque altro file si disponga).

Non ho ancora trovato un sistema all-in-one [per PostgreSQL], quindi ho dovuto scrivere funzioni / script per reindicizzare correttamente quando si uniscono i rami (ad esempio qualsiasi indice dal ramo di produzione non dovrebbe essere modificato perché i clienti si affidano a loro mentre gli indici + le chiavi esterne del ramo di sviluppo che si intersecano con i contenuti di produzione dovrebbero essere reindicizzati: non funzionerebbe per tutte le applicazioni, ma copre tutti i casi della nostra applicazione, quindi è abbastanza buono).

Ma l'idea generale è che i contenuti del database sono una parte essenziale dell'applicazione e tutte le risorse dovrebbero essere nel controllo del codice sorgente , quindi sì, dovresti usare anche il controllo del codice sorgente per il database.

Per Java, il nostro team utilizza Flyway , che troviamo davvero facile da usare e potente.

Se lavori in Ruby, Rails ha migrazioni che sono anche un modo efficace per affrontare questo problema.

La Liquibase è già stata menzionata: è una buona soluzione ma l'ho trovata più ingombrante rispetto alle alternative come Flyway.

Inoltre, il software RedGate offre un prodotto chiamato SQL Source Control progettato per SQL Server. Non l'ho usato da solo, ma uno dei miei colleghi dice che è fantastico.

Ecco il problema che ho riscontrato molte volte in assenza di controllo della versione o gestione delle modifiche nei database di sviluppo. Il programmatore A apporta una modifica a una tabella, vista o proc. Il programmatore B modifica la stessa cosa e sovrascrive ciò che ha fatto il programmatore A. Oppure, DBA ripristina un DB di produzione allo sviluppo e sovrascrive le modifiche. Ho visto questo genere di cose causare un dolore considerevole così tante volte non è divertente. E questo è solo sui sistemi di sviluppo. Le cose possono diventare davvero disordinate quando la gestione temporanea / test e persino i server di produzione vengono coinvolti in questo.

Per essere efficace, il controllo della versione del database non deve essere uguale al controllo della versione del codice normale. Tuttavia, una sorta di controllo delle modifiche e backup della cronologia prevengono molti problemi.

Pensalo come "Controllo versione" anziché "Controllo del codice sorgente". Ciò implica che puoi vedere l'intera storia di quel particolare script. Indipendentemente dal fatto che sia possibile ricostruire il database nella sua forma attuale, sarà più una questione di pratiche relative a questi script e ai framework utilizzati per crearli.

Per i nostri progetti PHP / MySQL, abbiamo utilizzato uno (una volta) piccolo strumento chiamato Ladder . È progettato per facilitare la crescita organica di un database nel tempo. Tutte le migrazioni per un progetto sono memorizzate nel controllo di revisione / sorgente / versione e sono tracciate insieme al codice.

Supporta l'aggiunta / modifica / eliminazione di colonne, l'esecuzione di query, l'aggiunta / eliminazione di indici, vincoli, ecc. Tratterà lo stato in cui si trova il database e applicherà eventuali migrazioni mancanti. Ti permette anche di "tornare indietro nel tempo" specificando una migrazione a cui devi essere presente. ( php ladder.php migrate 15)

Oh, e l'ultima aggiunta è diversa dal database. Eseguire il diff-savecomando, aggiungere e rimuovere alcune colonne dal database ed eseguirne il diffcomando. Vedrai il codice di migrazione generato automaticamente in base allo stato del database.

DataGrove risolve alcuni dei problemi citati qui ( ad esempio da jfrankcarr ).

Tiene traccia di tutte le modifiche a un DB e ti consente di salvare una versione dell'intero stato del DB in un repository. Ti consente quindi di generare più copie virtuali dello stesso DB, in modo che ogni sviluppatore o DBA possa avere la propria copia separata (ogni copia virtuale può essere generata da una versione diversa). Assicurerà che nessuno sovrascriva il codice / le modifiche di qualcun altro. Ciascuna delle copie virtuali viene inoltre rintracciata negli stessi repository in modo che tutti gli stati DB possano essere facilmente condivisi e ricreati.

Mi piacerebbe anche portare uno strumento di monitoraggio che può essere utilizzato anche come strumento di controllo delle versioni dei dati. Lo strumento di cui sto parlando è MONyog, in realtà è uno strumento di monitoraggio MySQL ma con un po 'di hack possiamo facilmente usarlo come versione dei dati.

Ma prima di andare oltre citerò che non sarà consigliabile creare l'intero database per il controllo delle versioni. È un vero assassino tenere traccia dei cambiamenti per un determinato insieme di dati.

MONyog ha una funzione chiamata CSO (Custom SQL Objects), che può monitorare la modifica in un particolare set di dati. L'aggiunta di un CSO è descritta qui . Ora nella sezione cronologia monitor di MONyog è possibile ottenere le modifiche per un periodo di tempo. Meglio, fornisce un rapporto visivo nella pagina html. Il rapporto sarà simile a questo