Memorizza le esportazioni mysql nel tuo strumento di controllo della versione per ripristinare in caso di errore?

Naviga le tue risposte
1

Gestiamo un server Web interno con software interno per l'esecuzione di una linea di produzione.

Quando devono essere aggiunte le nuove funzionalità del prodotto, si verificano entrambe le seguenti condizioni:

  1. le modifiche al software del server in-house potrebbero essere necessarie per supportare questi - questi sono per cambiamenti significativi nelle funzionalità, essendo l'unità di codice.
  2. cambia nel database MySQL per le nuove voci per i numeri di parte, queste sono per modifiche minori, configurazioni, modifiche a valori e parametri già esistenti - tali modifiche non richiedono modifiche al codice. Idealmente vorremmo che le nostre modifiche fossero qui piuttosto che nell'articolo 1.

L'elemento 1 è controllato in versione in Subversion, quindi è possibile fare riferimento alle revisioni precedenti per il ripristino in caso di problemi introdotti nell'ultima revisione.

Ma per quanto riguarda le modifiche al database MySQL?

Abbiamo processi di qualità per garantire che tali modifiche siano prive di errori ma c'è sempre la possibilità che gli errori possano passare, ad es. errore nell'immissione di dati o errori con il codice che utilizza il MySQL che danneggia il database ecc.

Abbiamo un backup automatico ogni 6 ore ma, se vogliamo più checkpoint definiti manualmente tra questi intervalli, potremmo utilizzare lo stesso sistema di backup, ma mi chiedevo se la gente qui usasse altri metodi per memorizzare precedenti stati di database, ad es. esportando il database come dump SQL in testo semplice - almeno con questo metodo sarebbe possibile vedere le differenze, ad es. in Oltre Confronta per risoluzione dei problemi.

Pensieri?

    
posta therobyouknow 01.02.2011 - 15:11
fonte

3 risposte

2

Ciascuna delle nostre filiali ha una cartella privata, al suo interno memorizziamo i file delle patch per eventuali modifiche SQL, sia lo script SQL che uno back-out nel caso in cui il problema debba essere ripristinato.

Al momento del rilascio le patch per tutti i rami di sviluppo che fanno parte di una release vengono testate insieme per garantire che non vi siano conflitti.

    
risposta data 01.02.2011 - 16:00
fonte
1

Abbiamo creato il nostro sistema di tracciamento della cronologia / versione per i dati nel database, analogo alle risposte qui:

link

    
risposta data 01.02.2011 - 17:53
fonte
0

Per il particolare progetto (un'applicazione LAMP) su cui sto lavorando attualmente, ho 2 repository Subversion. Ho un repository di Project, che contiene il codice sorgente e un altro repository SVN di "supporto". Il repository SVN di supporto contiene file che mi aiutano nell'implementazione dell'applicazione, ma non sono utilizzati dall'applicazione. Mantengo i diagrammi dello schema del database, i documenti che elencano le mie variabili globali e ogni tanto i backup del database sul repository SVN di supporto. In questo modo, posso sovrascrivere l'ultimo backup, ma ottenerlo se necessario. Ciò mantiene anche le cose meno spente: devo solo avere un file che continua a cambiare per i backup del database.

    
risposta data 01.02.2011 - 15:22
fonte

Leggi altre domande sui tag

Quali caratteristiche mancano dagli strumenti IDE di Python? Quale processo dovrebbero rientrare nelle specifiche del campo, nei requisiti o nella progettazione?