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

Uwaga

Ten artykuł stanowi część serii artykułów dotyczących planowania implementacji usługi Power BI. Ta seria koncentruje się głównie na środowisku usługi Power BI w usłudze 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 sieci szkieletowej: 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ą również obejmować menedżerów wydań, którzy obsługują cykl życia wydań zawartości, oraz inżynierów, którzy tworzą składniki potrzebne do efektywnego używania i zarządzania cyklem życia wsparcia technicznego.
• Twórcy zawartości i właściciele zawartości: użytkownicy, którzy tworzą zawartość, którą chcą publikować w portalu sieci szkieletowej, aby udostępniać je 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ą walidację wykonywaną przez twórców zawartości 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 sieć szkieletowa. 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ść.

Uwaga

Aby zapoznać się z omówieniem zarządzania cyklem życia zawartości, zobacz pierwszy artykuł z 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:

• Migrowanie do usługi 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 analizy biznesowej: Wdrażanie, obsługa i monitorowanie: w tym artykule opisano sposób planowania wdrożenia podczas pierwszego tworzenia rozwiązania usługi Power BI lub sieci szkieletowej.
• 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 programowania w portalu sieci szkieletowej. Zazwyczaj publikujesz tę zawartość, gdy chcesz przeprowadzić walidację wprowadzonych zmian.

Uwaga

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 sieci szkieletowej (na przykład przepływy danych, pulpity nawigacyjne i karty wyników) jest tworzona bezpośrednio w obszarze roboczym programowania 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 semantycznych modeli 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 zawartości w portalu sieci szkieletowej.
• 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 punktu końcowego odczytu/zapisu XMLA obszaru roboczego. 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 o sposobie wdrażania modeli semantycznych za pomocą narzędzi innych firm, 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 Semantic model connectivity with the XMLA endpoint (Łączność modelu semantycznego z punktem końcowym XMLA).

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

• Twórcy zawartości wolą ręcznie kontrolować publikowanie zawartości w portalu sieci szkieletowej.
• 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 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

Usługa OneDrive umożliwia autorom zawartości samoobsługowej automatyczne publikowanie modeli semantycznych lub raportów w obszarze roboczym w portalu sieci szkieletowej przy użyciu odświeżania w usłudze 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 zawartości chcą zautomatyzować publikowanie zawartości w portalu sieci szkieletowej.
• 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 usługą Git w usłudze Fabric

Integracja z usługą Git w sieci szkieletowej to funkcja przeznaczona wyłącznie dla pojemności sieci szkieletowej, która umożliwia twórcom zawartości synchronizowanie gałęzi ze zdalnego repozytorium Git z obszarem roboczym usługi 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).

Uwaga

Azure DevOps to pakiet usług, które integrują 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 jest zdalną lokalizacją magazynu używaną do śledzenia zmian zawartości i zarządzania nimi.
• Azure Pipelines: umożliwia tworzenie i używanie zestawu zautomatyzowanych zadań do obsługi, testowania i wdrażania zawartości z repozytorium zdalnego do obszaru roboczego.
• Plany testów platformy Azure: 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 za pomocą tablic oraz łączenie lub odwoływanie się do elementów roboczych z innych usług Azure DevOps.
• Witryna Typu wiki platformy Azure: umożliwia udostępnianie informacji zespołowi w celu zrozumienia zawartości i współtworzenia jej.

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 procesów zarządzania kontrolą źródła 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 korzystania z integracji usługi Git z usługą Fabric w celu wdrożenia zawartości usługi Power BI, zobacz scenariusz użycia publikowania zawartości przedsiębiorstwa.

Aby uzyskać więcej informacji na temat konfigurowania integracji z usługą Git, zobacz Samouczek: zarządzanie cyklem życia w usłudze Fabric i projektach 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 w pojemności sieci szkieletowej.
• Zawartość składa się z obsługiwanych typów elementów przez funkcję integracji z usługą Git.
• Zawartość nie ma etykiet poufności.

Uwaga

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

Usługa 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 w obszarach roboczych, które nie są w sieci szkieletowej ani w pojemności Premium. Jednak interfejsy API REST sieci szkieletowej działają tylko z siecią szkieletową, a punkty końcowe XMLA działają tylko z pojemnością Sieć szkieletowa lub 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 integrowania usługi Azure DevOps z usługą Power BI, zobacz Projekty programu Power BI Desktop dotyczące integracji i potoków kompilacji usługi Azure DevOps.

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

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

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 interfejsu API REST usługi Power BI, których można użyć do wdrożenia zawartości. Interfejsy API REST usługi Power BI obsługują tylko typy elementów usługi Power BI.
  • Importowanie: obsługiwane elementy można publikować przy użyciu interfejsów API REST usługi Power BI w celu zaimportowania prawidłowego pliku źródłowego do obszaru roboczego (na przykład pliku pbix).
  • Wdrażanie: możesz wdrożyć obsługiwane elementy, promując je z jednego obszaru roboczego do innego, jeśli są etapami w potoku 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 wdrażania zawartości. Interfejsy API REST sieci szkieletowej obsługują zarówno typy elementów usługi Power BI, jak i sieci szkieletowej.
  • Tworzenie: możesz utworzyć obsługiwane elementy przy użyciu interfejsów API REST sieci szkieletowej wraz z prawidłową definicją elementu.
  • Aktualizacja z usługi Git: obszar roboczy można zaktualizować przy użyciu zawartości z repozytorium zdalnego połączonego przy użyciu integracji z usługą Git.
• Punkty końcowe odczytu/zapisu XMLA: można tworzyć lub zmieniać 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 (opisaną tutaj dla usługi Power BI Embedded). Wymaga to dzierżawy microsoft Entra ID i użytkownika organizacyjnego i może być złożonym procesem konfigurowania odpowiednich uprawnień. Można jednak wykonywać interfejsy API REST sieci szkieletowej w notesach 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 sieci szkieletowej bez rejestrowania aplikacji, użyj linku semantycznego w notesie usługi Fabric z elementem FabricRestClientClass programu 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
• Potoki kompilacji
• Potoki wydania

Uwaga

Nie jest konieczne posiadanie 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 przypadku wbudowanych potoków wdrażania sieci szkieletowej.

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ą potok 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 uruchamianie 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 powinien powiadamiać twórców zawartości o problemach.

Potoki kompilacji

Potoki kompilacji przygotowują modele danych do publikacji w usługa Power BI. Te potoki łączą serializowane metadane modelu w jeden plik, który jest później publikowany przez potok wydania. Potok kompilacji może również wprowadzać zmiany w metadanych, takie jak modyfikowanie wartości parametrów. Potoki kompilacji tworzą artefakty wdrażania składające się z metadanych modelu danych (dla modeli danych) i plików projektu usługi Power BI (pbip), które są gotowe do opublikowania w usługa Power BI.

Potoki wydania

Potoki wydania publikują lub wdrażają zawartość. Rozwiązanie do publikowania zwykle zawiera kilka potoków wydania, w zależności od środowiska docelowego.

• Potok wydania programowania: ten pierwszy potok jest wyzwalany automatycznie. Publikuje ona zawartość w obszarze roboczym programowania po pomyślnym zakończeniu potoków kompilacji i walidacji.
• Potoki wersji testowej i produkcyjnej: te potoki nie są wyzwalane automatycznie. Zamiast tego są one wyzwalane na żądanie lub po zatwierdzeniu. Potoki wersji testowej i produkcyjnej wdrażają zawartość odpowiednio w obszarze roboczym testowym lub produkcyjnym po zatwierdzeniu wydania. Zatwierdzenia wydania zapewniają, że zawartość nie jest automatycznie wdrażana na etapie testowania lub produkcji, 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.

Uwaga

Unikaj ręcznego publikowania zawartości z komputera lokalnego w celu testowania i produkcji obszarów roboczych. Może to spowodować błędy lub zakłócenia z powodu błędów. Ogólnie rzecz biorąc, należy publikować tylko w obszarze roboczym programowania lub w prywatnym obszarze roboczym, jeśli go używasz.

Wdrażanie przy użyciu potoków wdrażania sieci szkieletowej

Potoki wdrażania umożliwiają skonfigurowanie co najmniej dwóch etapów (takich jak programowanie, testowanie lub produkcja) oraz wdrażanie zawartości sieci szkieletowej między tymi etapami. Administrator potoku przypisuje jeden obszar roboczy usługi 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 sieci szkieletowej.
• Typy i scenariusze elementów zawartości są obsługiwane przez potoki wdrażania.

Rozważ inne podejście niż potoki 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 w celu promowania zawartości między obszarami roboczymi, zobacz scenariusze dotyczące samoobsługowego publikowania zawartości i publikowania zawartości przedsiębiorstwa.

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 wdrażania jest opublikowanie całej zawartości w jednym obszarze roboczym i podwyższenie jej poziomu do późniejszych etapów w ramach jednego potoku wdrażania. Na poniższym diagramie przedstawiono to pierwsze podejście do wdrażania zawartości przy użyciu potoku wdrażania.

Podsumowując, twórca zawartości zazwyczaj najpierw publikuje zawartość na początkowym etapie potoku. Następnie, aby podwyższyć poziom zawartości do późniejszych etapów, administrator potoku wyzwoli 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ść. Zawartość można łączyć między obszarami roboczymi z wieloma potokami wdrażania przy użyciu automatycznego powią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 z innym wzorcem.

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 jednego potoku. Kluczową różnicą jest możliwość opcjonalnego połączenia zawartości połączonej między obszarami roboczymi i potokami wdrażania przy użyciu 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 dla użytkowników przeprowadzających wdrożenie. Zalecamy zaplanowanie dostępu do potoku wdrażania, aby administratorzy potoków mogli wyświetlać historię wdrożenia i porównywać zawartość. Podczas współpracy z wieloma twórcami zawartości rozważ ograniczenie dostępu potoku do menedżerów wersji lub właścicieli technicznych, którzy najlepiej nadają się do nadzorowania procesów wdrażania i wydawania.

Ponadto rozważ użycie reguł wdrażania, aby ustawić różne konfiguracje elementów na różnych etapach. Na przykład możesz chcieć utworzyć model semantyczny w obszarze roboczym programowania do źródła danych z bazy danych deweloperskich, a semantyczny model w produkcyjnym obszarze roboczym źródła danych 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 powiązania do łączenia elementów między potokami wdrażania, upewnij się, że przeglądasz również pochodzenie elementów, aby zidentyfikować przerwy w automatycznym powiązaniu spowodowanym przez publikowanie połączonej zawartości przez osobę publikującą powiązaną z niewłaściwym etapem.

Wdrożenia można wyzwalać ręcznie lub programowo przy użyciu interfejsów API REST usługi 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 przy użyciu potoku wdrażania sieci szkieletowej. Możesz wybrać pozycję Wdróż 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 wsteczne, gdy zmiany zawartości istnieją w późniejszym etapie, ale nie we wcześniejszej wersji.

Uwaga

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 przy użyciu potoku wdrażania. 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 sieci szkieletowej służą do wdrażania zawartości i zarządzania nią, korzystając z różnych potoków usługi Azure Pipelines, takich jak potoki weryfikacji i wydania.

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ą potoki wdrażania lub wdrażają zawartość w obszarze roboczym bez potoku wdrażania.

Organizowanie potoków wdrażania sieci szkieletowej przy użyciu usługi Azure Pipelines

W tym podejściu potoki wydania organizuje wdrażanie zawartości w celu testowania i produkcji obszarów roboczych przy użyciu potoków wdrażania. Zawartość jest promowana za pośrednictwem obszarów roboczych tworzenia, testowania i produkcji w sieci szkieletowej.

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

Podsumowując, twórcy zawartości publikują zawartość w obszarze roboczym w pierwszym etapie potoku wdrażania. Następnie menedżer wydania zatwierdza wdrożenie, które wyzwala usługę Azure Pipeline. Ten potok używa interfejsów API REST usługi Power BI do promowania zawartości między etapami, dzięki czemu metadane są 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ć w obszarze roboczym z usługi Azure DevOps przy użyciu usługi Azure Pipelines. Takie podejście nie korzysta z potoków wdrażania. Zamiast tego używa potoków wydania do wdrażania plików źródłowych lub plików metadanych przy użyciu interfejsów API REST sieci szkieletowej lub usługi 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 przy użyciu interfejsów API REST usługi Power BI (czyli dla plików pbix), interfejsów API REST sieci szkieletowej (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 za pomocą integracji z usługą Git w usłudze 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 gałąź główna 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 sposób wdrażania zawartości przy użyciu integracji usługi Git sieci szkieletowej w celu synchronizowania 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ą żądania ściągnięcia w celu żądania scalenia zmian w określonej 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 zorganizować wdrażanie między obszarami roboczymi przy użyciu strategii 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.

Uwaga

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 usługą Git lub potoku wdrażania usługi 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 notesu oraz interfejsów API REST usługi Power BI i sieci szkieletowej. 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ą:

• Zidentyfikuj 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, usługi Azure DevOps, integracji z usługą Git, interfejsów API REST sieci szkieletowej i punktów końcowych odczytu/zapisu XMLA.
• Zdecyduj, w jaki sposób opublikujesz zawartość: wybierz podejście do publikowania zawartości, która najlepiej odpowiada przepływowi pracy i potrzebom. Upewnij się, że takie podejście jest zgodne z innymi strategiami, takimi jak śledzenie zmian i zarządzanie nimi.
• Zdecyduj, w jaki sposób podwyższasz poziom zawartości między obszarami roboczymi: wybierz podejście do wdrażania zawartości z obszaru projektowego do testowania obszarów roboczych i od testowania do obszarów roboczych 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 interfejsów API REST sieci szkieletowej.
• Wykonaj konfigurację przy pierwszym konfigurowaniu narzędzi i procesów wdrażania: upewnij się, że skonfigurowaliśmy odpowiedni dostęp, a uprawnienia są zgodne z sposobem konfigurowania dostępu do zawartości.
• Wdrażanie zawartości w środowisku produkcyjnym: po zaplanowanym i skonfigurowanym wdrożeniu wdróż zawartość w środowisku produkcyjnym.

Powiązana zawartość

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