Sviluppo condiviso e database CI

Question

Sviluppo condiviso e database CI

#1 da (4 voti)
#2 da (2 voti)
#3 da (0 voti)

3

Sto per configurare CI per la mia applicazione web. Sto utilizzando Bitbucket e Pipeline beta come CI. L'applicazione web è strongmente accoppiata al database, nulla può essere testato senza i dati in esso contenuti.

Anche il mio team ha alcuni problemi con lo sviluppo locale, poiché a causa delle frequenti modifiche dello schema del database, le migrazioni di Django sono irreversibili, quindi stiamo finendo di ripristinare il DB e impostare gli stessi utenti ogni tanto (che è un molto lavoro manuale ripetuto, sembra qualcosa che potrebbe essere automatizzato).

Mi chiedo se esiste una best practice per risolvere questi problemi. Avevo un'idea di avere un database controllato dalla versione, che può essere considerato come l'unica fonte di verità per lo sviluppo locale e per i test e2e sull'elemento della configurazione. In questo modo non finiremo per utilizzare un database condiviso, ma tutti potranno estrarre la versione più recente del dispositivo DB e aggiornarlo se necessario. Ci sono dei motivi contro questo? (Non ho mai sentito nessuno che lo faccia prima)

Modifica

Lavoriamo con il backend Django, il frontend angolare e MySQL

database continuous-integration development-environment acceptance-testing

posta fodma1 27.06.2016 - 13:57

fonte

3 risposte

Leggi altre domande sui tag database continuous-integration development-environment acceptance-testing

Potrebbe essere definito un pattern decoratore? I criteri di accettazione della user story agile sono gli stessi dei requisiti funzionali tradizionali?

score 4 · Answer 1

Abbiamo un set di script SQL che usiamo per creare e modificare il DB tra le versioni - come il suo testo, il suo memorizzato nel VCS e taggato insieme a tutto l'altro codice.

Uno degli script è un "imposta dati predefiniti" uno, e un altro è uno script specifico per lo sviluppo che imposta tutto l'ambiente abituale, come gli utenti dello sviluppatore.

Quando si desidera un nuovo DB, è banale eseguire lo script da una linea cmd e crea, configura e configura un DB per la versione specifica che stiamo utilizzando. Funziona molto bene.

L'unica difficoltà è che tutti i dati personalizzati che sono stati inseriti sono persi, ma non è troppo difficile usare l'app per aggiungere nuovi dati, ed è probabilmente una buona cosa per eliminare tutto il dev crud che si accumula regolarmente in ogni caso.

score 2 · Answer 2

Molte persone usano il controllo della versione con i database.

Esistono più schemi per farlo e qualsiasi numero di strumenti, ma fondamentalmente è una buona via da percorrere.

Allo stesso modo sostengo con forza i database locali per gli sviluppatori, se è ragionevole, otterremo problemi di unione se cambi lo schema molto, ma dovresti essere in grado di elaborare le pratiche per mitigare questo come andate.

Per i test e2e sul retro della build è possibile avere una "istanza di riferimento" del database che si migra alla corrente e testare, questo deve essere sanificato ma rappresentativo dei dati del mondo reale. Dovrai aggiornare regolarmente l'istanza di riferimento ma non deve essere completamente aggiornata (perché hai una gestione automatizzata della migrazione) ed è probabile che diventi lo stesso database a cui vuoi far lavorare i tuoi sviluppatori (se il db di un dev entra in disordine, quindi ripristini il riferimento ed esegui le migrazioni e ...)

score 0 · Answer 3

Avevo pensato a un setup simile qualche anno fa. Se ti capita di utilizzare MS SQL Server, allora Visual Studio e / o SQL Server Management Studio hanno alcuni buoni strumenti per aiutarti. (Controlla il progetto del database in Visual Studio. Ha fatto molti progressi negli ultimi anni.)

L'unico svantaggio è la quantità di lavoro che deve essere fatto in anticipo, per creare gli script da modificare tra le versioni di DB. Per una piccola squadra che non stava nemmeno pensando a CI, questo si è rivelato un prezzo troppo alto da pagare.