Utilizzo di un database comune per lo sviluppo collaborativo

Question

Alcune delle persone nel mio progetto sembrano pensare che usare una banca dati di sviluppo comune con tutti coloro che vi si collegano sia la cosa migliore. Penso che non lo sia e ogni sviluppatore che ha il proprio database (con dump di dati aggiornati periodicamente) è il migliore. Ho ragione o torto? Hai riscontrato problemi in uno di questi approcci?

Answer 1

Lo spazio su disco e la CPU dovrebbero essere abbastanza economici che ogni sviluppatore può eseguire la propria istanza del database , con una build automatizzata sotto il controllo della versione. Ciò è necessario per consentire agli sviluppatori di essere audaci nell'hacking del database, in isolamento da qualsiasi altro hacker simultaneo dello sviluppatore.

L'avvertenza è, ovviamente, che qualsiasi modifica apportata alla propria istanza privata è inutile per chiunque altro a meno che possa essere automaticamente applicato durante il processo di compilazione. Pertanto, è necessario disporre di una solida politica secondo cui il codice dell'applicazione non può dipendere da alcuno stato del database, a meno che tale stato non sia rappresentato da modifiche testate dall'unità e testate in versione DDL .

Per un'eccellente guida sulla teoria e la pratica del trattamento della definizione del database come un'altra parte del codice del progetto e del coordinamento delle modifiche e dei refactoring, vedere Database di refactoring: progettazione di database evolutivi di Scott W. Ambler e Pramod Sadalage.

Answer 2

Mi piace avere la mia copia del database per lo sviluppo, perché ti dà la flessibilità di cambiare rapidamente le cose senza preoccuparti di come influenzerà gli altri.

Tuttavia, se tutti gli sviluppatori stanno tagliando via la propria copia del database, diventa sempre più difficile unire il lavoro di tutti insieme alla fine.

Penso che puoi ottenere il meglio da entrambi i mondi lasciando che gli sviluppatori lavorino su una copia locale durante lo sviluppo quotidiano, ma ogni sviluppatore dovrebbe probabilmente unire il proprio lavoro in una copia comune su una base abbastanza regolare. Scrivere molti test unitari aiuta anche.

Answer 3

Condividiamo un singolo database tra tutti i nostri sviluppatori (20 e dispari) ma l'abbiamo strutturato in modo che ognuno abbia le proprie tabelle.

Non hai necessario un database separato per sviluppatore se strutturi l'applicazione nel modo giusto. Dovrebbe essere configurabile quale database o prefisso tabella utilizza comunque in modo da poterlo spostare facilmente tra istanze (unit test, test di sistema, test di accettazione, produzione, disaster recovery e così via).

Il vantaggio di utilizzare un singolo database è che il costo della manutenzione è ammortizzato. Non hai i tuoi DBA che provano a gestire molti database (o, se sei un negozio di piccoli DB, non hai tutti gli sviluppatori che cercano di mantenere il proprio database quando vengono meglio utilizzati nello sviluppo).

Answer 4

Avere un singolo punto di errore non è una buona cosa, vero?

Answer 5

Preferisco un singolo database condiviso. Ma dipende molto dalla situazione e dalle applicazioni in fase di sviluppo.

Ciò che funziona per me potrebbe non funzionare per te. Vai con il tuo intestino.

Answer 6

Se si lavora con Hibernate o qualsiasi piattaforma basata su ibernazione, è possibile configurare il database da creare all'avvio del server (opzione create-drop). Questo è molto utile quando aggiungi nuovi attributi alle tue classi. In tal caso, ogni sviluppatore deve disporre della propria copia del DB.

Se non si modifica affatto la struttura del DB, è possibile utilizzare un singolo DB condiviso. In questo secondo caso non è d'obbligo. Preferisco avere il mio DB dove posso fare quello che voglio. D'altra parte, ricorda che alcune query possono richiedere molto tempo e ciò influirà su tutto il tuo team se condividi un DB.