Niemalwialne wdrożenie zmiany przyrostowej z projektami bazy danych Visual Studio

Question

Załóżmy, że dokonuję jakiejś nieprywatnej zmiany w mojej bazie danych, która wymaga "niestandardowej" pracy w celu aktualizacji z wersji A do B. Na przykład konwertowanie kolumn identyfikatora użytkownika z Typ danych UUID do nazwy użytkownika domeny Windows.

Jak mogę to zrobić automatycznie? To znaczy, chcę pozwolić programistom na kliknięcie prawym przyciskiem myszy projektu, kliknięcie "Wdróż" i wykonanie tej logiki, jeśli używają wystarczająco starej bazy danych.

Nie widzę żadnego miejsca na takie logowanie w projektach baz danych - nie wydaje się, żeby istniały jakiekolwiek rezerwy na takie "skrypty aktualizacyjne". Czy to naprawdę nie jest możliwe? Aby wyjaśnić, logiki nie można oczywiście generować automatycznie, ale chcę, aby była wykonywana automatycznie, w razie potrzeby.

Pierwszą logiczną przeszkodą będzie oczywiście to, że narzędzie do wdrażania nie będzie wiedzieć, czy taka logika musi zostać zaktualizowana - zakładam, że mogę podać logikę tego również (np. Sprawdź tabelę wersji a jeśli najnowsza wersja to < 5.0, należy wykonać to uaktualnienie, a następnie dodać nowy wiersz wersji).

Czy to możliwe? Czy mogę w pełni zautomatyzować wdrażanie za pomocą złożonych niestandardowych skryptów zmian? Bez konieczności wrzucania całej mojej logiki zmiany niestandardowej do (wkrótce będzie) ogromnych skryptów przed- lub pocztowych, oczywiście ...

Answer 1

Szczerze mówiąc, najlepszym rozwiązaniem jest wykorzystanie koncepcji bazy danych migracje, które przyszły ze świata Ruby, jeśli się nie mylę. W moich aplikacjach korzystałem z frameworka o nazwie Migrator.Net, ale jest kilka naprawdę dobrych (o różnym poziomie aktywności), które w zasadzie robią to samo. Szybka wyszukiwarka Google pojawia się quite a few.

Answer 2

Naprawdę można sprawdzić zainstalowaną wersję, jeśli rejestrujesz swoją bazę danych jako aplikację warstwy danych podczas wdrażania. Można to zrobić poprzez włączenie następujących w swoim profilu publikowania:

<RegisterDataTierApplication>True</RegisterDataTierApplication> 

Ta opcja zarejestruje schemat i jest to numer wersji w bazie danych msdb podczas wdrożenia. Pamiętaj, aby zmienić numer wersji dacpac między wersjami! Używamy msbuild stworzyć dacpacs, przykładowy kod do ustawiania wersję dacpac:

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

Uczyniwszy to, można zbudować wersji świadomy przed wysunięciem skrypty.

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

Sprawdzanie numeru wersji, która jest aktualnie wdrażana, jest nieco bardziej uciążliwe, ale można również zrobić. Zobacz doskonałego bloga Jamie Thomson dla tej techniki: Editing sqlcmdvariable nodes in SSDT Publish Profile files using msbuild