Kurs Power BI: Deployment pipelines: dev, test, prod (ALM)

W skróciePotok wdrażania (deployment pipeline) wstawia między autora raportu a odbiorców etapy kontroli: zmiana trafia najpierw do Testu, a na Produkcję dopiero po sprawdzeniu. Na raporcie Nordvelli ustawiamy parametr ścieżki pliku, wdrażamy między etapami Programowanie, Test i Produkcja, dodajemy reguły wdrażania i przeglądamy historię.

Do tej pory raport Nordvelli budowaliśmy w Power BI Desktop i publikowaliśmy prosto do obszaru, z którego korzysta zarząd. To działa, dopóki każda zmiana jest bezbłędna. Wystarczy pomyłka w mierze marży albo zła ścieżka do pliku i kierownicy sklepów rano oglądają złe liczby albo puste karty. Potok wdrażania (ang. deployment pipeline) wstawia między autora raportu a odbiorców dwa etapy kontroli: zmiana trafia najpierw do Testu, a na Produkcję dopiero po sprawdzeniu.

W tym rozdziale przechodzimy całą drogę na potoku Nordvella ALM (ALM to ang. Application Lifecycle Management, zarządzanie cyklem życia raportu): parametr ze ścieżką do arkusza, publikacja do obszaru Nordvella Dev, wdrożenie do Testu i na Produkcję, reguły wdrażania, które dają każdemu etapowi własny plik, poprawka sprawdzona w przeglądzie zmian, historia wdrożeń, zapis projektu w plikach tekstowych dla Git i uprawnienia. Każdy krok nagraliśmy w usłudze Power BI i w Power BI Desktop.

Po co potok wdrażania: trzy etapy zamiast jednego obszaru

Co chcemy osiągnąć. Każda zmiana w raporcie ma przejść przez Test, zanim zobaczy ją zarząd.

Potok wdrażania to element usługi Power BI, który łączy kilka obszarów roboczych w łańcuch etapów. U nas są trzy: Programowanie, Test i Produkcja. Do Programowania publikujesz z Desktopu tak jak dotąd. Do Testu i na Produkcję nie publikujesz z pliku nigdy: model i raport przenosi potok, przyciskiem Wdróż, z porównaniem różnic i notatką.

Ścieżki wskazują pliki na komputerze z bramą osobistą z lekcji 24. U nas to trzy kopie tego samego arkusza, więc liczby na wszystkich etapach są takie same. W firmie Test dostaje zwykle kopię z danymi testowymi, a Produkcja plik, który na bieżąco uzupełnia dział sprzedaży.

Plik gotowy do potoku: parametr SciezkaPliku, nowa miara i publikacja do Dev

Co chcemy osiągnąć. Ścieżka do arkusza ma być parametrem, który potok może podmienić, a model ma trafić do obszaru Nordvella Dev.

Otwórz plik z końca lekcji 22. Wszystkie dziewięć zapytań czyta arkusz ze stałej ścieżki C:\Kurs_PBI\Nordvella_dane.xlsx. Reguła wdrażania nie zmieni tekstu wpisanego na sztywno w kod M, potrafi za to podmienić wartość parametru. Parametry Power Query znasz z lekcji 5.

Parametr SciezkaPliku

1. Na karcie Narzędzia główne kliknij Przekształć dane. Otworzy się edytor Power Query.
2. Kliknij Zarządzaj parametrami, potem Nowy.
3. Wpisz nazwę SciezkaPliku i opis, u nas: Ścieżka do arkusza Nordvella_dane.xlsx. Reguła potoku wdrażania podmienia ją na etapach Test i Prod.
4. Zostaw zaznaczone Wymagane, typ Tekst i sugerowane wartości Dowolna wartość. W polu Wartość bieżąca wpisz C:\Kurs_PBI\Nordvella_dane.xlsx i kliknij OK.

Teraz podmień ścieżkę we wszystkich zapytaniach naraz. Nie musisz otwierać każdego z nich: dla Power Query ten arkusz to jedno źródło danych, a źródło zmienisz w jednym oknie.

1. Na karcie Narzędzia główne edytora kliknij Ustawienia źródła danych.
2. Zaznacz źródło z plikiem Nordvella_dane.xlsx i kliknij Zmień źródło.
3. W oknie Skoroszyt programu Excel, przy polu Ścieżka pliku, przełącz ikonę z wartości tekstowej na parametr i wybierz SciezkaPliku. Kliknij OK, potem Zamknij.

Kliknij zapytanie FaktSprzedaz i krok Źródło. Pasek formuły pokazuje parametr w miejscu ścieżki. Tak samo wygląda pierwszy krok pozostałych ośmiu zapytań, od DimKalendarz do FaktZwroty. Parametr jest na liście zapytań, z bieżącą wartością w nawiasie.

Źródło = Excel.Workbook(File.Contents(SciezkaPliku), null, true)

Kliknij Zamknij i zastosuj. Desktop wczyta tabele z tego samego pliku, więc liczby w raporcie się nie zmieniają.

Miara Marża po zwrotach %

Dodajemy jeszcze jedną miarę, żeby było co wdrażać. Marża % z wcześniejszych lekcji nie uwzględnia zwrotów. Nowa miara odejmuje od marży wartość zwrotów z tabeli FaktZwroty. Kliknij tabelę FaktSprzedaz w panelu Dane, wybierz Nowa miara i wpisz:

Marża po zwrotach % = VAR MarzaBrutto = SUM ( FaktSprzedaz[MarzaNetto] )
VAR StrataZwrotow = ABS ( SUM ( FaktZwroty[WartoscZwrotu] ) )
VAR SprzedazNetto = SUM ( FaktSprzedaz[WartoscNetto] )
RETURN
    DIVIDE ( MarzaBrutto - StrataZwrotow, SprzedazNetto )

Zmienna StrataZwrotow ma ABS, bo kwoty w kolumnie WartoscZwrotu są ujemne: suma zwrotów w arkuszu to -14 022 095,44 zł. Bez ABS odejmowanie liczby ujemnej podniosłoby wynik do 19,45%, wyżej niż marża przed zwrotami. Z ABS wynik to 13,46%, wobec 16,46% dla Marży %.

Publikacja do obszaru Nordvella Dev

1. Zapisz plik (Ctrl+S).
2. Na karcie Narzędzia główne kliknij Publikuj.
3. Wybierz obszar Nordvella Dev i kliknij Wybierz.

W obszarze pojawiają się dwa elementy o nazwie pliku: raport i model semantyczny nordvella_26_pipeline. Przy nazwie obszaru widać plakietkę Programowanie: obszar jest przypisany do pierwszego etapu potoku.

Utworzenie potoku i przypisanie obszarów roboczych

Co chcemy osiągnąć. Założyć potok z trzema etapami i połączyć każdy etap z jego obszarem roboczym.

Potoki mają w usłudze własną stronę: Potoki wdrażania w menu po lewej. Strona pokazuje kafelek Nowy potok i potoki, do których masz dostęp. U nas jest jeden, Nordvella ALM.

1. Kliknij Nowy potok.
2. Wpisz nazwę potoku i opcjonalny opis. Przycisk Dalej uaktywnia się po wpisaniu nazwy.
3. Ustaw etapy. Kreator proponuje trzy: Development, Test i Production. Etap dodasz przyciskiem plus między kartami, usuniesz ikoną kosza, a nazwę zmienisz ikoną ołówka (Ustawienia etapu).
4. Kliknij Tworzenie i kontynuowanie. Dopiero ten przycisk zakłada potok.

Tu przerwaliśmy nagranie i wyszliśmy z kreatora bez tworzenia potoku, bo Nordvella ALM już istnieje. Lista potoków nadal ma jedną pozycję. Po kliknięciu Tworzenie i kontynuowanie przypisujesz każdemu etapowi obszar roboczy. W potoku Nordvella ALM etapy mają obszary Nordvella Dev, Nordvella Test i Nordvella Prod (zrzut na początku rozdziału). Jeden obszar może należeć tylko do jednego potoku.

W obszarach Nordvella Dev i Nordvella Test są też starsze elementy Nordvella ALM i Nordvella HR z wcześniejszych ćwiczeń. Zostawiliśmy je, bo dobrze pokazują, że potok nie musi przenosić całego obszaru naraz.

Zobacz też: Szkolenie Power BI - Desktop, DAX i Online + Copilot

Pierwsze wdrożenie z Programowania do Testu

Co chcemy osiągnąć. Przenieść raport i model nordvella_26_pipeline do obszaru Nordvella Test.

Kliknij kartę etapu Test. Pod kartami pojawia się lista elementów Testu, porównana z etapem źródłowym (pole Wdróż z: Programowanie). Raport i model nordvella_26_pipeline mają status Tylko w źródle: są w Nordvella Dev, w Nordvella Test jeszcze ich nie ma.

1. Zaznacz pola wyboru przy raporcie i modelu nordvella_26_pipeline. Przycisk Wdróż pokazuje liczbę zaznaczonych elementów.
2. Kliknij Wdróż. Okno Wdrażanie na tym etapie wylicza elementy do wdrożenia, u nas Nowe (2).
3. Kliknij Dodaj notatkę i opisz, co wdrażasz. Notatka zostaje w historii wdrożenia.
4. Zostaw zaznaczone Kontynuuj wdrażanie, jeśli 1 lub więcej elementów ulegnie awarii, i kliknij Wdróż.

Po chwili karta Testu pokazuje datę wdrożenia i Pomyślne wdrożenie, a oba elementy mają status Takie samo jak źródło.

Wdrożenie skopiowało definicję modelu i raportu, ale model w Teście czyta na razie ten sam plik co Programowanie, a poświadczenia źródła trzeba mu ustawić osobno. Tym zajmuje się następna sekcja.

Reguła wdrażania: Test czyta własny plik

Co chcemy osiągnąć. Model w Nordvella Test ma czytać C:\Kurs_PBI\test\Nordvella_dane.xlsx, bez zmiany pliku w Desktopie.

Reguły ustawiasz na etapie docelowym, dla elementu, który już na nim jest. Dlatego najpierw było wdrożenie, a teraz reguła.

1. Na karcie Test kliknij ikonę Reguły wdrażania.
2. W panelu wybierz model nordvella_26_pipeline. Panel ma dwie sekcje: Reguły źródła danych i Reguły parametrów.
3. Rozwiń Reguły parametrów i kliknij Dodaj regułę.
4. W polu Od wybierz SciezkaPliku. W polu Do wybierz Inne i wpisz C:\Kurs_PBI\test\Nordvella_dane.xlsx.
5. Kliknij Zapisz.

Reguła działa przy następnym wdrożeniu, więc wdrażamy model jeszcze raz, z notatką Ponowne wdrożenie: reguła SciezkaPliku dla etapu Test. Model nie musi się zmienić w Programowaniu, żeby dało się go wdrożyć ponownie.

Teraz otwórz ustawienia modelu w obszarze Nordvella Test: na liście obszaru Więcej opcji przy modelu, potem Ustawienia. Sekcja Parametry pokazuje wartość z reguły. Wyżej są dwie rzeczy, których wdrożenie nie przenosi.

• Brama. Usługa wybrała bramę osobistą z lekcji 24, działającą na maszynie POWERBI-KURS. Brama standardowa Brama-Nordvella jest na liście, ale ma przy tym modelu status Nie skonfigurowano poprawnie, więc zostajemy przy bramie osobistej.
• Poświadczenia. Ostrzeżenie Nie można przetestować połączenia ze źródłem danych dotyczy pliku Nordvella_dane.xlsx. Kliknij Edytuj poświadczenia przy tym pliku. Okno wygląda jak w lekcji 24: metoda System Windows bez personifikacji, poziom prywatności Organizational. Kliknij Zaloguj, a ostrzeżenie znika.

Po tych dwóch krokach odświeżyliśmy model w Teście. Odświeżenie zakończyło się powodzeniem, a zapytanie DAX na modelu w Nordvella Test zwraca Łączną sprzedaż 467 775 009,17 zł, tyle samo co w Programowaniu. Ścieżkę potwierdza sekcja Parametry, a poprawne odświeżenie pokazuje, że plik z folderu test jest na miejscu i ma wszystkie arkusze.

Poprawka po testach: przegląd zmian i ponowne wdrożenie

Co chcemy osiągnąć. Wprowadzić poprawkę zgłoszoną przez testerów, sprawdzić w potoku, co dokładnie się zmieniło, i wdrożyć tylko ją.

Załóżmy, że testerzy proszą o jedno miejsce po przecinku w Marży po zwrotach %. Poprawkę robisz w Desktopie i publikujesz do Programowania, nigdy prosto do Testu.

1. W Desktopie kliknij miarę Marża po zwrotach % w panelu Dane.
2. Na karcie Narzędzia miar zmień format z 0.00% na 0.0%.
3. Zapisz plik i kliknij Publikuj, obszar Nordvella Dev.

Desktop wykrywa, że w obszarze jest już model o tej nazwie, i pyta: Zamienić ten zestaw danych? Okno wylicza elementy, które korzystają z modelu (u nas Raport 1), i ma link Wyświetl wpływ. Kliknij Zamień.

Wróć do potoku i kliknij kartę Test. Model nordvella_26_pipeline ma teraz status Różni się od źródła, a raport nadal Takie samo jak źródło, bo się nie zmienił.

Zanim cokolwiek wdrożysz, sprawdź, co się różni. Zaznacz model i kliknij Porównaj na pasku nad listą. Otwiera się okno Zmień przegląd: po lewej lista elementów z różnicami, po prawej definicja modelu w dwóch kolumnach, Do zmodyfikowania [Test] i Do wdrożenia [Programowanie]. Strzałki Następna różnica i Poprzednia różnica przeskakują między zmianami, a dwa przyciski obok przełączają tryb Obok siebie i tryb śródwierszowy.

Licznik -1 +1 oznacza jedną usuniętą i jedną dodaną linię, czyli dokładnie naszą poprawkę. Na liście elementów jest też starszy model Nordvella ALM, który różni się między innymi wartością parametru serwera. Tego modelu nie wdrażamy.

1. Zamknij okno przeglądu. Model zostaje zaznaczony.
2. Kliknij Wdróż. Okno pokazuje Różne (1).
3. Dodaj notatkę, u nas: Poprawka po testach: miara Marża po zwrotach % z jednym miejscem po przecinku (0,0%). Kliknij Wdróż.

Wdrożenie trwało około 10 sekund i objęło tylko model. Reguła z poprzedniej sekcji działa dalej: po wdrożeniu parametr w Teście nadal wskazuje plik z folderu test. Reguł nie ustawiasz przy każdym wdrożeniu, zostają przy etapie.

Historia wdrożeń i powrót do poprzedniej wersji

Co chcemy osiągnąć. Wiedzieć, kto, kiedy i co wdrożył, i umieć wrócić do wersji sprzed zmiany.

Przycisk Historia wdrożenia jest na górze strony potoku, a jego ikona także na kartach etapów. Panel pokazuje wdrożenia wszystkich etapów albo wybranego: kolumny Wdrożone w, Data i godzina, Wdrożone przez, Elementy, notatkę, identyfikator i stan. Ikona notatki rozwija jej treść.

Potok nie ma przycisku Cofnij. Jeśli poprawka okaże się błędna, wersję sprzed zmiany publikujesz ponownie do Programowania, z kopii pliku albo z repozytorium Git (o nim za dwie sekcje), i wdrażasz ją dalej tak samo jak poprawkę: przegląd zmian, notatka, Wdróż. Dlatego po każdej publikacji zachowuj kopię pliku .pbix albo trzymaj projekt w Git.

Wdrożenie na Produkcję: wybrane elementy i własna reguła

Co chcemy osiągnąć. Przenieść na Produkcję tylko raport i model nordvella_26_pipeline i sprawić, żeby Produkcja czytała plik z folderu prod.

Wybór elementów

Kliknij kartę Produkcja. Pole Wdróż z ma wartość Test: na Produkcję wdrażasz z Testu, nie z Programowania. Wszystkie elementy Testu mają status Tylko w źródle, także raport i model Nordvella HR, których zarząd nie powinien dostać.

1. Zaznacz raport nordvella_26_pipeline.
2. Kliknij Wybierz powiązane. Usługa sama zaznacza model, z którego korzysta raport, i przełącza widok na listę płaską (przełącznik Lista płaska).
3. Kliknij Wdróż (przycisk pokazuje liczbę 2), dodaj notatkę i potwierdź Wdróż.

Nasza notatka: Pierwsze wdrożenie na produkcję: model i raport nordvella_26_pipeline po akceptacji w Test. Raport HR zostaje w Test. Po wdrożeniu karta Produkcji pokazuje datę i Pomyślne wdrożenie, a nasze elementy w obszarze Nordvella Prod mają status Takie samo jak źródło.

Pułapka: Produkcja czyta plik testowy

Otwórz ustawienia modelu w obszarze Nordvella Prod i rozwiń Parametry. SciezkaPliku ma wartość C:\Kurs_PBI\test\Nordvella_dane.xlsx. Pierwsze wdrożenie skopiowało model z Testu razem z wartością parametru, a reguły dla Produkcji jeszcze nie było, bo nie było na niej modelu. Tak samo Test po pierwszym wdrożeniu czytał plik Programowania.

Dodaj regułę dla Produkcji tak samo jak dla Testu: ikona Reguły wdrażania na karcie Produkcja, model nordvella_26_pipeline, Reguły parametrów, Dodaj regułę, SciezkaPliku, Inne, C:\Kurs_PBI\prod\Nordvella_dane.xlsx, Zapisz. Po zapisaniu reguły model na Produkcji dostaje status Różni się od źródła: reguła czeka na wdrożenie.

Wdróż model jeszcze raz, z notatką Ponowne wdrożenie: reguła SciezkaPliku dla etapu Produkcja. Po wdrożeniu parametr na Produkcji ma wartość C:\Kurs_PBI\prod\Nordvella_dane.xlsx.

Poświadczenia i odświeżenie na Produkcji

W ustawieniach modelu na Produkcji powtórz to, co zrobiłeś w Teście: brama osobista jest już wybrana, przy pliku Nordvella_dane.xlsx kliknij Edytuj poświadczenia i Zaloguj. Model odświeżysz z listy obszaru albo prosto z potoku: przy modelu na liście etapu są ikony Odśwież teraz i Zaplanuj odświeżanie.

Historia odświeżania modelu na Produkcji ma dwa wpisy. Pierwsze odświeżenie uruchomiliśmy przez interfejs API usługi (wpis Za pośrednictwem interfejsu API), drugie przyciskiem Odśwież teraz (wpis Na żądanie, 28 sekund). Oba mają stan Zakończono. Zapytanie DAX na modelu w Nordvella Prod zwraca 467 775 009,17 zł i 108 675 wierszy FaktSprzedaz.

Harmonogram odświeżania ustawiasz w ustawieniach modelu na każdym etapie, tak jak w lekcji 24. U nas model na Produkcji nie ma harmonogramu: na liście obszaru, w kolumnie Następne odświeżanie, jest Brak.

Kontrola wersji: projekt Power BI (.pbip) i integracja z Git

Co chcemy osiągnąć. Mieć historię zmian modelu w plikach tekstowych i wiedzieć, gdzie obszar roboczy łączy się z repozytorium Git.

Przegląd zmian w potoku porównuje tylko etapy. Pełną historię wersji daje system kontroli wersji, najczęściej Git. Git dobrze pracuje z plikami tekstowymi, a .pbix to archiwum, w którym nie zobaczy zmiany w mierze. Dlatego Desktop zapisuje raport także jako projekt Power BI (.pbip): zestaw folderów i plików tekstowych.

1. W Desktopie wybierz Plik, Zapisz jako. Otworzy się ekran Zapisz kopię.
2. Kliknij Przeglądaj to urządzenie.
3. W polu typu pliku wybierz Pliki projektów usługi Power BI (*.pbip), wskaż pusty folder (u nas C:\pbi\l26\projekt) i kliknij Zapisz.

Tak wygląda folder projektu po zapisie:

projekt\
  .gitignore
  nordvella_26_pipeline.pbip
  nordvella_26_pipeline.Report\
    definition.pbir
    definition\          strony i wizualizacje (JSON)
  nordvella_26_pipeline.SemanticModel\
    definition.pbism
    definition\
      database.tmdl
      model.tmdl
      expressions.tmdl  parametr i zapytania
      relationships.tmdl
      tables\           19 plików, po jednym na tabelę
      roles\            6 ról zabezpieczeń
      cultures\pl-PL.tmdl
    .pbi\cache.abf      dane, 6,9 MB, poza Git

TMDL (ang. Tabular Model Definition Language) to tekstowy zapis modelu. Parametr wygląda w pliku expressions.tmdl tak (opis parametru to linia zaczynająca się od trzech ukośników):

/// Ścieżka do arkusza Nordvella_dane.xlsx. Reguła potoku wdrażania podmienia ją na etapach Test i Prod.
expression SciezkaPliku = "C:\Kurs_PBI\Nordvella_dane.xlsx" meta [IsParameterQuery=true, Type="Text", IsParameterQueryRequired=true]

Miara w pliku tables\FaktSprzedaz.tmdl:

measure 'Marża po zwrotach %' =
        VAR MarzaBrutto = SUM ( FaktSprzedaz[MarzaNetto] )
        VAR StrataZwrotow = ABS ( SUM ( FaktZwroty[WartoscZwrotu] ) )
        VAR SprzedazNetto = SUM ( FaktSprzedaz[WartoscNetto] )
        RETURN
            DIVIDE ( MarzaBrutto - StrataZwrotow, SprzedazNetto )
    formatString: 0.0%

Zmiana formatu z sekcji o poprawce to w tym pliku jedna linia: formatString: 0.00% na formatString: 0.0%. Taką różnicę Git pokaże przy każdej zmianie, z autorem i datą. Plik .gitignore, który Desktop tworzy sam, wyklucza z repozytorium pamięć podręczną z danymi (cache.abf) i lokalne ustawienia (localSettings.json): do Git trafia definicja, nie dane.

Pobierz nordvella_26_pipeline_pbip.zip
Projekt z tej lekcji (160 plików, 140 KB) w tej postaci, w jakiej trafiłby do repozytorium: bez pliku cache.abf z danymi i bez localSettings.json.

Integracja z Git jest w ustawieniach obszaru roboczego: w Nordvella Dev kliknij Ustawienia obszaru roboczego, potem Integracja z usługą GIT. Najpierw wybierasz dostawcę (Azure DevOps albo GitHub) i konto, potem repozytorium i gałąź. Po połączeniu obszar synchronizuje elementy z folderem w repozytorium, w takim samym zapisie jak projekt .pbip.

U nas GitHub jest wyszarzony, bo tego dostawcę musi dopuścić administrator. Azure DevOps jest dostępny. Repozytorium w tej lekcji nie łączymy, bo wymaga konta u dostawcy.

Kto może wdrażać: dostęp do potoku i role w obszarach

Co chcemy osiągnąć. Ograniczyć wdrażanie do kilku osób, a odbiorcom dać na Produkcji tylko podgląd.

Dostęp do samego potoku ustawiasz przyciskiem Zarządzanie dostępem na górze strony potoku. Potok ma jedną rolę: Administrator. Osoba z tą rolą widzi etapy i może wdrażać, jeśli ma też odpowiednią rolę w obszarach etapów.

Role w obszarach roboczych znasz z lekcji 23. W obszarze Nordvella Prod kliknij Zarządzaj dostępem, potem Dodaj osoby lub grupy. Lista ról ma cztery pozycje.

Przykładowy podział ról dla Nordvelli:

Odbiorcom na Produkcji wygodniej dać aplikację z lekcji 23 niż rolę w obszarze: po wdrożeniu aktualizujesz aplikację, a odbiorcy widzą tylko to, co do niej dodasz.

Lista kontrolna przed wdrożeniem na Produkcję

W kolejnym, przedostatnim rozdziale kursu zajmujemy się nowościami: układem raportu na telefon, trybem Direct Lake w Microsoft Fabric i Copilotem w Power BI.

✕