È buona prassi avere un database pre-compilato incorporato per lo sviluppo?

Perché no!

Personalmente, preferisco avere script che compilano un database vuoto con nuovi dati, così posso a) sapere esattamente cosa sta succedendo in eb) per cambiarli facilmente.

Lo faccio anche per i nostri grandi database di produzione, mantenendo uno script con i "soliti dati" che altrimenti dovrei inserire a mano - cose come un id utente predefinito per me stesso e una configurazione standardizzata.

Questo è probabilmente più utile nello sviluppo di quanto non lo sia per l'integrazione o in particolare per il QA, che dovrebbe creare il proprio DB utilizzando gli strumenti forniti per verificare che gli strumenti funzionino ancora con le nuove versioni.

Questa è davvero una buona idea e dovresti farlo. Vorrei andare oltre, anche se, con database preconfigurati tra cui scegliere e la possibilità di puntare a database condivisi per il team.

• Vuoi poter ripristinare il tuo database. Potrebbe essere necessario che sia in uno stato noto, difficile da riprodurre per innescare un particolare bug. Essere in grado di testare e correggere questi tipi di bug è un grande aiuto.

• Essere in grado di alzarsi e correre velocemente è fondamentale. Questo è un tempo improduttivo all'inizio di un progetto o durante un'iterazione se è necessario ripristinare qualcosa.

• Essere in grado di passare da un database all'altro può essere di grande aiuto. Cosa succede se il QA segnala un errore ma non riesci a riprodurlo? Certo, puoi vederlo sul sistema QA, ma questo non ti aiuta a scorrere il codice. Essere in grado di riconfigurare il tuo ambiente di sviluppo per utilizzare un database diverso in modo rapido e semplice può aiutare a ridurre il ciclo di feedback.

• Avrei una serie di script per aggiungere rapidamente dati specifici a un nuovo database per testare scenari specifici. Questi potrebbero essere script SQL o script di test automatici come Selenium .

Essere in grado di configurare e utilizzare un database in modo rapido e arbitrario è un enorme aiuto nello sviluppo con molti aspetti positivi e solo uno svantaggio che mi viene in mente:

• È facile avere più persone che utilizzano lo stesso database. Se più sviluppatori e tester stanno modificando gli stessi dati, in realtà potrebbero invalidare i loro test mentre si calpestano l'un l'altro. Anche se questo potrebbe non essere un grosso problema nella produzione, può essere frustrante nello sviluppo e nel testing in cui i dati potrebbero dover essere in uno stato specifico durante il test e il debug.

Sì, questa è un'ottima idea.

Per semplificare lo sviluppo, è molto utile ridurre al minimo i passaggi tra "check out sources" e "system is running". Fornire un database pre-compilato aiuta con quello. L'ho usato in passato e l'ho trovato molto utile.

Ci sono diversi modi per farlo:

• uno script SQL che viene eseguito automaticamente (o manualmente) - spesso la soluzione più semplice
• puoi scrivere del codice che popola il database usando le stesse classi / framework che usi nella produzione - ti consente di riutilizzare il codice e significa che le modifiche dello schema si applicano automaticamente al tuo database di test
• avere una sorta di dump di DB che carichi - meno flessibile da cambiare, ma utile se vuoi usare dati reali (ovviamente, prenditi cura di anonimizzare / disinfettare prima!)

Idealmente, la generazione dei dati di test dovrebbe essere eseguita automaticamente durante la creazione o l'avvio del sistema.

Ovviamente, aggiungi salvaguardie per far sì che tutto questo non funzioni mai in produzione!