Come gestisci le dimensioni del database in costante cambiamento?

Naviga le tue risposte
9

Negli ultimi due mesi ho cercato soluzioni o pratiche per gestire la gestione dei rilasci all'interno dei database. Sto cercando ciò che le persone considerano il miglior processo per gestirlo.

Abbiamo 3 ambienti per i nostri database:

  • sviluppo
  • Test di accettazione degli utenti (UAT)
  • Produzione

Il problema è che a volte stiamo apportando modifiche a diverse cose all'interno del nostro database di sviluppo e arriviamo il momento di implementare, alcune delle funzionalità potrebbero non essere pronte per essere rilasciate in UAT.

Recentemente abbiamo iniziato a utilizzare il controllo Origine SQL di Red Gate per l'archiviazione di tutte le nostre entità (con commit regolari).

Stavo pensando di basarmi sui changeset (cioè dire che tutto, dal changeset X e back è ora spinto a UAT) tuttavia, questo significa che le persone stanno solo controllando il loro codice nel controllo del codice sorgente prima di fare una distribuzione che può confondersi (soprattutto perché le persone sono smemorate). Un altro problema con l'approccio del changeset è che se c'è un bug in una stored procedure che deve essere corretto, il numero di changeset finirebbe per essere fuori dal nostro maxet changeset per la revisione, quindi fare in modo che se abbiamo bisogno di ricreare il database al di fuori di un changeset massimo, dovremmo rimandare il bug di nuovo.

Qualche suggerimento su un processo?

Grazie

    
posta judda 27.05.2011 - 15:19
fonte

3 risposte

5

Migrazioni

Un alto e un basso, che sono nel tuo repository e taggati insieme alla tua app.

Puoi persino fare il fai-da-te con i flatfile sql che modificano lo schema e aggiornano la versione dello schema. Tutto quello che devi fare è:

  • mantieni le tue migrazioni accanto al codice sorgente, dovrebbero essere versionate e taggate insieme
  • usa sempre le modifiche gestite (migrazioni) in tutti gli ambienti
  • non consentire mai modifiche ad-hoc in qualsiasi ambiente

Bene, puoi apportare modifiche allo sviluppo in dev, ma devi sempre spazzare via db e ricostruirlo con le migrazioni dopo aver acquisito la modifica.

    
risposta data 28.05.2011 - 06:20
fonte
2

Controllo del codice sorgente!

Non distribuisci i tuoi binari di sviluppo direttamente alla produzione senza passare da svn / git / p4, quindi perché i tuoi database lo fanno da soli? Ottieni istanze private per gli sviluppatori per testare le loro modifiche locali, ma quando deve andare al db di sviluppo, deve passare attraverso i file ddl archiviati. È anche possibile scrivere strumenti per applicare automaticamente queste modifiche ddl (non conosco alcun modo per farlo correttamente).

Una volta applicate le restrizioni relative alle modifiche dello schema db (non più sqlplus - > emettere ddl!) e disporre di un controllo rigoroso dell'account (nessun accesso ddl a tutti), questo dovrebbe diventare più gestibile.

    
risposta data 28.05.2011 - 05:34
fonte
0

Seguendo il suggerimento di utilizzare le migrazioni ... forse usare un O / RM che supporta Migrazioni come Ruby on Rails e Entity Framework 4.3 Il problema con entrambi gli approcci è che una migrazione è tutto o niente. Non puoi (di solito) selezionare quali Migrazioni vengono applicate come puoi in termini di serie di modifiche.

Un'altra opzione praticabile (se sei nello stack di Microsoft, non hai mai menzionato la piattaforma) è gestire il tuo SQL con gli strumenti del database di Visual Studio. Ha incorporato refactoring (rinominare / rimuovere colonne, ecc.) E verifica il modello. Se, per esempio, un proc memorizzato fa riferimento a una colonna che non è più lì, ti informerà.

    
risposta data 20.02.2012 - 20:25
fonte

Leggi altre domande sui tag

Perché abbiamo così tanti sapori di .NET? è una cosa buona? [chiuso] Modifica della firma del metodo per l'implementazione delle classi in PHP