VSTS CI / CD Flusso di lavoro con codice e script Sql

TL; DR

Come configurare il progetto VS2017 e il CI / CD di Visual Studio Team Services per pubblicare codice, eseguire script SQL e dati seme?

Dettagli

Ho avviato un progetto con Visual Studio 2017 v15.6.4 (versione corrente) e utilizzerò Code First . I Enable-Migrations e ecco cosa voglio ottenere come flusso di lavoro:

1. Come sviluppatore, voglio usare Add-Migrations per lo sviluppo locale (dev)
2. Una volta che ho finito con le modifiche, uno sviluppatore creerebbe script sql change usando Updated-Database -Script -SourceMigration:... -TargetMigration:... e li aggiungerà al progetto nella propria cartella per i DBA (vedi link )
   • motivo: voglio un DBA per controllare gli script ed eseguirli su un'area di staging prima di implementare
3. Attualmente l'applicazione contiene dati di seeding definiti nel file Configuration.cs creato dalle migrazioni (solo su dev)
4. Lo sviluppatore quindi invierà tutte le modifiche a Visual Studio Team Services (VSTS)
   • Ho usato la funzione integrata di VS2017 per configurare un CI / CD in VSTS che crea e pubblica su un sito di Azure (tutto questo funziona)

deve essere completato:

5. Imposta VSTS in modo che richieda approvazione prima di distribuire il sito sul sito di staging di Azure da un DBA e un tester
   • Aggiungerò un processo di approvazione in modo che un DBA debba prendere gli script sql e convalidarli (tuttavia, potremmo definirlo in-house, di solito creare una nuova copia del db di produzione ed eseguire gli script su di esso)

6. Basato sull'ambiente, o (preferito: A):

   A. VSTS pubblica sito / codice, esegue i dati di migrazione / seme (come fare?) nell'area di gestione temporanea

   B. DBA approverà la verifica degli script e VSTS pubblicherà il sito / codice nell'area di gestione temporanea

7. A questo punto, il tester può testare il sito di staging contro il db di stadiazione
8. Il tester può approvare (o rifiutare, naturalmente)

A questo punto, l'installazione desiderata potrebbe richiedere 2 modi:

A. una volta approvato da tutte le parti, VSTS esegue automaticamente gli script sul DB di produzione (dovrebbe andare bene come è stato testato al passaggio 5) e pubblicare il sito sul sito di produzione tutto in una volta

o

B. DBA deve eseguire gli stessi script con prod db, quando l'approvazione su VSTS è completa il sito pubblicherà sul sito di produzione * quello che non mi è chiaro su questa versione è, certo, che ci sarà un downtime, ma chi dovrebbe andare prima? Posto? Script DB?

Preferisco l'opzione A per evitare troppo tempo, qualcuno ha avuto esperienza con una di queste opzioni? Ci sono dei passaggi che dovrei aggiungere tra?

Infine, ho familiarità con Code First Migrations seeding del database mentre sto sviluppando, ma come si fa quando si esegue la messa in scena o la produzione? * Presumo che avrò bisogno di fornire agli amministratori di database anche uno script di semi? * Posso creare facilmente uno script di seeding in VS2017 basato sul mio file Configuration.cs o dovrò farlo manualmente?