Nicht-triviale inkrementelle Änderungsbereitstellung mit Visual Studio-Datenbankprojekten

Question

Nehmen wir an, dass ich eine nicht-triviale Änderung an meiner Datenbank vornehme, die "benutzerdefinierte" Arbeit erfordert, um von Version A auf B zu aktualisieren. Zum Beispiel die Konvertierung der Benutzer-ID-Spalten vom Datentyp UUID in den Windows-Domänen-Benutzernamen.

Wie kann ich diese automatisch bereitstellen lassen? Das heißt, ich möchte es den Entwicklern ermöglichen, mit der rechten Maustaste auf das Projekt zu klicken, auf "Bereitstellen" zu klicken und diese Logik ausführen zu lassen, wenn sie eine ausreichend alte Datenbank verwenden.

Ich sehe keinen Platz für eine solche Anmeldung in Datenbankprojekten - es scheint keine Bestimmung für solche "Upgrade-Skripte" zu geben. Ist dies wirklich nicht möglich? Zur Klarstellung: Die Logik kann natürlich nicht automatisch generiert werden, aber ich möchte, dass sie bei Bedarf automatisch ausgeführt wird.

Das erste logische Hindernis wäre natürlich, dass das Bereitstellungsprogramm nicht weiß, ob eine solche Logik aktualisiert werden muss - ich würde annehmen, dass ich auch die Logik dafür bereitstellen könnte (z. B. eine Versionstabelle prüfen und, wenn die letzte Version <5.0 ist, dieses Upgrade durchführen und später eine neue Versionszeile hinzufügen).

Ist dies möglich? Kann ich eine vollautomatische Bereitstellung mit komplexen benutzerdefinierten Änderungsskripten durchführen? Ohne dass ich meine gesamte benutzerdefinierte Änderungslogik in die (bald) riesigen Pre- oder Post-Build-Skripte einfügen muss, natürlich...

Answer 1

Sie können die installierte Version in der Tat überprüfen, wenn Sie Ihre Datenbank während der Bereitstellung als Anwendung der Datenebene registrieren. Sie können dies tun, indem Sie das Folgende in Ihr Veröffentlichungsprofil aufnehmen:

    <RegisterDataTierApplication>True</RegisterDataTierApplication>

Mit dieser Option wird das Schema und seine Versionsnummer während der Bereitstellung in der msdb-Datenbank registriert. Achten Sie darauf, die Dacpac-Versionsnummer zwischen verschiedenen Versionen zu ändern! Wir verwenden msbuild zur Erstellung von dacpacs, Beispielcode für die Einstellung der dacpac-Version:

DacVersion=$(ProjectReleaseNumber).$(ProjectBuildNumber).$(ProjectRevisionNumber)

Danach können Sie Skripte für die vorzeitige Bereitstellung mit Versionskontrolle erstellen.

-- Get installed version, e.g. 2.3.12309.0
DECLARE @InstalledVersion NVARCHAR(64) = (
    SELECT type_version
    FROM msdb.dbo.sysdac_instances
    WHERE instance_name = DB_NAME()
);
-- Get the major part of the version number, e.g. 2
DECLARE @InstalledVersionMajor TINYINT = CONVERT(TINYINT, SUBSTRING(@InstalledVersion, 0, PATINDEX('%.%', @InstalledVersion)));

IF (@InstalledVersionMajor < 5)
BEGIN;
    PRINT 'Do some nontrivial incremental change that only needs to be applied on version before 5';
END;

Die Überprüfung der Versionsnummer, die Sie gerade einsetzen, ist etwas mühsamer, kann aber ebenfalls durchgeführt werden. Diese Technik finden Sie in Jamie Thomsons hervorragendem Blog: Bearbeiten von sqlcmdvariable-Knoten in SSDT-Publish-Profile-Dateien mit msbuild

Answer 2

Ehrlich gesagt, ist die beste Option dafür das Konzept der Datenbankmigrationen, das aus der Ruby-Welt stammt, wenn ich mich nicht irre. Ich habe ein Framework namens Migrator.Net in meinen Anwendungen, aber es gibt eine Reihe wirklich guter Programme (mit unterschiedlichem Aktivitätsgrad), die im Grunde das Gleiche tun. Eine schnelle Google-Suche ergibt ziemlich viele .