Planowanie implementacji usługi Power BI: wdrażanie zawartości

Notatka

Ten artykuł, stanowi część serii artykułów planowania implementacji usługi Power BI. Ta seria koncentruje się głównie na środowisku usługi Power BI w Microsoft Fabric. Aby zapoznać się z wprowadzeniem do serii, zobacz planowanie implementacji usługi Power BI.

Ten artykuł ułatwia wdrażanie zawartości w ramach zarządzania cyklem życia zawartości. Jest ona przeznaczona przede wszystkim na:

• Administratorzy usługi Fabric: administratorzy, którzy są odpowiedzialni za nadzorowanie usługi Fabric w organizacji. Administratorzy sieci szkieletowej mogą wymagać współpracy z innymi administratorami, takimi jak ci, którzy nadzorują usługę Microsoft 365 lub Azure DevOps.
• centrum doskonałości (COE) i zespoły analizy biznesowej: zespoły odpowiedzialne za nadzorowanie usługi Power BI w organizacji. Zespoły te obejmują osoby podejmujące decyzje, które decydują, jak zarządzać cyklem życia zawartości usługi Power BI. Zespoły te mogą także obejmować menedżerów wydań, którzy zarządzają cyklem życia wydań zawartości, oraz inżynierów, którzy tworzą i zarządzają składnikami potrzebnymi do efektywnego używania i wspierania zarządzania cyklem życia.
• Twórcy treści i właściciele treści: użytkownicy, którzy tworzą treści, które chcą opublikować w portalu Fabric, aby udostępnić innym osobom. Te osoby są odpowiedzialne za zarządzanie cyklem życia tworzonej zawartości usługi Power BI.

Zarządzanie cyklem życia składa się z procesów i praktyk używanych do obsługi zawartości z jej tworzenia do ewentualnego wycofania. W trzecim etapie zarządzania cyklem życia weryfikujesz zmiany zawartości, które obejmują weryfikację wykonywaną zarówno przez twórców zawartości, jak i użytkowników. W czwartym etapie wdrażasz zawartość dla użytkowników, aby z niej korzystać.

Aby udostępnić zawartość usługi Power BI użytkownikom, należy najpierw opublikować (lub wdrożyć) zawartość w obszarze roboczym usługi Fabric. Wdrażanie zawartości obejmuje również przeniesienie tej zawartości między środowiskami, takich jak wdrażanie z obszaru roboczego programowania do obszaru roboczego testowego lub z obszaru roboczego testowego do produkcyjnego obszaru roboczego.

Na poniższej ilustracji przedstawiono cykl życia zawartości usługi Power BI z wyróżnionym etapem czwartym, w którym wdrażana jest zawartość.

Notatka

Aby zapoznać się z omówieniem zarządzania cyklem życia zawartości, zobacz pierwszy artykuł w tej serii .

Ten artykuł koncentruje się na kluczowych zagadnieniach i decyzjach dotyczących wdrażania zawartości w całym cyklu życia. Aby uzyskać więcej wskazówek dotyczących wdrażania zawartości, zobacz:

• Migracja do Power BI: Wdrażanie zawartości: W tym artykule opisano kluczowe zagadnienia i decyzje dotyczące wdrażania podczas migracji do usługi Power BI z innych technologii.
• planowanie rozwiązania BI: wdrażanie, obsługa i monitorowanie: w tym artykule opisano sposób planowania wdrożenia podczas pierwszego tworzenia rozwiązania Power BI lub Fabric.
• Planowanie implementacji usługi Power BI: scenariusz samoobsługowego publikowania zawartości: w tym artykule opisano, jak użytkownicy samoobsługi mogą wdrażać zawartość przy użyciu potoków wdrażania usługi OneDrive for Work i School and Fabric.
• Planowanie implementacji usługi Power BI: Scenariusz użycia publikowania zawartości w przedsiębiorstwie: w tym artykule opisano, jak zespoły centralne mogą wdrażać zawartość i zarządzać nią przy użyciu usługi Azure DevOps.

Zawartość jest wdrażana w dwóch głównych punktach w cyklu życia zawartości:

• Podczas publikowania zawartości w obszarze roboczym programowania. W tym momencie publikujesz zawartość, aby zweryfikować zmiany.
• W przypadku podwyższania poziomu zawartości między dwoma obszarami roboczymi (na przykład podwyższanie poziomu zawartości z obszaru roboczego programowania do testowego obszaru roboczego). W tym momencie wdrażasz zawartość, gdy będzie gotowa do następnego etapu (na przykład gdy nowa zawartość będzie gotowa do przetestowania).

W poniższych sekcjach opisano metody publikowania lub podwyższania poziomu zawartości.

Wybieranie sposobu publikowania zawartości

Podczas tworzenia zawartości na komputerze lokalnym należy opublikować ją w obszarze roboczym deweloperskim w portalu Fabric. Zazwyczaj publikujesz tę zawartość, gdy chcesz wykonać weryfikację zmian wprowadzonych.

Notatka

W tym artykule odwołujemy się do publikowania zawartości jako początkowego wdrożenia w obszarze roboczym programowania. Jednak w zasadzie publikowanie zawartości jest takie samo jak wdrażanie.

Zawartość utworzona w portalu Fabric (na przykład przepływy danych, pulpity nawigacyjne i karty wyników) jest tworzona bezpośrednio w środowisku roboczym programistycznym i nie musi być publikowana.

W poniższych sekcjach opisano różne podejścia do publikowania zawartości.

Publikowanie za pomocą programu Power BI Desktop

Program Power BI Desktop umożliwia użytkownikom publikowanie modeli semantycznych i raportów z komputera lokalnego do obszaru roboczego w portalu sieci szkieletowej. Takie podejście jest najprostszym sposobem publikowania zawartości; nie można go jednak zautomatyzować.

Rozważ użycie tego podejścia, gdy:

• Twórcy zawartości wolą ręcznie kontrolować publikowanie treści na portalu Fabric.
• Twórcy zawartości używają programu Power BI Desktop do tworzenia zawartości i zarządzania nią.
• Twórcy zawartości nie znają usług Azure DevOps ani Git.
• Zawartość składa się tylko z semantycznych modeli lub raportów.

Publikowanie za pomocą narzędzi innych firm

Narzędzia innych firm umożliwiają twórcom zawartości publikowanie modelu semantycznego przy użyciu obszaru roboczego punktu końcowego odczytu/zapisu XMLA. Na przykład twórca zawartości używa edytora tabelarycznego do tworzenia metadanych modelu i zarządzania nimi, takich jak TMDL (tabelaryczny język definicji modelu) lub pliki bim.

Napiwek

Aby uzyskać więcej informacji na temat używania narzędzi innych firm do wdrażania modeli semantycznych, zobacz zaawansowany scenariusz użycia zarządzania modelami danych.

Aby uzyskać więcej informacji na temat włączania i używania punktów końcowych odczytu/zapisu XMLA, zobacz Łączność modelu semantycznego z punktem końcowym XMLA.

Rozważ użycie tego podejścia, gdy:

• Twórcy zawartości wolą ręcznie kontrolować jej publikowanie w portalu Fabric.
• Twórcy zawartości używają narzędzia innej firmy do tworzenia zawartości i zarządzania nią.
• Zawartość zostanie opublikowana w obszarze roboczym korzystającym z warstwy Premium na użytkownika (PPU), pojemności Premium lub trybu licencji pojemności sieci szkieletowej.
• Twórcy zawartości nie znają usług Azure DevOps ani Git.
• Zawartość obejmuje tylko modele semantyczne.

Publikowanie za pomocą odświeżania w usłudze OneDrive

OneDrive pozwala twórcom treści na automatyczne publikowanie modeli semantycznych lub raportów w obszarze roboczym portalu Fabric, korzystając z funkcji odświeżania OneDrive. Twórcy zawartości mogą zapisywać pliki programu Power BI Desktop (pbix) w bibliotece udostępnionej w usłudze OneDrive. Biblioteka udostępniona może być również biblioteką dokumentów programu SharePoint lub microsoft Teams.

Napiwek

Aby uzyskać więcej informacji na temat korzystania z usługi OneDrive for Work and School z zawartością usługi Power BI, zobacz scenariusz użycia samoobsługowego publikowania zawartości .

Aby uzyskać więcej informacji na temat konfigurowania odświeżania w usłudze OneDrive, zobacz Odświeżanie modelu semantycznego przechowywanego w usłudze OneDrive lub SharePoint Online.

Rozważ użycie tego podejścia, gdy:

• Twórcy treści chcą zautomatyzować publikowanie treści w portalu Fabric.
• Twórcy zawartości nie znają usług Azure DevOps ani Git.
• Twórcy zawartości wykonują kontrolę wersji zawartości przy użyciu usługi OneDrive lub programu SharePoint.
• Twórcy zawartości zapisują semantyczne modele i raporty jako pliki pbix.
• Zawartość składa się tylko z semantycznych modeli lub raportów.

Publikowanie za pomocą integracji z Fabric Git

Integracja z Git w ramach Fabric to funkcja dostępna wyłącznie dla pojemności Fabric, która pozwala twórcom treści na synchronizację gałęzi zdalnego repozytorium Git z przestrzenią roboczą Fabric. Integracja z usługą Git razem z usługą Azure DevOps umożliwia synchronizowanie zawartości z usługi Azure Repos lub wdrażanie zawartości przy użyciu usługi Azure Pipelines (opisanej w następnej sekcji).

Notatka

azure DevOps to pakiet usług integrujących się z usługami Power BI i Fabric, które ułatwiają planowanie i organizowanie zarządzania cyklem życia zawartości. W przypadku korzystania z usługi Azure DevOps w ten sposób zwykle korzystasz z następujących usług:

• Azure Repos: umożliwia tworzenie i używanie zdalnego repozytorium Git, które służy do śledzenia i zarządzania zmianami zawartości.
• Azure Pipelines: pozwala na tworzenie i korzystanie z zestawu zautomatyzowanych zadań do obsługi, testowania i wdrażania zawartości z zdalnego repozytorium do obszaru roboczego.
• Azure Test Plans: umożliwia projektowanie testów w celu zweryfikowania rozwiązania i zautomatyzowania kontroli jakości wraz z usługą Azure Pipelines.
• Azure Boards: Umożliwia śledzenie zadań i planów jako elementów roboczych, a także łączenie lub odwoływanie się do elementów roboczych z innych usług Azure DevOps.
• Azure Wiki: umożliwia udostępnianie informacji swojemu zespołowi, aby rozumieli i współtworzyli treść.

Podsumowując, zawartość zatwierdzona i wypchnięta do repozytorium zdalnego jest automatycznie publikowana w obszarze roboczym za pośrednictwem tego procesu synchronizacji. Kluczową zaletą tego podejścia jest możliwość sprzężenia zarządzania kontrolą źródła procesów z publikacją zawartości. Na przykład umożliwia łatwiejsze wycofywanie zmian lub całych wersji rozwiązania.

Napiwek

Aby uzyskać więcej informacji na temat używania integracji Fabric z Git do wdrażania zawartości Power BI, zobacz scenariusz użycia publikowania zawartości przedsiębiorstwa .

Aby uzyskać więcej informacji na temat sposobu konfigurowania integracji z usługą Git, zobacz Samouczek: zarządzanie cyklem życia w usłudze Fabric i projektów programu Power BI Desktop: integracja z usługą Git.

Rozważ użycie tego podejścia, gdy:

• Twórcy zawartości znają usługi Azure DevOps i Git.
• Twórcy zawartości używają usługi Azure DevOps do współpracy i kontroli źródła.
• Twórcy zawartości zapisują semantyczne modele i raporty jako pliki projektu usługi Power BI (pbip).
• Zawartość zostanie opublikowana w obszarze roboczym opartej na pojemności Fabric.
• Zawartość składa się z typów elementów obsługiwanych przez funkcję integracji z usługą Git.
• Zawartości nie są opatrzone etykietami poufności .

Notatka

Sposób używania integracji z usługą Git do wdrażania zawartości i zarządzania nią zależy w dużym stopniu od rozgałęziania i scalania strategii, które decydujesz w ramach drugiego etapu zarządzania cyklem życia.

Publikowanie za pomocą usługi Azure Pipelines

Azure Pipelines programowo automatyzuje testowanie, zarządzanie i wdrażanie zawartości. Po uruchomieniu potoku kroki w potoku są wykonywane automatycznie. Usługa Azure Pipelines jest bardziej złożona i wymaga więcej czasu i nakładu pracy w celu skonfigurowania w porównaniu z innymi podejściami, ale pozwala na największą kontrolę i elastyczność organizowania procesu wdrażania.

Napiwek

Zawartość można wdrażać przy użyciu usługi Azure Pipelines i interfejsów API REST usługi Power BI do obszarów roboczych, które nie są na Fabric ani w pojemności Premium. Jednak interfejsy API REST działają tylko z Fabric, a punkty końcowe XMLA działają tylko z Fabric lub w pojemności Premium.

Aby uzyskać więcej informacji na temat sposobu wdrażania zawartości usługi Power BI przy użyciu usługi Azure Pipelines, zobacz scenariusz użycia publikowania zawartości przedsiębiorstwa.

Aby uzyskać więcej informacji na temat sposobu integracji usługi Azure DevOps z usługą Power BI, zobacz projekty programu Power BI Desktop dotyczące integracji usługi Azure DevOps i potoków kompilacji .

Rozważ użycie usługi Azure Pipelines do organizowania wdrażania zawartości w przypadku:

• Twórcy zawartości znają Azure DevOps i Fabric REST API.
• Twórcy zawartości używają usługi Azure DevOps do współpracy i kontroli źródła.
• Twórcy treści nie korzystają z integracji z Fabric Git.

Usługa Azure Pipelines i inne narzędzia oparte na kodzie mogą programowo wdrażać zawartość przy użyciu co najmniej jednego z następujących interfejsów API lub punktów końcowych:

• interfejsy API REST usługi Power BI: Istnieją różne punkty końcowe interfejsów API REST usługi Power BI, które można użyć do wdrażania zawartości. Interfejsy API REST usługi Power BI obsługują tylko typy elementów usługi Power BI.
  • Importowanie: Możesz publikować obsługiwane elementy, używając interfejsów API REST Power BI do zaimportowania prawidłowego pliku źródłowego do obszaru roboczego (na przykład pliku .pbix).
  • Wdrażanie: Możesz wdrożyć elementy obsługiwane, promując je z jednego obszaru roboczego do drugiego, jeśli są etapami w ścieżce wdrażania.
• Interfejsy API REST sieci szkieletowej: istnieją różne punkty końcowe interfejsu API REST sieci szkieletowej, których można użyć do wdrożenia zawartości. Interfejsy API REST Fabric obsługują zarówno typy elementów Power BI, jak i Fabric.
  • Utwórz: Możesz utworzyć obsługiwane elementy, używając Fabric REST APIs razem z prawidłową definicją elementu .
  • Update From Git: możesz zaktualizować obszar roboczy zawartością zdalnego repozytorium przy użyciu integracji z Gitem.
• punktów końcowych odczytu/zapisu XMLA: można utworzyć lub zmienić modele semantyczne przy użyciu punktów końcowych XMLA wraz z prawidłowym plikiem model.bim. Punkty końcowe XMLA umożliwiają wdrażanie zmian w określonych obiektach modelu zamiast całego modelu. Usługa Azure Pipelines może korzystać z narzędzi innych firm (takich jak interfejs wiersza polecenia edytora tabelarycznego) do wdrażania modeli semantycznych przy użyciu punktów końcowych XMLA.

Napiwek

W przypadku korzystania z interfejsów API REST usługi Fabric lub Power BI należy najpierw utworzyć rejestrację aplikacji na platformie Azure (opisane tutaj dla usługi Power BI Embedded). Wymaga to dzierżawcy Microsoft Entra ID oraz użytkownika organizacyjnego i może być złożonym procesem, aby skonfigurować odpowiednie uprawnienia. Można jednak wykonywać interfejsy API REST Fabric w notatnikach bez tworzenia rejestracji aplikacji. Usprawnia to konfigurowanie i używanie interfejsów API w rozwiązaniach, dzięki czemu nie trzeba zarządzać poświadczeniami ani konfigurować żadnej konfiguracji przed użyciem interfejsów API.

Aby używać interfejsów API REST usługi Fabric bez rejestrowania aplikacji, użyj linku semantycznego w notesie usługi Fabric z klasą FabricRestClientClass z biblioteki sempy w celu wywołania interfejsu API.

Wraz z testowaniem automatycznym integracja usługi Azure Pipelines z usługą Power BI ułatwia osiągnięcie ciągłej integracji i ciągłego wdrażania (CI/CD).

W przypadku korzystania z usługi Azure Pipelines właściciele potoków mogą dostosowywać wyzwalacze, kroki i funkcje, aby spełnić potrzeby wdrożenia. W związku z tym liczba i typy potoków różnią się w zależności od wymagań rozwiązania.

Istnieją trzy typy usługi Azure Pipelines, które można skonfigurować do testowania, zarządzania i wdrażania rozwiązania usługi Power BI.

• Potoki weryfikacji
• Procesy budowy
• Potoki wydania

Notatka

Nie jest konieczne stosowanie wszystkich trzech typów potoków w rozwiązaniu do publikowania. W zależności od przepływu pracy i potrzeb można skonfigurować co najmniej jeden wariant potoków opisanych w tym artykule w celu zautomatyzowania publikacji zawartości. Możliwość dostosowywania potoków jest zaletą usługi Azure Pipelines w porównaniu z wbudowanymi potokami wdrażania w ramach Fabric.

Potoki weryfikacji

Potoki weryfikacji przeprowadzają podstawowe kontrole jakości modeli danych przed ich opublikowaniem w obszarze roboczym programowania. Zazwyczaj zmiany w gałęzi repozytorium zdalnego wyzwalają rurę w celu zweryfikowania tych zmian za pomocą testów automatycznych.

Przykłady testów automatycznych obejmują skanowanie modelu danych pod kątem naruszeń reguł najlepszych rozwiązań przy użyciu analizatora najlepszych rozwiązań (BPA)lub przez uruchomienie zapytań języka DAX względem opublikowanego modelu semantycznego. Wyniki tych testów są następnie przechowywane w repozytorium zdalnym na potrzeby dokumentacji i inspekcji. Modele danych, które kończą się niepowodzeniem, nie powinny być publikowane. Zamiast tego potok przetwarzania powinien powiadamiać twórców treści o problemach.

Potoki budowania

Potoki kompilacji przygotować modele danych do publikacji w usłudze Power BI. Te potoki łączą zserializowane metadane modelu w jeden plik, który jest później publikowany przez potok wydawniczy. Potok kompilacji może również wprowadzać zmiany w metadanych, takie jak modyfikowanie wartości parametrów. Potoki kompilacji tworzą artefakty wdrożeniowe, które składają się z metadanych modelu danych oraz z plików projektu Power BI (.pbip), które są gotowe do publikacji w usłudze Power BI.

Potoki wydania

Pipeline'y wydań publikują lub wdrażają treści. Rozwiązanie do publikowania zwykle zawiera kilka potoków wydania, w zależności od środowiska docelowego.

• pipeline wydań deweloperskich: Ten pierwszy pipeline uruchamia się automatycznie. Publikuje ona zawartość w środowisku rozwojowym po pomyślnym zakończeniu procesów kompilacji i walidacji.
• potoki wydania testowego i produkcyjnego: te potoki nie są wyzwalane automatycznie. Zamiast tego są one wyzwalane na żądanie lub po zatwierdzeniu. Testowe i produkcyjne potoki wydawnicze wdrażają zawartość w testowym lub produkcyjnym obszarze roboczym odpowiednio po zatwierdzeniu wydania. zatwierdzenia wydania upewnić się, że zawartość nie jest automatycznie wdrażana na etapie testowym ani produkcyjnym, zanim będzie gotowa. Te zatwierdzenia są udostępniane przez menedżerów wersji, którzy są odpowiedzialni za planowanie i koordynowanie wydania zawartości w środowiskach testowych i produkcyjnych.

Wybieranie sposobu promowania zawartości między obszarami roboczymi

W przypadku używania różnych środowisk do programowania, testowania i produkcji należy wdrożyć zawartość we wszystkich trzech środowiskach. Istnieją różne narzędzia i podejścia, które można podjąć w celu promowania zawartości między obszarami roboczymi, w zależności od konkretnego przepływu pracy i potrzeb.

W poniższych sekcjach opisano metody promowania zawartości między obszarami roboczymi.

Ostrożność

Unikaj ręcznego publikowania zawartości z komputera lokalnego w przestrzeniach testowych i produkcyjnych. Może to spowodować błędy lub zakłócenia wynikające z pomyłek. Ogólnie rzecz biorąc, należy publikować tylko w obszarze roboczym deweloperskim lub w prywatnym obszarze roboczym, jeśli go używasz.

Wdrażanie przy użyciu potoków wdrażania Fabric

Potoki wdrażania umożliwiają skonfigurowanie co najmniej dwóch etapów (takich jak rozwój, testowanie lub produkcja) oraz wdrażanie zawartości Fabric między tymi etapami. Administrator potoku wdrażania przypisuje jedno środowisko pracy Power BI do każdego etapu w potoku wdrażania. Sposób korzystania z potoków wdrażania zależy od tego, jak podjęto decyzję o skonfigurowaniu i użyciu obszarów roboczych.

Rozważ użycie potoków wdrażania, gdy:

• Zawartość jest wdrażana w obszarach roboczych z trybem licencji PPU, pojemności Premium lub pojemności Fabric.
• Typy i scenariusze elementów zawartości są obsługiwane przez potoki wdrażania.

Rozważ inne podejście niż ciągi wdrażania, gdy:

• Wolisz wdrażać zawartość z repozytorium zdalnego, na przykład przy użyciu usługi Azure Pipelines.
• Zamierzasz używać integracji z usługą Git do synchronizowania różnych etapów z różnymi gałęziami repozytorium zdalnego, zamiast wdrażać zawartość.

Napiwek

Aby uzyskać więcej informacji na temat używania potoków wdrażania do promowania zawartości pomiędzy obszarami roboczymi, zobacz scenariusze użycia samoobsługowej publikacji zawartości i oraz scenariusze użycia publikacji zawartości przedsiębiorstwa i.

Aby uzyskać więcej informacji na temat potoków wdrażania, zobacz Potoki wdrażania: Omówienie procesu wdrażania.

Najprostszym sposobem korzystania z potoku wdrożeniowego jest, gdy publikujesz całą zawartość w jednym obszarze roboczym i promujesz ją do późniejszych etapów w ramach jednego potoku wdrożeniowego. Na poniższym diagramie przedstawiono pierwsze z podejść do wdrażania zawartości za pomocą potoku wdrożeniowego.

Podsumowując, twórca zawartości zazwyczaj najpierw publikuje zawartość na początkowym etapie potoku. Następnie, aby przenieść zawartość do późniejszych etapów, administrator potoku inicjuje wdrożenie. W przypadku wdrożenia potok wdrażania wdraża metadane zawartości z jednego obszaru roboczego do następnego.

Podczas oddzielania zawartości według typu elementu w różnych obszarach roboczych użyjesz oddzielnych potoków wdrażania, aby wdrożyć tę zawartość. Można łączyć zawartość między obszarami roboczymi z wykorzystaniem wielu potoków wdrażania za pomocą automatycznego wiązania. Automatyczne wiązanie między potokami wdrażania zapewnia, że zawartość pozostaje połączona z odpowiednim elementem na odpowiednim etapie. Na przykład raport na etapie programowania pozostanie połączony z modelem na etapie programowania innego potoku wdrażania. Można jednak również uniknąć zachowania automatycznego wiązania, jeśli scenariusz wymaga połączenia zawartości między obszarami roboczymi w inny sposób.

Na poniższym diagramie przedstawiono drugie podejście do wdrażania zawartości przy użyciu wielu potoków wdrażania.

Podsumowując, wdrażanie zawartości przy użyciu wielu potoków wdrażania jest podobne do używania jednego potoku. Kluczową różnicą jest to, że możesz opcjonalnie połączyć treści powiązane pomiędzy obszarami roboczymi i ścieżkami wdrażania, korzystając z funkcji automatycznego powiązania. W przeciwnym razie jest to identyczne z pierwszym podejściem.

Potoki wdrażania to elastyczne, proste narzędzie odpowiednie do ulepszania zarządzania cyklem życia zawartości zarówno w scenariuszach samoobsługowych, jak i dla przedsiębiorstw.

Dostęp do obszaru roboczego i potoku wdrażania jest wymagany przez użytkowników przeprowadzających wdrożenie. Zalecamy planowanie dostępu do pipeline'u wdrażania, aby administratorzy pipeline'u mogli wyświetlać historię wdrażania i porównywać zawartość. Podczas współpracy z wieloma twórcami treści rozważ ograniczenie dostępu do pipeline’u dla menedżerów wersji lub właścicieli technicznych, którzy są odpowiedzialni za nadzorowanie procesów wdrażania i dystrybucji.

Ponadto rozważ użycie reguł wdrażania, aby ustawić różne konfiguracje elementów na różnych etapach. Na przykład możesz chcieć, aby model semantyczny w obszarze roboczym deweloperskim pozyskiwał dane z bazy danych deweloperskich, podczas gdy model semantyczny w produkcyjnym obszarze roboczym pozyskuje dane z produkcyjnej bazy danych.

Napiwek

Jeśli wiele osób ma dostęp do potoku wdrażania, zalecamy regularne przeglądanie historii wdrażania . Te przeglądy mogą pomóc w zidentyfikowaniu niezatwierdzonych wdrożeń lub niepowodzeń wdrażania.

Jeśli używasz automatycznego wiązania do łączenia elementów między potokami wdrażania, upewnij się, że przeglądasz również ścieżki elementów, aby zidentyfikować przerwy w automatycznym powiązaniu spowodowane przez osobę, która publikuje połączoną zawartość na niewłaściwym etapie.

Wdrożenia można wyzwalać ręcznie lub programowo za pomocą interfejsów API REST Power BI . W obu przypadkach należy zdefiniować jasny i niezawodny proces dotyczący promowania zawartości do każdego etapu oraz sposobu wycofywania niezamierzonych zmian.

Ręczne wykonywanie wdrożenia

Zawartość można wdrożyć ręcznie, korzystając z potoku wdrażania Fabric. Możesz wybrać wdrożyć całą zawartość lub wybrać elementy. Wdrożenie selektywne może być korzystne, gdy część zawartości jest gotowa do przejścia do następnego etapu, ale niektóre elementy są nadal w trakcie opracowywania lub walidacji. Ponadto można wykonać wdrożenie wstecz, gdy zmiany zawartości istnieją w późniejszym etapie, ale nie we wcześniejszym.

Ostrożność

W przypadku korzystania z potoków wdrażania zalecamy wdrożenie zawartości w jednym kierunku, na przykład od programowania do testowania do produkcyjnych obszarów roboczych. Zazwyczaj należy unikać wprowadzania zmian w zawartości w późniejszych etapach, zanim te zmiany zostały poddane odpowiedniej weryfikacji w trakcie opracowywania lub testowania.

Podczas ręcznego wdrażania można porównać etapy, aby zidentyfikować zmiany zawartości w oknie przeglądu zmian . Takie podejście jest szczególnie przydatne, gdy nie używasz zdalnego repozytorium Git do kontroli źródła.

Wdrażanie za pomocą interfejsów API REST usługi Power BI

Interfejsy API REST usługi Power BI umożliwiają wdrażanie zawartości za pomocą potoku wdrożeniowego. Zaletą korzystania z interfejsów API REST jest to, że można zautomatyzować wdrażanie i zintegrować je z innymi narzędziami, takimi jak Usługa Azure Pipelines w usłudze Azure DevOps.

Wdrażanie za pomocą usługi Azure Pipelines

Usługa Azure Pipelines umożliwia organizowanie wdrożenia między wszystkimi etapami. Dzięki temu podejściu interfejsy API REST Fabric służą do wdrażania i zarządzania zawartością, korzystając z różnych potoków usługi Azure Pipelines, takich jak potoki walidacji i releasu.

Rozważ użycie usługi Azure Pipelines, gdy:

• Chcesz scentralizować aranżację wdrożenia z poziomu usługi Azure DevOps.
• Twórcy zawartości używają usługi Azure DevOps do współpracy i kontroli źródła.

Rozważ inne podejście niż usługa Azure Pipelines, gdy:

• Twórcy zawartości nie znają usługi Azure DevOps ani wdrożeń opartych na kodzie.
• Zawartość zawiera typy elementów, które nie mają obsługiwanej definicji ani formatu pliku źródłowego, takich jak pulpity nawigacyjne.

Istnieją dwa różne podejścia do wdrażania zawartości za pomocą usługi Azure Pipelines. Organizują pipeline'y wdrożeniowe lub wdrażają zawartość w obszarze roboczym bez pipeline'u wdrożeniowego.

Organizowanie potoków wdrażania w środowiskach Fabric przy użyciu usługi Azure Pipelines

W tym podejściu potoki publikacji organizują rozmieszczanie zawartości w obszary robocze testowe i produkcyjne za pomocą potoków wdrażania. Zawartość jest promowana przez obszary robocze tworzenia, testowania i produkcji w Fabric.

Na poniższym diagramie przedstawiono sposób organizowania potoków wdrażania z usługi Azure Pipelines.

Podsumowując, twórcy treści publikują je do obszaru roboczego w pierwszym etapie ścieżki wdrażania. Następnie menedżer wydania zatwierdza wdrożenie, które wyzwala usługę Azure Pipeline. Ten potok przetwarzania używa interfejsów API REST usługi Power BI do promowania zawartości między etapami, aby metadane były wdrażane w innym obszarze roboczym. Jedną z zalet tego podejścia jest to, że można organizować wdrażanie wielu typów elementów sieci szkieletowej za pośrednictwem potoków wdrażania, ponieważ niektóre typy elementów są opracowywane w portalu sieci szkieletowej, a tym samym nie można ich wdrażać tylko przez usługę Azure Pipelines.

Wdrażanie zawartości przy użyciu tylko usługi Azure Pipelines

Zawartość można również wdrożyć do obszaru roboczego przy użyciu Azure Pipelines z usługi Azure DevOps. Takie podejście nie korzysta z potoków wdrażania. Zamiast tego, używa potoków publikacji do wdrażania plików źródłowych lub metadanych przy użyciu interfejsów API REST Fabric lub Power BI albo punktów końcowych odczytu/zapisu XMLA. Zazwyczaj te pliki są przechowywane w repozytorium Git usługi Azure Repos.

Na poniższym diagramie przedstawiono sposób wdrażania zawartości przy użyciu tylko usługi Azure Pipelines.

Podsumowując, twórcy zawartości zatwierdzają i wypychają zmiany zawartości do zdalnego repozytorium Git w usłudze Azure Repos. Ta zawartość jest używana przez usługę Azure Pipelines do wdrożenia. Gdy menedżer wydania zatwierdzi określone wdrożenie, usługa Azure Pipeline wdroży zawartość w obszarze roboczym, korzystając z interfejsów API REST Power BI (czyli dla plików .pbix), interfejsów API REST Fabric (czyli dla definicji elementów) lub punktów końcowych XMLA (czyli dla plików model.bim). Istnieje oddzielna usługa Azure Pipeline dla każdego obszaru roboczego.

Takie podejście nie wymaga pojemności sieci szkieletowej ani licencjonowania Premium w przypadku publikowania tylko plików programu Power BI Desktop za pomocą interfejsów API REST usługi Power BI. Jednak wiąże się to z większym nakładem pracy i złożonością konfiguracji, ponieważ należy zarządzać wdrożeniem poza usługą Power BI. Zespoły programistyczne, które już używają metodyki DevOps do obsługi rozwiązań danych spoza usługi Power BI, mogą zapoznać się z tym podejściem. Zespoły programistyczne korzystające z tego podejścia mogą skonsolidować wdrażanie rozwiązań danych w usłudze Azure DevOps.

Wdrażanie z integracją Git w Fabric

W przypadku korzystania z integracji z usługą Git można zsynchronizować różne gałęzie z różnymi obszarami roboczymi zamiast jawnie publikować lub wdrażać zawartość. W ten sposób można mieć oddzielne gałęzie dla obszarów roboczych programowania, testowania i produkcji. W tym scenariuszu główna gałąź jest synchronizowana z obszarem roboczym produkcyjnym. Następnie wdrażasz zawartość między obszarami roboczymi, wykonując żądanie ściągnięcia, aby scalić gałąź programowania z gałęzią testową (w celu wdrożenia w obszarze roboczym testowym) lub scalić gałąź testową z gałęzią główną (w celu wdrożenia w obszarze roboczym produkcyjnym).

Na poniższym diagramie przedstawiono, jak wdrażać zawartość przy użyciu integracji Fabric Git do synchronizacji gałęzi z różnymi obszarami roboczymi. Dla uproszczenia diagram nie zawiera szczegółów rozgałęziania ani scalania zawartości.

Podsumowując, twórcy zawartości zatwierdzają i wypychają zmiany zawartości do zdalnego repozytorium Git w usłudze Azure Repos. Twórcy zawartości otwierają wnioski o pobranie (PR), aby prosić o scalenie swoich zmian z określoną gałęzią. W zależności od strategii rozgałęziania różne gałęzie są połączone z różnymi obszarami roboczymi. Po scaleniu zmian z gałęzią twórcy zawartości synchronizują obszar roboczy ze zdalnym repozytorium Git, aby wyświetlić najnowsze zmiany zawartości w tym obszarze roboczym.

Rozważ następujące podejście, gdy:

• Chcesz koordynować wdrażanie pomiędzy przestrzeniami roboczymi, wykorzystując swoją strategię rozgałęziania i scalania.
• Nie zamierzasz używać potoków wdrażania usługi Azure Pipelines ani sieci szkieletowej do organizowania wdrożeń w celu testowania i produkcji.
• Obszar roboczy nie zawiera nieobsługiwanych elementów ani scenariuszy .
• Zawartość nie ma etykiet poufności .

Notatka

Istnieje wiele prawidłowych sposobów wdrażania zawartości. Na przykład można użyć kombinacji różnych podejść omówionych w tym artykule.

Możesz na przykład wdrożyć zawartość w obszarze roboczym programowania przy użyciu usługi Azure Pipeline, która umożliwia korzystanie z funkcji ciągłej integracji i przeprowadzania testów automatycznych (takich jak korzystanie z analizatora najlepszych rozwiązań). Następnie możesz wdrożyć zawartość między obszarami roboczymi przy użyciu integracji z Git lub pipeline'u wdrażania Fabric.

Wybierz podejście, które najlepiej odpowiada Twoim potrzebom i sposób działania zespołu.

Wybieranie sposobu obsługi działań wykonywanych po wdrożeniu

Po wdrożeniu istnieją różne działania po wdrożeniu, które muszą być obsługiwane. Wiele z tych działań można obsłużyć programowo, na przykład za pomocą usługi Azure Pipeline lub notatnika oraz interfejsów API REST usługi Power BI i Fabric. Na przykład można programowo ustawić poświadczenia źródła danych, zarządzać zaplanowanym odświeżaniem i wyzwalać odświeżenia po wdrożeniu metadanych. Jednak niektóre zadania wymagają ręcznej interwencji, takiej jak konfiguracja po raz pierwszy lub aktualizacja aplikacji usługi Power BI.

Upewnij się, że zidentyfikowano wszystkie odpowiednie działania po wdrożeniu dla zawartości i decydujesz, w jaki sposób będą one obsługiwane.

Po zaplanowanym sposobie wdrażania zawartości należy rozważyć obsługę i monitorowanie zawartości.

lista kontrolna — podczas planowania sposobu wdrażania zawartości kluczowe decyzje i akcje obejmują:

• Określ dostępne opcje wdrażania: w zależności od licencjonowania i zawartości dostępne są różne opcje publikowania zawartości lub podwyższania jej poziomu między obszarami roboczymi. Określ, czy możesz używać potoków wdrażania, Azure DevOps, integracji z Git, interfejsów Fabric REST API i punktów końcowych odczytu/zapisu XMLA.
• Zdecyduj, jak opublikować zawartość: wybierz podejście do publikowania zawartości, która najlepiej odpowiada potrzebom i przepływowi pracy. Upewnij się, że takie podejście jest zgodne z innymi strategiami, takimi jak śledzenie zmian i zarządzanie nimi.
• Zdecyduj, jak będziesz promować zawartość między różnymi obszarami roboczymi: Wybierz podejście do wdrażania zawartości z obszarów projektowych do testowych obszarów roboczych i z obszarów testowych do obszarów produkcyjnych. Upewnij się, że takie podejście jest zgodne z innymi strategiami, takimi jak sposób publikowania zawartości.
• Zaplanuj strategię wydania: określ, czy określona osoba będzie odpowiedzialna za ostateczną recenzję zawartości przed zatwierdzeniem wydania lub wdrożenia. Upewnij się, że ta osoba jest świadoma tego zadania i tego, co należy zrobić, aby chronić proces wdrażania bez blokowania postępu.
• planowanie działań po wdrożeniu: upewnij się, że podjęto decyzję o wykonaniu działań, takich jak aktualizowanie aplikacji usługi Power BI lub odświeżanie elementów danych po wdrożeniu metadanych. Rozważ zautomatyzowanie tego procesu przy użyciu Fabric REST API.
• Wykonaj konfigurację narzędzi i procesów wdrażania po raz pierwszy: Upewnij się, że skonfigurowaliśmy odpowiedni dostęp, a uprawnienia są dostosowane do sposobu konfigurowania dostępu do zawartości.
• Wdrażanie zawartości w środowisku produkcyjnym: podczas planowania i konfigurowania wdrożenia wdróż zawartość w środowisku produkcyjnym.

Powiązana zawartość

W następnym artykule z tej seriidowiesz się, jak obsługiwać i monitorować zawartość w ramach zarządzania cyklem życia zawartości.