---

Novembre 2017

Volume 33 Numero 11

Il presente articolo è stato tradotto automaticamente.

DevOps - Migrazione continua dei dati con Visual Studio e TFS

Da Jebarson Jebamony

Migrazione dei dati è spesso un requisito in un'attività di sviluppo di applicazioni, se si tratta di un progetto di base o una riprogettazione dell'applicazione. Nonostante ciò, poco Ottiene attenzione alla migrazione dei dati durante la fase di progettazione e sviluppo, con attività spesso inserito di nuovo l'ultima parte del progetto. Sebbene questo approccio potrebbe consentire un che lo stato attivo sulla migrazione, è dotato di alcuni rischi, non meno di cui è che i team dispongono di tempo e risorse per verificare correttamente la migrazione e il codice circostante.

Il concetto di migrazione dei dati continua si fonda sul concetto di sviluppo di script di migrazione durante lo sviluppo di un'applicazione e gestirli tramite le versioni esattamente come il codice dell'applicazione. Un approccio di migrazione continua consente di testare le migrazioni insieme lo sviluppo di codice, garantendo che l'asset di dati e codice rimangano sincronizzati.

In questo articolo, descrivo una soluzione che sfrutti Visual Studio e Team Foundation Server per ottenere la migrazione dei dati continua. Tenere in considerazione sono disponibili strumenti di terze parti come rollback pronto di Red Gate che sono in grado di eseguire questa operazione parzialmente, ma presentano un costo elevato e non dispongono di funzionalità della migrazione dei dati continua.

Richiesta di verifica e soluzione

Visual Studio può eseguire una pubblicazione incrementale di un database con l'aiuto di SqlPackage.exe, ma lo strumento risulta mancante in molti modi. Ad esempio, SqlPackage.exe fallisce quando inserire una nuova colonna tra le colonne di una tabella, la modifica dei dati del valore di inizializzazione, normalizzazione e la normalizzazione delle tabelle, tra gli altri esempi.

Inoltre, le modifiche di controllo delle versioni è molto importante quando è necessario eseguire la distribuzione e correzioni di destinazione. È ad esempio, potrebbe essere necessario incrementare il valore di una colonna di 10, quando esegue la migrazione dalla versione 1.2 v 1.3, ma non in qualsiasi altro flusso. Può essere ottenuta solo con l'utilizzo del controllo delle versioni; Tuttavia, SQL non dispone di questa funzionalità.

Si vuole affrontare la sfida per progettare una soluzione che si avvale delle novità di Visual Studio e SqlPackage.exe può offrire, durante la risoluzione di differenze indicati in precedenza.

Un progetto di database tipici è disponibili due tipi di script, compilato e non compilata. Tutti gli oggetti, ad esempio schemi, tabelle, viste, stored procedure e così via vengono in genere scritti sotto forma di script compilato. Lo script di inizializzazione e le query di runtime verranno in genere inserite nello script post-distribuzione, ovvero non compilata.

Iniziamo con un esempio. Figura 1 Mostra il progetto di database di esempio AdventureWorks.Database (importati dal backup disponibile all'indirizzo bit.ly/2vPwu4N). Come si può notare, tutti gli oggetti vengono inseriti script compilato.

Figura 1 compilare gli script nel AdventureWorks.Database

Lo script di dati di inizializzazione (contenente i dati necessari per il funzionamento dell'applicazione) è inserire script non compilati e definito nello script di post-distribuzione. Figura 2 illustrata questa operazione. Se non si è consapevoli dell'importanza di script di post-distribuzione, si consiglia di leggere la documentazione di MSDN Library all'indirizzo bit.ly/2w12Iy4.

Figura 2 script di post-distribuzione

Per assicurarsi che lo script di post-distribuzione è possibile gestire la distribuzione incrementale, è stata aggiunta una clausola NOT EXISTS davanti a tutte le istruzioni INSERT. Ad esempio:

IF NOT EXISTS (SELECT 1 FROM [Person].[AddressType] WHERE [AddressTypeID] = 1)
INSERT [Person].[AddressType] ([AddressTypeID], [Name], [ModifiedDate]) VALUES (1 N’Billing’, CAST (N’2008-04-30T00:00.000’ AS DateTime))

Per ragioni di semplicità e facilità di manutenzione, verrà mantenere tutti gli script di inizializzazione rispettivi file e li rimandano nello script di post-distribuzione.

È ora necessario un progetto che consente di distribuire i dati di inizializzazione e lo schema più recenti, in qualsiasi momento. È inoltre in grado di eseguire una distribuzione incrementale in un database esistente, se il progetto non ha introdotto le modifiche di rilievo. Tuttavia, le restrizioni menzionato all'inizio di questa sezione entrano in gioco.

Infine, è disponibile un bug che interrompe la distribuzione incrementale quando viene modificato un tipo definito dall'utente (UDT). Sfortunatamente, il team di Visual Studio è contrassegnato questo bug come non implementabile, vale a dire che è necessario per evitare che. È possibile esaminare ulteriori dettagli sul bug nella voce di Community di sviluppatori Visual Studio in bit.ly/2w0zTBU.

Controllo delle versioni

Come versione di qualsiasi applicazione che si effettua la spedizione, è importante versione il database. Controllo delle versioni consente di tenere traccia di codice sorgente in modo si può facilmente mantenere sotto controllo la funzionalità, bug e le correzioni apportate in ogni versione del software. Se non si ha già familiarità con il controllo delle versioni, consultare l'articolo "Controllo delle versioni semantico 2.0.0" in semver.org dedicare alcuni minuti. Vale la pena un'operazione di lettura.

Prima di iniziare imprevista, è necessario risolvere un problema: SQL non sono effettivamente con un meccanismo per il controllo delle versioni, sarà necessario crearne uno personalizzato. Creare una tabella denominata [interna]. [DatabaseVersion] per archiviare i dettagli della versione, dove "interno" è lo schema della tabella. È consigliabile disporre di uno schema separato per tutti gli oggetti di database utilizzato per scopi interni (ovvero, non partecipano alla business effettivi).

Figura 3 Mostra lo schema sarebbe proporre per la tabella. Se non si è convinti, è possibile seguire un motivo personalizzato. Tenere presente che non si creare versioni per tenere traccia delle compilazioni e versioni.

Figura 3 Schema della tabella

CREATE TABLE [internal].[DatabaseVersion]
(
 [DatabaseVersionId] INT IDENTITY(1,1) NOT NULL,
 [Major] INT NOT NULL,
 [Minor] INT NOT NULL,
 [Build] INT NOT NULL,
 [Revision] INT NOT NULL,
 [CreatedBy] NVARCHAR (256) 
CONSTRAINT [DFDatabaseVersionCreatedBy] DEFAULT ('') NOT NULL,
 [CreatedOn] DATETIME 
CONSTRAINT [DFDatabaseVersionCreatedOn] DEFAULT (GETUTCDATE()) NOT NULL,
 [ModifiedBy] NVARCHAR (256) 
CONSTRAINT [DFDatabaseVersionModifiedBy] DEFAULT ('') NOT NULL,
 [ModifiedOn] DATETIME 
CONSTRAINT [DFDatabaseVersionModifiedOn] DEFAULT (GETUTCDATE()) NOT NULL,
 CONSTRAINT [PKDatabaseVersion] PRIMARY KEY CLUSTERED ([DatabaseVersionId] ASC)
);GO

Ogni volta che apporta una modifica allo schema o controllare in uno script di migrazione di dati, aggiungere una nuova voce di versione per la tabella, che rappresenta l'etichetta per la modifica. Se la versione corrente è 1.0.0.0 e viene introdotta una migrazione che corregge il problema di flag Gender invertendo i valori, verranno aggiunte script appropriati per assicurarsi che modificano e aggiungere una nuova voce alla tabella con la versione che informa 1.1.0128.212.

Migrazione

Come detto in precedenza, Visual Studio è possibile eseguire la distribuzione incrementale, ma non con le modifiche di rilievo. Pertanto, quando progetta la migrazione, è necessario tenere presente che e aggirare la limitazione.

Il primo passaggio consiste nel creare un progetto separato per la migrazione di destinazione. Per quanto riguarda l'esempio in figura 3, creare un nuovo progetto di database denominato AdventureWorks.Database.Migration. La migrazione del progetto due tipi di destinazioni di script. Il primo è lo script di migrazione di dati, che deve essere eseguito se si verifica qualsiasi lo spostamento dei dati o l'aggiornamento. Il secondo script si occupa delle ultime modifiche di schema che non può gestire Visual Studio e SqlPackage.exe. Entrambi questi script andare nel progetto come script post-distribuzione. In questo progetto sono non presenti gli script compilabili.

Per comprendere meglio lo scenario, esaminiamo tutti gli elementi in relazione l'esempio di AdventureWorks. L'ho caricato il codice sorgente per questo il repository GIT in github.com/Jebarson/ContinuousDataMigration. Il ramo master incorpora il progetto di base che ho importato e creato dal database, come indicato in precedenza.

Prima esulano nello scenario, vorrei illustrare il funzionamento della migrazione. Come spiegato nella sezione controllo delle versioni, sono il controllo delle versioni ogni singola modifica rilasciato tramite l'aggiunta di una nuova riga in interno. DatabaseVersion. All'interno del progetto AdventureWorks.Database.Migration, scrivere la logica per eseguire gli script di migrazione appropriato in base alla versione del database di destinazione. Estrarre il diagramma di flusso figura 4 per comprendere la logica coinvolti.

Figura 4, la logica di migrazione

All'inizio del progetto AdventureWorks.Database.Migration, controllare la versione corrente del database e in base che eseguono gli script di migrazione per la versione più recente. Di seguito è possibile utilizzare per stabilire il percorso di migrazione, si farà riferimento a Script 1 il frammento di codice:

DECLARE @currentDBVersion BIGINT = NULL;

-- Get the current version of the database.
SELECT TOP 1 @currentDBVersion = Id FROM [internal].[DatabaseVersion] ORDER BY [DatabaseVersionId] DESC

-- Jump to the incremental migration scripts based on the current version.
IF @currentDBVersion = 1 GOTO Version11
ELSE IF @currentDBVersion = 2 GOTO Version12
ELSE
RETURN

Ora che ho illustrato la modalità di esecuzione di script di migrazione, unità consente la migrazione con alcuni scenari fittizi che consente di illustrare cosa accade in. Verranno descritte due modifiche di versione dal progetto di base creata in precedenza.

Versione 1.1: Questa è la prima modifica nella parte superiore del progetto di base che è stato creato. Le modifiche siano disponibili nel ramo v11 del progetto di migrazione dei dati continua su GitHub. Le modifiche è stato eseguito il commit in questa versione sono i seguenti:

• Inserire una nuova colonna IsEmployee [HumanResources]. [Employee] dopo la colonna JobTitle.
• Modificare [Person]. [AddressType] nome principale di Office a Microsoft Office.
• Stored procedure modificate (senza bisogno di includere nel progetto di migrazione).
• Nuova stored procedure (senza bisogno di includere nel progetto di migrazione).

Tutte queste modifiche sono apportate nel progetto regolari AdventureWorks.Database così com'è, insieme alla nuova riga di versione in interno. DatabaseVersion. Ciò facilita il qualsiasi nuova distribuzione per rendere effettive le modifiche più recenti. Per qualsiasi database esistente con la versione di base per l'aggiornamento a v 1.1, è necessario implementare le stesse modifiche nel progetto di migrazione. A tale scopo, suddivise in due sezioni: la modifica dello schema e la modifica dei dati. Inserimento di una nuova colonna denominata IsEmployee è una modifica dello schema, mentre la modifica di AddressType dall'ufficio principale in Office è una modifica dei dati.

La modifica dello schema è che possibile eseguire Visual Studio. Tuttavia, è possibile aggiungere solo la colonna e che è un elemento che non. Per superare questa limitazione, è necessario generare uno script per eliminare prima tutte le dipendenze (indici, vincoli, le chiavi esterne e così via) della tabella Employee e quindi creare una tabella temporanea con la nuova colonna nell'ordine corretto con tutte le dipendenze. Quindi, è possibile spostare i dati dalla tabella Employee per la tabella temporanea, eliminare la tabella dei dipendenti e infine rinominare la tabella temporanea al dipendente. Questo script è disponibile nel branch del progetto di migrazione dei dati continua su GitHub, nel file SchemaChangeScript.sql v11.

La modifica dei dati consente di modificare solo un valore del record dall'ufficio principale da Office e, pertanto, è possibile creare uno script una query di aggiornamento a tale scopo. Consente di estrarre il file DataChangeScript.sql nel branch del progetto di migrazione dei dati continua v11 su GitHub.

Quando il progetto di migrazione viene eseguito nella parte superiore di AdventureWorks.Database esistente, il codice di Script 1 invierà l'esecuzione di uno script che chiama lo schema e di modifica dei dati dello script, come illustrato nel frammento seguente, che chiameremo 2 Script:

-- Script to migrate to v1.1
Version11:
:r .\Scripts\Migration\V11\SchemaChangeScript.sql
:r .\Scripts\Migration\V11\DataChangeScript.sql

EXEC [internal].[CreateDatabaseVersion] @id = 2, @major = 1, @minor = 1, 
 @build = 0128, 
 @revision = 212

Versione 1.2: Si tratta della modifica più recente eseguito il commit nella parte superiore v 1.1. Le stesse modifiche sono disponibili nel branch del progetto in GitHub (V12). Le modifiche in questa versione sono come segue:

• Modificare IsEmployee in [HumanResources]. [Employee] per EmployeeType, che fa riferimento una tabella nuova a [HumanResources]. [EmployeeType].
• Stored procedure modificate (senza bisogno di includere nel progetto di migrazione).
• Nuova tabella (senza bisogno di includere nel progetto di migrazione).

Analogamente alla versione 1.1, ho anche apportate le modifiche nel progetto regolari AdventureWorks.Database insieme a una nuova voce interno. DatabaseVersion. Come si può notare, IsEmployee ora viene modificato in EmployeeType per supportare ulteriori tipi di dipendenti. A tale scopo, seguono lo stesso modello che nel v 1.1. Tuttavia, è necessario scrivere la migrazione dei dati per la nuova colonna in base al valore della colonna precedente. Lo script delle modifiche dello schema viene scritto nel file SchemaChangeScript.sql nel branch del progetto di migrazione dei dati continua v12 su GitHub.

Ecco lo script che è stata inclusa nel progetto per eseguire la migrazione alla versione 1.2, che chiameremo 3 Script:

-- Script to migrate to v1.2
Version12:
:r .\Scripts\Migration\V12\SchemaChangeScript.sql

EXEC [internal].[CreateDatabaseVersion] @id = 3, @major = 1, @minor = 2, 
 @build = 0414, 
 @revision = 096

Come accennato in precedenza, Visual Studio è parzialmente in grado di gestire una distribuzione incrementale, ma solo gli elementi che non dispone di Visual Studio con gli script che ho generato fino a questo punto di destinazione. Si può notare che per alcuni elementi in v 1.1 e 1.2, non detto "è necessario includere nel progetto di migrazione." Ciò avviene perché Visual Studio è in grado di distribuirli in modo incrementale. Quale chiedersi: Le modifiche risultanti per un progetto di migrazione e le modifiche non?

È possibile esaminare l'elenco informativo utile nel figura 5, che consente di decidere se generare lo script di migrazione o non. Si noti che potrebbero essere presenti più elementi che si trova in cui è stato possibile aggiungere a questo elenco.

Cambia	Valutazione
Nuova tabella/vista/stored procedure/oggetto	Utilizzare Visual Studio
Modificare nella vista/stored procedure/funzione	Utilizzare Visual Studio
Modifica nel tipo definito dall'utente	Eliminare tutte le stored procedure correlate dell'UDT. Si tratta di una soluzione per il bug descritto in precedenza.
Aggiunta della nuova colonna alla tabella	Una migrazione da una tabella esistente in una nuova tabella con l'ordine delle colonne corrette di script (vedere github.com/Jebarson/ContinuousDataMigration). Questo non è necessario se si aggiunge una colonna che ammette valori null e l'ordine della colonna è irrilevante.
Normalizzazione o la normalizzazione della tabella	Lo script una migrazione a split o merge in base al requisito. È simile allo script creato nella versione 1.2.
Modifica dei dati	Nello script la modifica dei dati.

 

Scheda elenco di riferimento di progetto di migrazione nella figura 5

OK, è sufficiente sulla generazione di script di migrazione. Ora per continuare con la distribuzione.

Quando si distribuisce una nuova istanza della versione più recente di un database esistente, non è necessario per la migrazione. Nell'esempio ho stato presentazione, è sufficiente per distribuire il AdventureWorks.Database. È possibile farlo da Visual Studio (tramite pubblicazione) o tramite SqlPackage.exe. Ecco il comando per la distribuzione del database tramite SqlPackage.exe:

SqlPackage.exe /Action:Publish /SourceFile:"AdventureWorks.Database.dacpac" /tdn:<<DatabaseName>> /tsn:"<<SQL Instance>>"

Quando si esegue una distribuzione incrementale in un database esistente, è probabile che lo script più recente sarà necessario una migrazione. Pertanto, che è necessario distribuire database di migrazione. Sarà tale scopo, la distribuzione del progetto di AdventureWorks.Database.Migration prima, seguita da AdventureWorks.Database. Assicurarsi che l'opzione "Ricrea sempre database" non è selezionata nell'area di distribuzione avanzate della finestra di dialogo Impostazioni di pubblicazione avanzate, come illustrato nella figura 6.

Figura 6 avanzate nella finestra di dialogo Impostazioni di pubblicazione

SqlPackage.exe /Action:Publish /SourceFile:"AdventureWorks.Migration.Database.dacpac" /tdn:<<DatabaseName>> /tsn:"<<SQL Instance>>" /p:CreateNewDatabase = False
SqlPackage.exe /Action:Publish /SourceFile:"AdventureWorks.Database.dacpac" /tdn:<<DatabaseName>> /tsn:"<<SQL Instance>>" /p:CreateNewDatabase = False

Problemi di migrazione comuni 3 e correzioni

Continua la migrazione dei dati può generare numerosi vantaggi, ma non senza i relativi problemi. Ecco alcuni problemi comuni desiderato potrebbero verificarsi durante l'implementazione di questa soluzione e modalità di risoluzione.

Questo errore nel progetto di migrazione, potrebbero verificarsi quando la versione recente di uno script di migrazione è rimosso un oggetto, ma fa riferimento l'oggetto in uno script di versione precedente. La soluzione consiste nello scrivere query come sp_executesql '<< il migrazione qui lo script >>.' Ad esempio:

EXEC sp_executesql 'ALTER TABLE Employee ADD NewCol INT'

Controllo degli script di migrazione e overload di versione:

È consigliabile impostare sempre una versione di destinazione minimo per la migrazione. In questo modo limita l'ambito degli script di migrazione e consente di assicurare che non diventino troppo difficile da gestire.

Implementazione di un database di produzione:

Nel caso in cui si desidera implementare la soluzione in un database che è già in produzione, includere la definizione di interno. DatabaseVersion e le voci di versione. Modificare il componente, vedere "Script 1" se la tabella interna. DatabaseVersion esiste e in caso contrario, indirizzare l'esecuzione all'etichetta di versione più recente, che consente di eseguire la migrazione e creare anche la tabella. Ad esempio:

DECLARE @currentDBVersion BIGINT = NULL;

-- Get the current version of the database.
IF NOT EXISTS(SELECT 1 FROM [INFORMATION_SCHEMA].[TABLES] WHERE [TABLES].
[TABLE_NAME]='DatabaseVersion' AND [TABLES].[TABLE_SCHEMA]='internal')
SELECT @currentDBVersion = 1
ELSE
SELECT TOP 1 @currentDBVersion = Id FROM [internal].[DatabaseVersion]
ORDER BY [DatabaseVersionId] DESC
-- Jump to the incremental migration scripts based on the current version.
IF @currentDBVersion = 1 GOTO Version11
ELSE IF @currentDBVersion = 2 GOTO Version12
ELSE
RETURN

Configurare la compilazione TFS per la distribuzione continua migrazione

L'obiettivo è quello di automatizzare le migrazioni come integrazione continua, in modo che il server di compilazione esegue la migrazione dei dati e rende disponibili per gli sviluppatori e tester dopo la compilazione viene attivata. Il passaggio successivo consiste nel configurare le attività di rilascio della compilazione.

Per creare attività per la compilazione, è necessario innanzitutto tenere di creazione di una build di integrazione continua. Se non si, assicurarsi di leggere l'esercitazione pubblicata nel sito di Microsoft Visual Studio all'indirizzo bit.ly/2xWqtUx.

Dopo aver creato le attività di compilazione, è necessario creare le attività di distribuzione per il database. In questo esempio, è necessario aggiungere due attività di distribuzione: uno per il progetto AdventureWorks.Database.Migration e l'altro per il progetto AdventureWorks.Database. L'attività di distribuzione avrà un aspetto simile figura 7.

Figura 7, l'attività di distribuzione

Compilare il dettaglio e impostare il trigger in base alle proprie esigenze. Dopo la compilazione sia in esecuzione verranno impostati una migrazione dei dati continua per l'applicazione.

Conclusioni

In questo articolo illustrato l'importanza della migrazione dei dati continua su un progetto che è suddivisa in più fasi di rilascio e come ottenere tramite Visual Studio e TFS. Migrazione dei dati continua consente di ridurre i bug di impegno e la migrazione sia lo sviluppo. Nella mia esperienza, sono stato in grado di ottenere quanto 40 percento dell'attività di migrazione in termini di sviluppo. Inoltre ottenuto rid della fase di migrazione del progetto.

Integrazione di script di migrazione a TFS è importante quanto gli stessi script di migrazione. Se non è distribuito come parte della compilazione giornaliera, il processo di migrazione di dati continui ha alcuna utilità. "Errore tempestivamente, esito negativo rapido" è il motto ricordare nello sviluppo del software, e la migrazione dei dati continua set fino a esattamente a tale scopo.

---

Jebarson Jebamony* è un consulente senior con Microsoft Services e schemi e le compilazioni di soluzioni di Microsoft, il relativo partner e clienti. Egli ha più di 14 anni di esperienza tecnica e ha lavorato su numerose tecnologie Microsoft in quel momento.*

Grazie ai seguenti esperti Microsoft per la revisione dell'articolo: Sagar Dheram e Shrenik Jhaveri

---

Viene illustrato in questo articolo nel forum di MSDN Magazine