Power BI Deployment Pipelines (preview) – nowy sposób na wdrażanie raportów

O tym, że procesy continuous integration oraz continuous deployment (CICD) stanowią coraz bardziej istotną i popularną metodę wdrażania rozwiązań informatycznych pomiędzy środowiskami deweloperskimi, a produkcyjnymi raczej nie trzeba mówić. Tego typu podejście nie tylko usprawnia sam proces wdrażania, ale również w połączeniu z różnego rodzaju testami automatycznymi pozwala w dużej  mierze ograniczyć błędy występujące w naszym rozwiązaniu. W przypadku Power BI mieliśmy kilka rozwiązań pozwalających na przerzucanie pliku pbix pomiędzy różnymi workspace’ami czy to z użyciem API czy też wykorzystując chociażby Azure Pipelines, rozwiązania te jednakże pomagały pokonać jedynie część problemów związanych z deploymentem. W tym miejscu pojawiają się nowe możliwości skrywające się pod nazwą Power BI Deployment Pipelines. Funkcjonalność ta będąca aktualnie w fazie preview pozwala na intuicyjne przerzucanie raportów pomiędzy workspaceami z dodatkową ich parametryzacją. Sprawdźmy jak to wszystko działa w praktyce – zapraszam.

Opisywana funkcjonalność może być testowana na serwisie Power BI gdzie po zalogowaniu po lewej stronie w menu głównym możemy zobaczyć interesującą nas opcję:

Jak już wspomniałem Deployment pipelines pozwala nam usprawnić sposób przerzucania raportów, zestawów danych oraz dashboardów pomiędzy workspace’ami dlatego też zanim przejdziemy do samych testów przygotujemy workspace, które nazwałem SEEQUALITY – DEV. W naszym przypadku testowym będziemy łączyć się do bazy danych SQL Server. Warto tutaj wskazać, że tak naprawdę będziemy mieli dwie bazy jedną deweloperską, a jedną produkcyjną. Ich definicja jest bardzo prosta i wygląda następująco:

CREATE DATABASE Development
GO

USE Development
GO

CREATE TABLE Sales
(
ID		BIGINT IDENTITY,
Product		NVARCHAR(50),
Category	NVARCHAR(50),
Color		NVARCHAR(50),
SalesDate	DATE,
Customer	NVARCHAR(50),
Quantity	INT,
UnitPrice	DECIMAL(18,2),
SalesAmount AS Quantity * UnitPrice
)
GO

INSERT INTO Sales
(
 Product	
,Category
,Color	
,SalesDate
,Customer
,Quantity
,UnitPrice
)
VALUES
	(
		 'Road Bike'
		,'Bike'
		,'Black'
		,'20200528'
		,'John Doe'
		,1
		,1000
	),
	(
		 'Road Bike'
		,'Yellow'
		,'Black'
		,'20200529'
		,'John Doe'
		,1
		,1200
	)
GO

CREATE DATABASE Production
GO

USE Production
GO

CREATE TABLE Sales
(
ID			BIGINT IDENTITY,
Product		NVARCHAR(50),
Category	NVARCHAR(50),
Color		NVARCHAR(50),
SalesDate	DATE,
Customer	NVARCHAR(50),
Quantity	INT,
UnitPrice	DECIMAL(18,2),
SalesAmount AS Quantity * UnitPrice
)
GO

INSERT INTO Sales
(
 Product	
,Category
,Color	
,SalesDate
,Customer
,Quantity
,UnitPrice
)
VALUES
	(
		 'Road Bike'
		,'Bike'
		,'Red'
		,'20200501'
		,'Bill Gates'
		,1
		,1000
	),
	(
		 'Fancy Helmet'
		,'Helmet'
		,'Pink'
		,'20200520'
		,'Steve Ballmer'
		,1
		,200
	)
GO

W powyższym skrypcie widzimy, że w środowisku deweloperskim mamy dwie transakcje, których dokonał John Doe. W środowisku produkcyjnym mamy po jednej transakcji Steve’a Ballmera oraz Billa Gatesa. Na podstawie środowiska deweloperskiego stworzyłem bardzo prosty raport pokazujący zestawienie sprzedaży:

Ten prosty raport wrzuciłem do  stworzonego wcześniej workspace. Mając to wszystko przygotowane przejdźmy do meritum i stwórzmy nasz pierwszy pipeline. Po przejściu do zakładki Deployment Pipelines przywita nas krótka informacja jak wystartować z tą funkcjonalnością:

Powyższy opis wskazuje tak jak powinniśmy się spodziewać , że musimy stworzyć pipeline, przypisać do niego określony workspace, stworzyć i przetestować raporty, a następnie udostępnić je użytkownikom. Zacznijmy zatem od stworzenia pipeline poprzez kliknięcie przycisku Create a pipeline widocznego na powyższym zrzucie ekranowym. Pierwszy krok nie powinien przysporzyć nam problemów i sprowadza się do nadania nazwy i opcjonalnego opisu:

W dalszym kroku jest nieco ciekawiej gdyż możemy wskazać, który workspace ma być deweloperski, a który produkcyjny:

Na moment pisania niniejszego artykułu mamy trzy możliwe “środowiska” i nie można tego zmienić. Przypiszmy zatem workspace poprzez kliknięcie widocznego powyżej przycisku Assign a workspace:

Powyższe okienko również nie powinno sprawić problemów i wystarczy, że wskażemy workspace oraz to czy jest on deweloperski, testowy czy też produkcyjny. Warto tutaj zauważyć, że jeśli wybierzemy typ “Development” to następnie będziemy mogli stworzyć nowy workspace testowy i deweloperski z poziomu pipeline’a. Jeśli natomiast wybierzemy typ “Production” to będziemy mogli stworzyć workspace testowy i deweloperski i tak dalej. W tym miejscu warto zaznaczyć kilka rzeczy jeśli chodzi o to jaki workspace może być używany w ramach pipeline bo są pewne wymogi:

• musi to być nowy typ workspace (czyli tzw. new workspace experience),
• workspace musi być przypisany do dedicated capacity czyli musimy posiadać licencję premium,
• workspace nie może być przypisany do innego pipeline,
• jeżeli nasz workspace ma sample raportów wbudowanych w Power BI to nie może być deployowany w ramach Deployment Pipelines.

Po przypisaniu workspace dostałem informacje jaka zawartość znajduje się we wskazanym workspace. Dodatkowo z tego miejsca mogę opublikować aplikację opartą właśnie na tym deweloperskim workspace (Publish app) lub też przerzucić jego zawartość do workspace testowego (Deploy to test):

Ciekawa informacja pojawiła się przy “środowisku” testowym oraz produkcyjnym – chodzi mianowicie o fakt, że workspace odpowiadający danemu środowisku zostanie stworzony podczas deploymentu. Czyli reasumując na ten moment możemy przypisać tylko jedno ze środowisk, a pozostałe (za pierwszym razem) zostaną stworzone automatycznie podczas deploymentu. Przerzućmy zatem dane z Development na Test klikać widoczny powyżej przycisk Deploy to test. Po krótkiej chwili wszystko jest gotowe:

Zielony symbol pomiędzy środowiskami symbolizuje to, że są one ze sobą zsynchronizowane. Dodatkowo dla nowego środowiska również możemy opublikować aplikację. Nowopowstały workspace dostał nazwę taką samą jak ten na Dev tylko, że z dopiskiem [Test] co nie do końca wpisuje się w moją konwencję nazewniczą dlatego zmienię jego nazwę na SEEQAULITY – TEST, a zrobiłem to oczywiście z apletu Workspace settings do którego możemy się dostać bezpośrednio z pipeline’a:

Przejdźmy dalej i przerzućmy dane na produkcję klikając Deploy to production. Kolejny workspace został stworzony i tym razem jego nazwę w analogiczny sposób jak powyżej zmieniłem na SEEQUALITY – PRD. Tym razem jednak na środowisku produkcyjnym zmieńmy nieco ustawienia – posłuży nam do tego ikona dostępna w prawym górnym rogu naszego środowiska (analogiczne ustawienia mamy dostępne również na środowisku testowym jednak my zrobimy to jedynie na produkcji):

Po jej kliknięciu możemy zdefiniować pewne reguły np. ustawić wartość parametru dla tego tylko workspace lub zmienić źródło danych.

Ustawienie to sprowadza się do:

• wybrania data setu dla którego chcemy nadpisać ustawienia,
• kliknięcia Add rule,
• wskazania źródła danych lub parametru dla którego chcemy nadpisać ustawienia.

W naszym przykładzie przełączyłem bazę danych z “development” na production, a następnie opublikowałem aplikację. Dzięki tej funkcjonalności przy przerzucaniu struktur między środowiskami nie będę musiał za każdym razem pilnować wartości parametrów czy też połączenia ze źródłem gdyż zrobi to za mnie Deployment Pipelines. Ze względu na fakt, iż do uwierzytelnienia ze źródłem używałem SQL Server authentication oraz gateway’a musiałem wejść do nowego workspace produkcyjnego i wskazać jaki gateway ma być użyty oraz login i hasło jakiego Power BI ma użyć jednak dobrze byłoby móc tym sterować z poziomu pipeline’a (wymarzonym scenariuszem byłaby możliwość podpięcia tutaj Azure Key Vault na co bardzo liczę). Z poziomu pipeline możemy również dane odświeżyć co też zrobiłem:

Po otwarciu aplikacji zauważyłem, że dane pochodzą z bazy Production czyli dokładnie tak jak to zakładałem:

Co natomiast się stanie w momencie jak coś zmienimy w raporcie i od nowa wrzucimy go na środowisko deweloperskie? Opisywany mechanizm wykryje zmiany i będziemy mogli przerzucać obiekty między workspace’ami. Dla przykładu zmodyfikowałem nieco warstwę frontend na raporcie podmieniając kolor dostępnych tam kart:

Dodatkowo możemy wykonać kilka dowolnych zmian w modelu aby zobrazować również zmiany datasetu. Po opublikowaniu raportu do workspace możemy zobaczyć, że pipeline automatycznie wykrył zmiany i daje nam możliwość wrzucenia na pozostałe środowiska:

 

Jeśli chcemy przerzucić tylko określone obiekty np. wybrany raport to oczywiście możemy zaznaczyć tylko ten jeden wybrany obiekt i kliknąć deploy. Analogicznie ma się sytuacja z przerzucaniem ze środowiska testowego na produkcyjne. Patrząc na dokumentację słowem uzupełnienia warto wspomnieć, które tak naprawdę właściwości są kopiowane, a które nie.

Kopiowane są:

• źródła danych,
• parametry,
• raporty
• dashboardy,
• metadane modelu,
• relacje między obiektami.

Nie są kopiowane:

• dane,
• adres URL oraz identyfikator,
• dostępy zarówno do workspace jak i przypisanie do poszczególnych ról,
• ustawienia workspace’a
• Power BI app,
• dane uwierzytelniające do źródeł,
• ustawienia Query cache,
• ustawienia Endorsment.

Warto również wspomnieć, że poniższe elementy również nie mogą być przerzucane poprzez Deployment Pipelines:

• Paginated Reports,
• Dataflows,
• PUSH datasets,
• Workbooks

Jest jeszcze kilka ograniczeń o których nie będę pisał ze względu na fakt, iż część z nich może się zmienić zainteresowanych odsyłam do dokumentacji.

Na sam koniec warto wspomnieć o jednej bardzo ważnej rzeczy – chodzi mianowicie o dostęp do Deployment Pipelines poprzez API. Na ten moment go nie ma ale moim zdaniem coś takiego się pojawi albo w finalnej wersji albo w niedługim czasie po wyjściu funkcjonalności z fazy preview. Z całą pewnością byłoby to wskazane żeby móc napisać sobie skrypt, który będzie w stanie uruchomić pipeline, opublikować aplikację itd, a następnie móc go wpleść np. w Azure Pipelines.

Nie pozostaje nam nic innego jak trzymać kciuki za ulepszenia i cieszyć się z udostępnionej funkcjonalności która z całą pewnością jest krokiem w dobrą stronę.