VSTS progetto di database di distribuzione continua

4

Alla ricerca di continue strategie di implementazione per i progetti di database del server SQL indirizzati a Azure SQL tramite VSTS. Il mio scenario ...

  • Uso di VSTS per CI / CD
  • Utilizzo di un progetto di database SQL Server per definire lo schema del mio database
  • Uso di Dapper per il mio ORM (quindi nessuna migrazione tramite EF)
  • Utilizzo di un database SQL di Azure
  • Alcune tabelle hanno dati seme, che molto probabilmente verranno aggiunti nel tempo (supponiamo che nessun dato seme venga eliminato per il momento)
  • Utilizzo di test di integrazione destinati a un database separato, poiché i test cancelleranno i dati di ogni tabella
  • Uso del flusso Git

Vedo tre scenari che devo gestire

  1. Le modifiche al database non distruttive vengono apportate al ramo di sviluppo, che può includere o meno modifiche ai dati
  2. Le modifiche distruttive del database vengono apportate al ramo di sviluppo
  3. È necessario unire più commit con una combinazione di scenari 1 e 2 nel ramo principale

Il primo scenario può essere facilmente gestito utilizzando l'attività di distribuzione SQL di Azure e DACPAC incorporati di VSTS. I dati dei semi verranno aggiunti utilizzando gli script di pre / post distribuzione

Il secondo scenario è un po 'più difficile, tuttavia dovrebbe seguire lo stesso approccio dello scenario uno con lo script di pre-distribuzione che è molto più importante in quanto sarebbe responsabile della rimozione dei vincoli, eliminazione dei dati , ecc.

Il terzo approccio su cui sono completamente perso. Quello che accadrà è che ho una serie di commit che devono essere uniti in un singolo ramo, tutti con script di distribuzione pre / post che devono essere eseguiti in un ordine specifico. Non sono a conoscenza di una strategia o di uno strumento in grado di gestirlo e sto cercando suggerimenti qui.

Infine, e questo non è estremamente importante, ma ho anche test di integrazione che hanno come target un database di test che vorrei eseguire durante la compilazione (parte CI) in contrasto con la parte di rilascio (CD). Qualcuno è a conoscenza di una guida o di istruzioni sull'implementazione di test di integrazione su un database di test come parte di un processo di configurazione?

-Tim

    
posta Tim_Cardwell 25.01.2018 - 23:45
fonte

1 risposta

0

Ecco come lo facciamo ...

  • Qualsiasi semplice modifica che può essere effettuata tramite la distribuzione DACPAC viene gestita in questo modo
  • Per qualsiasi altra modifica, viene creato un singolo script SQL che effettua la modifica e gestisce tutte le migrazioni
    • Gli script hanno ciascuno una specifica versione incrementale (cioè 5.1.4.sql , 5.1.5.sql )
    • Quando viene eseguito uno script, viene tracciato nel database utilizzando una tabella DeploymentScripts
    • Lo script di pre-distribuzione chiama ciascuno degli script, prima controlla DeploymentScripts per verificare che non siano ancora stati chiamati
  • Quando si tratta di unire più commit in master , tutto ciò che devi fare è confermare che tutti gli script richiesti sono stati inclusi nello script di pre-distribuzione e che sono nell'ordine corretto

Se desideri eseguire test di integrazione durante il processo di generazione, non conosco un modo integrato per farlo, ma potresti probabilmente aggiungere un'attività di PowerShell che attiva un rilascio e quindi attiva qualsiasi test tu potrebbe voler correre. Il trucco restituirebbe un codice di uscita all'attività di build che lo fallisce.

    
risposta data 12.10.2018 - 01:47
fonte