Weryfikowanie opublikowanego pakietu SSIS

SSIS Check Deployment Feature Image

SQL Server Integration Services od wersji SQL Server 2012 pozwala na korzystanie z “Project Deployment Model”, który umożliwia wygodne publikowanie pakietów na serwer. Korzystając z tego modelu wszystkie pakiety w jednym projekcie są kompilowane do jednego pliku wynikowego (ISPAC) i następnie mogą zostać opublikowane do SSIS Catalogu, lub mówiąc konkretnie do bazy danych SSISDB (od wersji SQL Server 2016 istnieje również możliwość publikacji pojedynczych pakietów). Samą publikację można przeprowadzić za pomocą Visual Studio, narzędzia ISDeploymentWizard, SQL Server Management Studio, ale także za pomocą T-SQL, Powershell czy bibliotek dla platformy .NET. Liczba dostępnych metod oraz łatwość użycia sprawiają, że publikowanie nie jest trudne i łatwo go zautomatyzować za pomocą własnych skryptów lub korzystając z gotowych rozwiązań jak TeamCity.

Niekiedy zdarza się jednak, że coś pójdzie nie tak. W przypadku gdy z jakichkolwiek powodów publikacja się nie powiedzie, zostanie przerwana i zostanie zwrócony błąd sprawa jest oczywista. Zdarza się jednak, że projekt zostanie opublikowany, natomiast jego uruchomienie świadczy o tym, że na serwerze znajduje się jego stara lub niewłaściwa wersja. Na taki problem można trafić między innymi w sytuacji, kiedy za pomocą TeamCity próbujemy opublikować projekt, który wcześniej został cofnięty do poprzedniej wersji w TFS. Niestety TeamCity w takiej sytuacji czasami miewa problemy z wybraniem właściwego brancha i przy braku uwagi może to spowodować opublikowania niewłaściwej wersji pakietu. Co więcej w takim przypadku zobaczymy w SSIS Catalog, że pojawiła się nowa wersja, natomiast niekoniecznie będzie to wersja właściwa. W sytuacji manualnego publikowania błąd ludzki oczywiście też nie jest wykluczony. W celu uniknięcia ewentualnych problemów można skorzystać z kilku metod, które pozwolą nam zweryfikować jaka wersja projektu/pakietu znajduje się na serwerze. Zarówno w przypadku automatyzacji i Continiuus Integration jak i w przypadku ręcznej publikacji dodatkowa weryfikacja może okazać się bardzo pomocna i może zmniejszyć niebezpieczeństwo ewentualnych błędów.

Najprostszą metodą, aby sprawdzić co właściwie zostało opublikowane jest skorzystanie z Visual Studio. Wybierając kolejno File > New > Project > Templates > Business Intelligence > Integration Services będziemy mogli skorzystać z szablonu “Integration Services Import Project Wizard”, który umożliwi nam pobranie projektu z SSIS Catalogu (bazy danych SSISDB).

This slideshow requires JavaScript.

Za pomocą konfiguratora wystarczy połączyć się do SSIS Catalogu oraz wybrać projekt, który chcemy zaimportować. Korzystając z tej metody możemy po prostu otworzyć pakiet, który ostatnio był modyfikowany i sprawdzić czy jego wersja odpowiada tej, która powinna znaleźć się na serwerze.

Inne metody korzystają z faktu, iż każda zmiana w projekcie powoduje zmianę w metadanych tego pakietu, w tym wartości DTS:VersionBuild. Na marginesie warto zauważyć, że mimo nazwy numer generowany jest w chwili zapisu projektu, a nie jego budowania. Ponadto w metadanych znajdziemy również, między innymi, DTS:VersionGUID, natomiast dla celów tego postu jest on zupełnie nieistotny, gdyż jego wartość ulegnie zmianie w chwili publikacji, ale nawet w chwili każdorazowego jego uruchomienia (do sprawdzenia w SSISDB). Warto również nadmienić, że “VersionBuild” dotyczy pojedynczego pakietu i każdy pakiet ma różne wartości zgodnie z ilością zmian. Wartości te można odczytać wyświetlając kod źródłowy pakietu.

Początek kodu źródłowego będzie podobny do tego:

Korzystając z tej informacji, po zaimportowaniu projektu tak jak wyżej, zamiast szukać odpowiedniej zmiany w pakiecie wystarczy porównać wersję pakietu z serwera z wersję pakietu w projekcie.

Dzięki tej informacji można również sprawdzić aktualną wersję pakietu na serwerze bez jego pobierania, gdyż metadane pakietów zostają zapisywanie w bazie SSISDB. W celu weryfikacji wystarczy zatem wykorzystać odpowiednie zapytanie na tej bazie.

Rezultatem zapytania będzie:

Idąc o krok dalej możemy zautomatyzować naszą weryfikację. Po pierwsze za pomocą PowerShell jesteśmy w stanie porównać dwa projekty na osobnych instancjach SQL Server.

Skrypt porówna wszystkie pakiety oraz ich wersję dla konkretnych projektów w konkretnych folderach pomiędzy dwiema instancjami SQL Server.

Innym przykładem może być porównanie wersji pakietów z plików, w tym przypadku plików znajdujących się wewnątrz pliku ISPAC, z wersją pakietów znajdującymi się na serwerze.

Skrypt na samym początku wypakuje zawartość pliku ISPAC do tymczasowego folderu, następnie po kolei przeczyta wszystkie pakiety i zapisze do kolekcji wersje pakietów. W końcu pobierze dla konkretnego folderu i konkretnego projektu wersje pakietów i porówna je z tymi z ISPAC.

SQL Server Integration Services dostarcza szereg możliwości do publikowania projektu, które są stosunkowo proste i zwykle niezawodne. Z racji faktu, że jednak czasami błędy się zdarzają i istnieje ryzyko opublikowania niewłaściwego projektu, dobrym pomysłem wydaje się wprowadzenie do procesu publikowania zmian projektu SSIS ((Request for change – RFC)) dodatkowego etapu z weryfikacją. Jak widać na powyższych przykładach, możliwości takiej weryfikacji jest wiele i może być ona ręczna albo w pełni automatyczna.

 

Slawomir Drzymala
Follow me on

Slawomir Drzymala

Still playing with data and .NET technologies
Slawomir Drzymala
Follow me on

Leave a Comment

Your email address will not be published. Required fields are marked *