Come impostare il processo di sviluppo del database locale per un piccolo team Web?


14

sfondo

Sto lavorando alla creazione di un nuovo processo di sviluppo per un piccolo team web di circa 4 programmatori e 4 designer, con l'ovvio potenziale di far crescere il team in futuro. Il nostro prodotto è un'applicazione centrale che alimenta i siti Web dei clienti che progettiamo e ospitiamo.

In precedenza, lavoravamo tutti via FTP su un server di sviluppo, con un singolo database di sviluppo. "Ha funzionato" * per un po ', ma ci stiamo muovendo in una nuova direzione, quindi è tempo di maturare il nostro processo.

Usiamo Percona Server 5.5, ma questo dovrebbe essere indipendente dal database, con l'idea di mantenere bassi i costi.

Obiettivi :

Sto cercando di creare un processo di integrazione continua (CI) per lo sviluppo di database tenendo presente quanto segue:

  1. Gli sviluppatori hanno una copia locale dei dati per eseguire il codice di sviluppo
  2. In grado di ripristinare la struttura del database su un changeset precedente
  3. In grado di separare le nuove modifiche dello schema delle funzionalità rispetto alle modifiche della correzione della progettazione dello schema
  4. In grado di modificare la struttura del database localmente per il test

Concetto iniziale

Di seguito ho delineato un processo usando SVN e LiquiBase, sebbene rimuova completamente #4.

  • creare un ramo di "sviluppo" dal tronco
  • il server db "sviluppo" centrale esegue il ramo "sviluppo"
  • gli sviluppatori locali sono impostati come slave per il ramo di sviluppo (fornisce #1sopra)
  • I changeset di liquibase vengono impegnati regolarmente nel ramo di sviluppo, che esegue un hook post-commit per aggiornare il database di sviluppo centrale (che verrà trasferito ai computer locali in esecuzione come slave su questo server di sviluppo) (liquibase fornisce #2sopra)
  • quando le funzionalità o le correzioni dello schema sono pronte per passare al QA, DBA (me) unirà le modifiche appropriate dal ramo di sviluppo al trunk. Questo atto creerà uno script sql da applicare a un server di database di gestione temporanea.
  • Il server di gestione temporanea dovrebbe riflettere TRUNK, che dovrebbe avere la stessa struttura della produzione, oltre alle modifiche che si trovano nel QA
  • dopo aver eseguito lo script sql sul server di gestione temporanea, eseguire alcuni controlli di qualità sulle modifiche.
  • Se tutto sembra a posto, TAG la struttura. Ciò genererà lo script .sql che verrà eseguito in produzione manualmente dal DBA (per le ore non di punta, se necessario)

Questo processo richiede che tutti gli sviluppatori eseguano lo stesso ramo di "sviluppo", il che significa che esiste una sola versione dello schema del database in qualsiasi momento (non sono sicuro di volerlo).

Significa anche che eventuali modifiche allo schema non possono essere testate localmente e potrebbero influire su altri sviluppatori se non eseguite correttamente. Nel nostro ambiente, gli sviluppatori potrebbero aggiungere nuove tabelle ma raramente modificare la struttura esistente. Come DBA, le correzioni del design sono state fatte da me. Ma l'incapacità di testare le correzioni localmente è il mio più grande blocco del processo.

In che modo è possibile modificare il processo sopra descritto per consentire lo sviluppo locale, pur mantenendo una copia dei dati relativamente aggiornata (come fornita dalla replica nel processo proposto)? Non ho bisogno che i dati siano aggiornati fino all'ultima settimana.


* Per "lavorato", intendo dire che è stato sufficiente, ma era un PITA.

Risposte:


12

Gestione degli ambienti

Penso che sicuramente non vuoi essere forzato in una singola versione del database. Hai abbastanza sviluppatori che avrai inevitabilmente più flussi di lavoro di sviluppo e requisiti per applicare patch all'attuale ambiente di produzione indipendentemente dai flussi di lavoro di sviluppo.

È possibile utilizzare Liquibase o un processo manuale per produrre script di patch per aggiornare le versioni. Suggerisco di iniziare con un processo manuale e di utilizzare lo strumento di confronto dello schema per il QA sulle patch. La sincronizzazione pulita, automatizzata e trasparente di un database non banalmente complesso è un po 'utopica.

Il tuo modello di dati centrale può essere mantenuto in qualunque sistema desideri. Ho usato di tutto, dai noiosi strumenti di repository enterprise per creare script di tabelle. Creare script di tabelle si gioca bene con i normali strumenti di controllo del codice sorgente come sovversione e non tutti gli strumenti di repository fanno un buon lavoro di controllo delle versioni.

Qualunque cosa tu usi come repository del modello di dati master, hai bisogno di un meccanismo abbastanza pulito per distribuire un ambiente da quel modello. Dovrebbe essere strutturato in modo tale che l'implementazione in un ambiente sia semplice. È inoltre necessario un meccanismo per applicare patch da una versione rilasciata alla successiva.

Quello che ho fatto

Ho fatto quanto segue in passato quando gestivo gli ambienti di sviluppo. Non è particolarmente high-tech, ma è suscettibile di controllo delle versioni e build automatizzate, quindi rende facile implementare un ambiente su una versione specifica e mantenere un gran numero di ambienti è abbastanza pratico.

Mantenere un repository centrale: potrebbe trattarsi di un set di script per la creazione di database contenuti in un sistema di controllo versione o di un modello di repository in uno strumento di modellazione dei dati. Fai la tua scelta. Questo modello dovrebbe avere un meccanismo di compilazione che consenta di implementare un ambiente dagli script senza molto intervento manuale.

Se disponi di molti dati di riferimento, dovrai disporre di un meccanismo di caricamento. A seconda di come lo si desidera, è possibile mantenerlo in un database o in un set di file. Il vantaggio dei file è che possono anche essere versionati ed etichettati dallo stesso sistema di controllo della versione della tua base di codice. Un gruppo di file CSV e script del caricatore di massa in un repository di controllo del codice sorgente può farlo abbastanza facilmente.

Un'opzione per la distribuzione di ambienti di sviluppo è quella di prendere i backup del database di produzione patchati alla versione appropriata e renderli disponibili per gli sviluppatori per ripristinarli in un ambiente di sviluppo.

Semplifica l'implementazione: come ogni processo di compilazione di elementi della configurazione, il database deve essere distribuibile da un singolo script. Configurarlo in modo che le connessioni al database possano essere paramaterizzate o che lo script sia indipendente dalla posizione e possa essere semplicemente eseguito attraverso la connessione.

Script di patch: sarà necessario eseguire il roll forward e probabilmente ripristinare gli script da ciascuna versione rilasciata.

Crea ambienti di test dal modello di repository: questo garantisce che lo sviluppo su ambienti non sincronizzati con il repository venga bloccato nei test.

Testare il processo di distribuzione: gli script di patching automatizzati, tuttavia vengono creati, dovrebbero essere verificabili. Gli strumenti di confronto degli schemi sono abbastanza buoni per questo, anche se non li usi per generare gli script di patch.

  • Crea un ambiente di riferimento con la build del modello di repository su cui hai provato

  • Crea un ambiente di prova del fumo con un backup della versione di produzione o una build basata sulla versione rilasciata corrente.

  • Esegui lo script di patch sull'ambiente test fumo.

  • Utilizzare lo strumento di confronto degli schemi per confrontare l'ambiente del test del fumo con l'ambiente di riferimento. Lo script di patch dovrebbe risultare identico nei due database, in modo da poter esaminare eventuali differenze.

Quello che mi piace di questo processo

Questo è un po 'pesante ed è stato progettato per essere distribuito in ambienti di produzione abbastanza burocratici e opachi. Tuttavia, ha i seguenti punti di forza:

  • Gli sviluppatori possono armeggiare dove devono.

  • È possibile accogliere più rami e flussi di sviluppo.

  • Gli script di distribuzione stessi possono essere testati in modo ripetibile. Questo è molto utile per chiudere i combattimenti di schieramento, in quanto la ripetibilità può essere dimostrata.

  • Gli strumenti di confronto degli schemi forniscono QA sulla distribuzione stessa.

  • I test vengono sempre eseguiti in base a ciò che dovrebbe essere rilasciato e ciò consentirà di rilevare i problemi derivanti da ambienti non sincronizzati.

  • La distribuzione basata su modelli di repository e script di patch significa che l'immondizia incontrollata non viene migrata accidentalmente dagli ambienti di sviluppo alla produzione.

  • Gran parte del processo può essere automatizzato, sebbene sia spesso preferibile preparare e testare manualmente gli script delle patch di distribuzione.

  • Gli ambienti sono economici e facili da implementare senza dover saltare attraverso i cerchi.

  • Gli sviluppatori sono costretti a creare un sistema adatto a un semplice processo di compilazione e distribuzione.

  • Gli sviluppatori sono costretti ad apprendere le attività di amministrazione di base del database, ma gli ambienti di test e produzione sono isolati da errori noob.

Come risponde alle tue esigenze

  1. Gli sviluppatori dispongono di una copia locale dei dati per eseguire il codice di sviluppo contro

    Gli script di distribuzione o le immagini DB indicano che possono configurare un ambiente da qualsiasi versione disponibile.

  2. In grado di ripristinare la struttura del database su un changeset precedente

    Ancora una volta, ordinati per script di distribuzione. Tramite DDL o testando le immagini di backup del database create attraverso un processo controllato, gli sviluppatori possono creare un ambiente per qualsiasi versione specifica in tuo possesso.

  3. In grado di separare le nuove modifiche dello schema delle funzionalità rispetto alle modifiche delle correzioni della progettazione dello schema Le

    patch per una versione comune possono essere gestite in un fork separato nella struttura svn. Se i backup del database vengono utilizzati come ambienti di riferimento, devono essere archiviati da qualche parte con la stessa struttura di cartelle della diramazione dei progetti di controllo del codice sorgente.

  4. In grado di modificare la struttura del database a livello locale per i test

    Il semplice processo di distribuzione consente agli sviluppatori di armeggiare e ripristinare facilmente un ambiente a uno stato locale, oppure di creare un ambiente di riferimento per fare confronti e apportare modifiche.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.