November 2017

Band 33, Nummer 11

DevOps: Kontinuierliche Datenmigration mit Visual Studio und TFS

Von Jebarson Jebamony

Datenmigration ist häufig eine Anforderung in der Anwendungsentwicklung, und zwar unabhängig davon, ob es sich um ein Greenfield-Projekt oder die Überarbeitung eines Anwendungsentwurfs handelt. Dennoch wird der Datenmigration in der Entwurfs- und Entwicklungsphase kaum Beachtung geschenkt, sodass die Aktivitäten oft bis zum Ende des Projekts aufgeschoben werden. Dieser Ansatz könnte zwar eine ungeteilte Konzentration auf die Migration ermöglichen, birgt jedoch auch einige Risiken. Ein Risiko besteht darin, dass es den Teams an Zeit und Ressourcen fehlt, um die Migration und den damit verbundenen Code ordnungsgemäß zu testen.

Das Konzept der kontinuierlichen Datenmigration gründet auf der Idee, Migrationsskripts während der Entwicklung einer Anwendung zu entwickeln und diese ebenso wie den Anwendungscode in Versionen zu pflegen. Ein kontinuierlicher Migrationsansatz ermöglicht es Ihnen, Ihre Migrationen parallel zur Codeentwicklung zu testen, um sicherzustellen, dass Ihre Daten- und Coderessourcen synchron bleiben.

In diesem Artikel beschreibe ich eine Lösung, die Visual Studio und Team Foundation Server nutzt, um eine kontinuierliche Datenmigration zu erreichen. Denken Sie daran, dass Drittanbietertools wie Red Gate Ready Roll verfügbar sind, die diesen Vorgang teilweise übernehmen können. Sie sind aber mit enormen Kosten verbunden und verfügen nicht über die Fähigkeit zur kontinuierlichen Datenmigration.

Herausforderung und Lösung

Visual Studio kann eine inkrementelle Veröffentlichung einer Datenbank mit Hilfe von „SqlPackage.exe“ ausführen, aber das Tool ist in vielerlei Hinsicht unzureichend. Beispielsweise kann „SqlPackage.exe“ u. a. keine neue Spalte zwischen den Spalten einer Tabelle einfügen, keine Startwertdaten ändern und keine Tabellen normalisieren und denormalisieren.

Außerdem ist Versionsverwaltung ausgesprochen wichtig, wenn Sie gezielte Korrekturen und Bereitstellungen vornehmen müssen. Sie müssen z. B. den Wert einer Spalte ggf. um 10 erhöhen, wenn Sie von v1.2 zu v1.3 migrieren. Dies gilt aber für keinen anderen Datenfluss. Dies kann nur durch Versionsverwaltung erreicht werden. SQL verfügt jedoch nicht über diese Funktionalität.

Ich möchte die Herausforderung angehen, indem ich eine Lösung entwerfe, die die Möglichkeiten von Visual Studio und „SqlPackage.exe“ umfassend nutzt und gleichzeitig die oben genannten Mängel behebt.

Ein typisches Datenbankprojekt verwendet zwei Arten von Skripts: kompilierte und nicht kompilierte Skripts. Alle Objekte wie Schema, Tabellen, Ansichten, gespeicherte Prozeduren und ähnliche Elemente werden in der Regel als kompiliertes Skript geschrieben. Das Startwertskript und alle Laufzeitabfragen werden in der Regel in das Skript nach der Bereitstellung eingefügt, das nicht kompiliert wird.

Beginnen wir mit einem Beispiel. Abbildung 1 zeigt das Beispieldatenbankprojekt „AdventureWorks.Database“ (das aus der Sicherung importiert wurde, die unter bit.ly/2vPwu4N verfügbar ist). Wie Sie sehen können, werden alle Objekte als kompilierte Skripts eingefügt.

Abbildung 1: Kompilierte Skripts in „AdventureWorks.Database“

Das Startdatenskript (mit Daten, die benötigt werden, damit die Anwendung funktioniert) wird als nicht kompiliertes Skript verwendet. Auf dieses Skript wird aus dem Skript nach der Bereitstellung verwiesen. Abbildung 2 zeigt dies. Wenn Sie sich der Bedeutung von Skripts nach der Bereitstellung nicht bewusst sind, empfehle ich Ihnen, die Dokumentation in MSDN Library unter bit.ly/2w12Iy4 zu lesen.

Abbildung 2: Skripts nach der Bereitstellung

Um sicherzustellen, dass das Skript nach der Bereitstellung eine inkrementelle Bereitstellung verarbeiten kann, habe ich vor allen INSERT-Anweisungen eine NOT EXISTS-Klausel hinzugefügt. Beispiel:

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))

Aus Gründen der Einfachheit und Verwaltungsfreundlichkeit behalte ich für alle Startwertskripts die entsprechenden Dateien bei und verweise dann im Skript nach der Bereitstellung auf diese.

Ich verfüge jetzt über ein Projekt, das die neuesten Schema- und Startwertdaten zu jedem Zeitpunkt bereitstellen kann. Es ist auch in der Lage, eine inkrementelle Bereitstellung für eine vorhandene Datenbank auszuführen, wenn mit dem Projekt keine aktuellen Änderungen verbunden sind. Die Einschränkungen, die ich am Anfang dieses Abschnitts erwähnte, kommen nun jedoch ins Spiel.

Schließlich gibt es einen Fehler, der die inkrementelle Bereitstellung unterbricht, wenn ein benutzerdefinierter Typ (User-Defined Type, UDT) geändert wird. Leider hat das Visual Studio-Team diesen Fehler als nicht behebbar markiert. Dies bedeutet, dass Sie das Problem umgehen müssen. Weitere Details zu diesem Fehler finden Sie im Visual Studio Developer Community-Eintrag unter bit.ly/2w0zTBU.

Versionsverwaltung

Genau wie Sie für jede Anwendung, die Sie ausliefern, Versionsverwaltung verwenden, muss auch für die Datenbank unbedingt Versionsverwaltung verwendet werden. Die Versionsverwaltung unterstützt Sie dabei, den Quellcode nachzuverfolgen, sodass Sie die Features, Fehler und Korrekturen aus jedem Release der Software leicht im Auge behalten können. Wenn Sie mit Versionsverwaltung noch nicht vertraut sind, nehmen Sie sich einen Augenblick Zeit und lesen den Artikel „Semantic Versioning 2.0.0“ auf semver.org. Dieser Artikel ist wirklich lesenswert.

Bevor ich beginne, muss ich mich einer Herausforderung stellen: SQL bietet tatsächlich keinen Mechanismus für Versionsverwaltung. Daher muss ich einen eigenen Mechanismus erstellen. Ich erstelle eine Tabelle mit dem Namen „[internal].[DatabaseVersion]“, um die Versionsdetails zu speichern. Dabei ist „internal“ das Schema der Tabelle. Es ist empfehlenswert, ein separates Schema für alle Datenbankobjekte zu nutzen, die für interne Zwecke verwendet werden (also nicht geschäftsrelevant sind).

Abbildung 3 zeigt das Schema, das ich für die Tabelle vorschlagen würde. Sie können ein eigenes Muster verwenden, wenn dieses Sie nicht überzeugt. Denken Sie nur daran, dass wir Versionen erstellen, um Builds und Releases nachverfolgen zu können.

Abbildung 3: Tabellenschema

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

Jedes Mal, wenn ich eine Änderung am Schema vornehme oder ein Datenmigrationsskript einchecke, füge ich der Tabelle einen neuen Versionseintrag hinzu, der als Bezeichnung für die Änderung dient. Wenn die aktuelle Version 1.0.0.0 ist und ich eine Migration vornehme, die das Gender-Kennzeichnungsproblem durch Umkehrung der Werte behebt, füge ich entsprechende Skripts hinzu, um diese Änderung vorzunehmen. Außerdem füge ich der Tabelle einen neuen Eintrag mit der Version hinzu, der 1.1.0128.212 lautet.

Migration

Wie ich bereits erwähnt habe, kann Visual Studio inkrementelle Bereitstellungen ausführen, aber nicht mit aktuellen Änderungen. Wenn ich die Migration entwerfe, muss ich also daran denken und diese Einschränkung umgehen.

Der erste Schritt besteht darin, ein separates Projekt für die Migration zu erstellen. Für das Beispiel in Abbildung 3 erstelle ich ein neues Datenbankprojekt mit dem Namen „AdventureWorks.Database.Migration“. Dieses Migrationsprojekt verwendet zwei Arten von Skripts. Der erste Typ ist das Datenmigrationsskript, das ausgeführt werden muss, wenn eine Datenbewegung oder ein Update stattfindet. Das zweite Skript kümmert sich um aktuelle Schemaänderungen, die Visual Studio und „SqlPackage.exe“ nicht verarbeiten können. Beide Skripts gehen als Skript nach der Bereitstellung in das Projekt ein. Es gibt keine kompilierbaren Skripts in diesem Projekt.

Um das Szenario besser zu verstehen, untersuchen wir alle Aspekte im Zusammenhang mit dem AdventureWorks-Beispiel. Ich habe den Quellcode für das Beispiel in mein Git-Repository unter github.com/Jebarson/ContinuousDataMigration hochgeladen. Der Masterbranch enthält das Basisprojekt, das ich importiert und wie bereits erwähnt aus der Datenbank erstellt habe.

Bevor ich mich mit dem Szenario beschäftige, möchte ich erläutern, wie die Migration funktioniert. Wie ich im Abschnitt „Versionsverwaltung“ beschrieben habe, führe ich die Versionsverwaltung für jede einzelne freigegebene Änderung durch Hinzufügen einer neuen Zeile zu „internal.DatabaseVersion“ aus. Im AdventureWorks.Database.Migration-Projekt schreibe ich die Programmlogik zum Ausführen geeigneter Migrationsskripts basierend auf der Datenbankversion, die als Ziel dienen soll. Sehen Sie sich das Flussdiagramm in Abbildung 4 an, um sich mit der verwendeten Programmlogik vertraut zu machen.

Abbildung 4: Die Programmlogik für die Migration

Zu Beginn des AdventureWorks.Database.Migration-Projekts überprüfe ich die aktuelle Version der Datenbank und führe basierend auf dieser Angabe die Migrationsskripts bis zur neuesten Version aus. Hier ist der Codeausschnitt, den ich benutze, um den Migrationspfad zu bestimmen. Ich nenne ihn „Script 1“:

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

Nachdem ich nun gezeigt habe, wie die Migrationsskripts ausgeführt werden, sehen wir uns die Migration in einigen fiktiven Szenarien an, die zeigen, was geschieht. Ich werde zwei Versionsänderungen aus dem Basisprojekt erläutern, das ich zuvor erstellt habe.

Version 1.1: Dies ist die erste Änderung im Vergleich zum Basisprojekt, das ich erstellt habe. Die Änderungen sind im v11-Branch des Continuous Data Migration-Projekts auf GitHub verfügbar. Die folgenden Änderungen habe ich in dieser Version committed:

• Einfügen einer neuen IsEmployee-Spalte in „[HumanResources].[Employee]“ hinter der JobTitle-Spalte.
• Ändern des [Person].[AddressType]-Namens aus „Main Office“ in „Office“.
• Ändern von SPs (nicht im Migrationsprojekt erforderlich).
• Neue SPs (nicht im Migrationsprojekt erforderlich).

Alle diese Änderungen werden im regulären AdventureWorks.Database-Projekt wie vorliegend vorgenommen, und zwar zusammen mit der neuen Versionszeile in „internal.DatabaseVersion“. Dies ermöglicht jeder neuen Bereitstellung die Integration der neuesten Änderungen. Für jede vorhandene Datenbank mit der Basisversion, für die ein Upgrade auf v1.1 ausgeführt werden soll, muss ich die gleichen Änderungen in das Migrationsprojekt implementieren. Dazu trenne ich sie in zwei Abschnitte: die Schemaänderung und die Datenänderung. Das Einfügen einer neuen Spalte mit dem Namen „IsEmployee“ ist eine Schemaänderung, während das Ändern von „AddressType“ aus „Main Office“ in „Office“ eine Datenänderung ist.

Die Schemaänderung kann durch Visual Studio ausgeführt werden. Visual Studio kann aber nur die Spalte anfügen, und das möchte ich nicht. Um diese Einschränkung zu überwinden, muss ich ein Skript generieren, das zunächst alle Abhängigkeiten (Indizes, Einschränkungen, Fremdschlüssel und ähnliches) der Tabelle „Employee“ löscht und dann eine temporäre Tabelle mit der neuen Spalte in der richtigen Reihenfolge mit allen Abhängigkeiten erstellt. Dann kann ich die Daten aus der Tabelle „Employee“ in die temporäre Tabelle verschieben, die Tabelle „Employee“ löschen und schließlich die temporäre Tabelle in „Employee“ umbenennen. Dieses Skript ist im v11-Branch meines Continuous Data Migration-Projektes auf GitHub in der Datei „SchemaChangeScript.sql“ verfügbar.

Die Datenänderung ändert nur einen Wert des Datensatzes aus „Main Office“ in „Office“. Deshalb kann ich eine Aktualisierungsabfrage als Skript schreiben, um dies zu erreichen. Sie finden Sie Datei „DataChangeScript.sql“ im v11-Branch des Continuous Data Migration-Projekts auf GitHub.

Wenn das Migrationsprojekt über der vorhandenen „AdventureWorks.Database“ ausgeführt wird, sendet der Code aus „Script 1“ die Ausführung an ein Skript, das das Schema und das Datenänderungsskript aufruft. Dieses nenne ich „Script 2“. Der folgende Codeausschnitt zeigt dies:

-- 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

Version 1.2: Dies ist die neueste Änderung, die nach v1.1 committet wurde. Die gleichen Änderungen sind im v12-Branch des Projekts auf GitHub verfügbar. In dieser Version sind die folgenden Änderungen vorgenommen worden:

• Ändern von „IsEmployee“ in „[HumanResources].[Employee]“ in „EmployeeType“, Verweisen einer neuen Tabelle auf „[HumanResources].[EmployeeType]“.
• Ändern von SPs (nicht im Migrationsprojekt erforderlich).
• Neue Tabelle (nicht im Migrationsprojekt erforderlich).

Ähnlich wie in v1.1 habe ich auch Änderungen am regulären AdventureWorks.Database-Projekt zusammen mit einem neuen Eintrag in „internal.DatabaseVersion“ vorgenommen. Wie Sie sehen können, wurde „IsEmployee“ jetzt in „EmployeeType“ geändert, um mehr Mitarbeitertypen berücksichtigen zu können. Um dies zu erreichen, verfolge ich das gleiche Muster wie in v1.1. Ich muss jedoch die Datenmigration für die neue Spalte basierend auf dem Wert der früheren Spalte schreiben. Das Schemaänderungsskript wird in die Datei „SchemaChangeScript.sql“ im v12-Branch des Continuous Data Migration-Projekts auf GitHub geschrieben.

Hier ist das Skript, das ich in das Projekt für die Migration zu v1.2 aufgenommen habe. Ich nenne es „Script 3“:

-- 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

Wie ich bereits erwähnt habe, ist Visual Studio teilweise in der Lage, eine inkrementelle Bereitstellung zu steuern. Die Skripts, die ich bis zu diesem Punkt erstellt habe, beziehen sich aber nur auf die Aspekte, die Visual Studio nicht verarbeiten kann. Vielleicht haben Sie bemerkt, dass ich sowohl in v1.1 als auch in v1.2 für bestimmte Elemente angemerkt habe, dass sie „nicht im Migrationsprojekt erforderlich“ sind. Das liegt daran, dass Visual Studio sie inkrementell bereitstellen kann. Dies führt zu folgender Frage: Welche Änderungen eigenen sich überhaupt für ein Migrationsprojekt und welche nicht?

Sie können sich den praktischen „Spickzettel“ in Abbildung 5 ansehen, der Sie bei der Entscheidung unterstützt, ob Skripts für die Migration verwendet werden sollten. Beachten Sie, dass Sie ggf. weitere Elemente ermitteln, die dieser Liste hinzugefügt werden können.

Abbildung 5: „Spickzettel“ für das Migrationsprojekt

Diese Informationen zur Generierung der Migrationsskripts sollten ausreichend sein. Wenden wir uns jetzt der Bereitstellung zu.

Bei der Bereitstellung einer neuen Instanz der neuesten Version einer vorhandenen Datenbank ist keine Migration erforderlich. In dem Beispiel, das ich hier vorstelle, müssen Sie nur die „AdventureWorks.Database“ bereitstellen. Sie können diese Bereitstellung aus Visual Studio (über eine Veröffentlichung) oder mit „SqlPackage.exe“ vornehmen. Der folgende Befehl wird zum Bereitstellen der Datenbank mit „SqlPackage.exe“ verwendet:

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

Wenn Sie eine inkrementelle Bereitstellung über einer vorhandenen Datenbank ausführen, besteht die Möglichkeit, dass das neueste Skript eine Migration benötigt. Das bedeutet, dass ich auch die Migrationsdatenbank bereitstellen muss. Zu diesem Zweck implementiere ich zuerst das AdventureWorks.Database.Migration-Projekt, gefolgt von „AdventureWorks.Database“. Stellen Sie sicher, dass die Option „Datenbank immer neu erstellen” im Bereich „Erweiterte Bereitstellungsoptionen“ des Dialogfelds „Erweiterte Veröffentlichungseinstellungen“ (wie in Abbildung 6 gezeigt) deaktiviert ist.

Abbildung 6: Das Dialogfeld „Erweiterte Veröffentlichungseinstellungen“

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

Drei häufige Migrationsprobleme und ihre Korrekturen

Die kontinuierliche Datenmigration kann viele Vorteile mit sich bringen, aber sie bietet auch einige Herausforderungen. Im Folgenden werden einige häufig auftretende Probleme beschrieben, auf die Sie bei der Implementierung dieser Lösung möglicherweise stoßen, sowie Möglichkeiten, diese zu lösen.

Dieser Fehler kann im Migrationsprojekt auftreten, wenn Ihre aktuelle Version eines Migrationsskripts ein Objekt entfernt hat, auf das Objekt jedoch in einem früheren Versionsskript verwiesen wird. Die Lösung besteht darin, Abfragen als sp_executesql '<<Ihr Migrationsskript hier>>' zu schreiben. Beispiel:

EXEC sp_executesql 'ALTER TABLE Employee ADD NewCol INT'

Außer Kontrolle geratene Migrationsskripts und Versionsüberladung:

Es ist eine gute Idee, immer eine minimale Zielversion für die Migration festzulegen. Auf diese Weise wird der Bereich Ihrer Migrationsskripts eingeschränkt und sichergestellt, dass sie nicht zu schwierig zu verwalten sind.

Implementierung mit einer Produktionsdatenbank:

Falls Sie diese Lösung in einer bereits in Produktion befindlichen Datenbank implementieren möchten, sollten Sie die Definition von „internal.Database­Version“ und die zugehörigen Versionseinträge einbeziehen. Ändern Sie „Script 1“, um zu ermitteln, ob die Tabelle“internal.DatabaseVersion“ vorhanden ist. Wenn dies nicht der Fall ist, verweisen Sie die Ausführung auf die neuere Versionsbezeichnung, die die Migration ausführt und auch die Tabelle erstellt. Beispiel:

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

Konfigurieren des TFS-Builds für die Breitstellung kontinuierlicher Migration

Das Ziel ist es, Migrationen genauso zu automatisieren wie Continuous Integration, sodass der Buildserver die Datenmigration ausführt und sie Entwicklern und Testern zur Verfügung stellt, sobald der Build ausgelöst wird. Der nächste Schritt ist die Konfiguration der Releasetasks des Builds.

Um Tasks für den Build zu erstellen, sollten Sie sich zunächst darüber im Klaren sein, wie ein Continuous Integration-Build erstellt wird. Wenn dies nicht der Fall ist, sollten Sie unbedingt das Tutorial auf der Microsoft Visual Studio-Website unter bit.ly/2xWqtUx lesen.

Nachdem Sie die Buildtasks erstellt haben, müssen Sie die Bereitstellungstasks für die Datenbank erstellen. In diesem Beispiel müssen Sie zwei Bereitstellungstasks hinzufügen: einen für das AdventureWorks.Database.Migration-Projekt und einen für das AdventureWorks.Database-Projekt. Der Bereitstellungstask sieht ähnlich wie Abbildung 7 aus.

Abbildung 7: Der Bereitstellungstask

Ergänzen Sie die Details, und richten Sie den Trigger gemäß Ihren Anforderungen ein. Sobald der Build ausgeführt wird, haben Sie kontinuierliche Datenmigration für Ihre Anwendung eingerichtet.

Zusammenfassung

In diesem Artikel habe ich die Bedeutung der kontinuierlichen Datenmigration für ein Projekt erläutert, das mehrere Releasephasen umfasst, und gezeigt, wie dieses Ziel mit Visual Studio und TFS erreicht werden kann. Kontinuierliche Datenmigration unterstützt Sie dabei, den Entwicklungsaufwand und Migrationsfehler zu verringern. Meiner Erfahrung nach habe ich bei der Entwicklung bis zu 40 Prozent des Migrationsaufwands gewinnen können. Außerdem wurde die Migrationsphase im Projekt abgeschafft.

Die Integration von Migrationsskripts in TFS ist ebenso wichtig wie die Migrationsskripts selbst. Der Vorgang der kontinuierlichen Datenmigration ist nutzlos, wenn Sie ihn nicht als Teil des täglichen Buildvorgangs bereitstellen. „Scheitere früh und schnell“ ist das Mantra, das Sie sich bei der Softwareentwicklung einprägen müssen, und die kontinuierliche Datenmigration schafft genau dafür die Voraussetzungen.

Jebarson Jebamony ist Senior Consultant bei Microsoft Services und konzipiert und erstellt Lösungen für Microsoft, Partner und Kunden. Er verfügt über mehr als 14 Jahre technische Erfahrung und hat in dieser Zeit an vielen Microsoft-Technologien gearbeitet.

Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Sagar Dheram und Shrenik Jhaveri

Diesen Artikel im MSDN Magazine-Forum diskutieren