Ha senso gestire i dump del database di produzione / dev / test come dipendenza?

1

Spesso mi viene in mente l'idea di distribuire le applicazioni in ambienti produttivi, di sviluppo e di test (non test delle unità, intendo come una sandbox) quando si tratta di database.

E no, il controllo del codice sorgente non è un'opzione. Tre ragioni principali: 1) Non voglio necessariamente che gli sviluppatori guardino a informazioni sensibili (come password, carte di credito, ecc.), 2) i database diventano grandi, troppo grandi per un DVCS come git o Mercurial, 3) Voglio mantenere la tracciabilità tra il codice e i dump del database.

Ultimamente ho usato Artifactory e l'ho trovato molto utile in diversi flussi di lavoro. Artifactory è un repository artefatto / dipendenza, che è diverso da un repository di controllo versione in quanto è pensato per la gestione di file / risorse di grandi dimensioni e può essere utilizzato con strumenti di gestione delle dipendenze.

Mi è venuto in mente che, invece di accumulare backup di database in un file server in cui non riesco a rintracciare tali file in un modo che dovrebbero andare insieme (ad es. gestione della configurazione), potrei benissimo usare Artifactory (o qualsiasi altro altri set di strumenti di gestione degli artefatti / dipendenze) e semplificano l'automazione della distribuzione evitando il pantano di creare una soluzione di gestione dei backup.

Quindi, questo concetto / caso d'uso è mal concepito? o è effettivamente fatto nella pratica? (perché non riuscivo a trovare questo fatto ovunque)

    
posta dukeofgaming 29.02.2016 - 00:18
fonte

0 risposte

Leggi altre domande sui tag