Come propagare le modifiche ai dati tra dev, qa e produzione

0

Possiedo strumenti per la propagazione delle modifiche alle definizioni del database, ma eventuali modifiche ai dati apportate Scrivo ed eseguo gli script in ogni ambiente a mano.

Ci sono alcune modifiche / aggiunte di dati che devono essere fatte di routine e vorrei creare una GUI per gestirle, ma se l'ho fatto allora non ho più gli script sql da eseguire in altri ambienti (a meno che non generi loro dallo strumento GUI, ma poi mi rimane ancora la necessità di eseguire queste modifiche a mano in altri ambienti).

Un'idea su cui sto riflettendo è scrivere lo strumento GUI in modo tale da generare i file xml per gli oggetti che ho aggiunto o modificato e includere questi file xml nella pubblicazione del progetto web. Quindi l'applicazione può guardare questi file xml e aggiornare il database di conseguenza.

Esistono pratiche standard o strumenti per spingere automaticamente le modifiche dei dati insieme alla definizione del db e / o alle modifiche al codice?

EDIT:

In base alla prima risposta che ho ricevuto, sembra che avrei potuto farlo sembrare come se volessi uno strumento per confrontare i database di sviluppo con i database di produzione e propagare tutte le modifiche. Questo NON E 'SICURAMENTE quello che stavo cercando di comunicare.

Un esempio di ciò di cui mi occupo sono i testi di lingua che devono essere aggiunti (no, non posso usare i file di risorse per questo perché gli utenti finali possono modificare i testi attraverso l'applicazione in fase di runtime). Invece di dover scrivere script ogni volta che ho bisogno di aggiungere testi per un nuovo elemento, sarebbe fantastico se potessi creare uno strumento GUI per semplificare il processo.

Penso che sia abbastanza ovvio perché preferirei usare una GUI che sovrascriva le istruzioni SQL, e quindi la prossima domanda è perché dovrei propagarla allo stesso modo in cui propaghiamo le modifiche al codice. Bene, questo non è come gli altri dati di test. Si tratta di dati che verranno SEMPRE propagati in ogni ambiente. Lo stesso tipo di preoccupazioni che ci portano a utilizzare gli strumenti per semplificare il processo di spinta delle modifiche al codice o al database in ogni ambiente si applicano al tipo di dati di cui sto parlando qui.

    
posta BVernon 14.11.2014 - 22:25
fonte

2 risposte

1

Perché vorresti propagare le modifiche ai dati insieme alla promozione della definizione o delle modifiche al codice da Dev a QA a Prod?

Non penserei che ci sia qualcosa del genere là fuori perché, se mai, è meglio essere in grado di aggiornare Dev e QA con i dati di Prod ... non il contrario. In una situazione in cui è necessario creare nuovi dati in Dev o QA perché si sta testando una nuova funzione che si occupa di qualcosa che i dati esistenti non contengono, il fatto è che sono solo ... i dati di TEST. Le migliori pratiche del QA dettano che i dati in corso in Prod devono essere puliti.

Se necessario, le migliori pratiche nella mia esperienza sono quelle che già possiedi: usa gli script (ci sono alcuni strumenti di migrazione dei dati là fuori che sono pensati per una cosa del genere), o inseriscili manualmente.

    
risposta data 14.11.2014 - 22:55
fonte
0

Se hai bisogno di un modo per creare cambiamenti riproducibili in un database, gli strumenti della GUI sono spesso non il miglior approccio possibile. Quando si modifica qualcosa utilizzando uno strumento GUI, la GUI a volte può solo indovinare come il cambiamento è stato inteso "in generale". In SQL, tuttavia, puoi esprimere le esatte regole di modifica che hai in mente - e ti dà la possibilità di inserire le modifiche nel controllo della versione, testare le modifiche ed eseguirne il debug quando il test mostra un problema. E, come hai notato tu stesso, forniscono una soluzione riproducibile per il tuo QA e l'ambiente di produzione.

Quindi la prima cosa che dovresti chiederti è: hai davvero bisogno di uno strumento GUI.

Tuttavia, quando pensi di avere troppo lavoro tedioso da fare con ogni cambiamento, puoi comprarti uno strumento di confronto dello schema (vedi qui per alcuni suggerimenti, ci sono diversi strumenti per diversi DBMS). Questi strumenti possono probabilmente aiutarti a confrontare diverse versioni dei tuoi schemi di database di sviluppo e potresti tranquillamente fare un po 'di fatica nella creazione degli SQL per il tuo ambiente di controllo qualità e dei prodotti.

    
risposta data 17.11.2014 - 19:58
fonte

Leggi altre domande sui tag