Scenariusze użycia usługi Power BI: publikowanie zawartości przedsiębiorstwa

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.

Gdy twórcy zawartości współpracują z dostarczaniem rozwiązań analitycznych, które są ważne dla organizacji, muszą zapewnić terminowe i niezawodne dostarczanie zawartości konsumentom. Zespoły techniczne rozwiązują to wyzwanie przy użyciu procesu o nazwie DevOps. Metodyka DevOps umożliwia zespołom automatyzowanie i skalowanie procesów dzięki wdrożeniu rozwiązań, które usprawniają i przyspieszają dostarczanie.

Uwaga

Zespoły danych, które sprostają tym samym wyzwaniom, mogą również ćwiczyć operację DataOps. Metodyka DataOps opiera się na zasadach metodyki DevOps, ale metodyka DataOps zawiera dodatkowe rozwiązania specyficzne dla zarządzania danymi, takie jak kontrola jakości danych i ład. W tym artykule odwołujemy się do metodyki DevOps, ale należy pamiętać, że podstawowe zasady mogą również mieć zastosowanie do metodyki DataOps.

Twórcy zawartości i konsumenci korzystają z kilku zalet podczas wdrażania praktyk DevOps w celu publikowania zawartości usługi Power BI. Poniżej przedstawiono ogólne omówienie sposobu działania tego procesu.

1. Opracowywanie zawartości i zatwierdzanie pracy w repozytorium zdalnym: twórcy zawartości opracowują swoje rozwiązanie na własnej maszynie. Zatwierdzają i zapisują swoją pracę w repozytorium zdalnym w regularnych odstępach czasu podczas opracowywania. Repozytorium zdalne zawiera najnowszą wersję rozwiązania i jest dostępne dla całego zespołu deweloperskiego.
2. Współpraca nad zmianami zawartości i zarządzanie nimi przy użyciu kontroli wersji: inni twórcy zawartości mogą wprowadzać poprawki do rozwiązania, tworząc gałąź. Gałąź jest kopią repozytorium zdalnego. Gdy te poprawki są gotowe i zatwierdzone, gałąź zostanie scalona z najnowszą wersją rozwiązania. Wszystkie poprawki rozwiązania są śledzone. Ten proces jest nazywany kontrolą wersji (lub kontrolą źródła).
3. Wdrażanie i podwyższanie poziomu zawartości przy użyciu potoków: w scenariuszu użycia samodzielnej zawartości publikowania zawartości jest promowana (lub wdrażana) za pośrednictwem obszarów roboczych programowania, testowania i produkcji przy użyciu potoków wdrażania usługi Power BI. Potoki wdrażania usługi Power BI mogą ręcznie podwyższyć poziom zawartości do obszarów roboczych usługi Power BI Premium przy użyciu interfejsu użytkownika lub programowo przy użyciu interfejsów API REST. Z kolei publikowanie zawartości przedsiębiorstwa (skupienie się na tym scenariuszu użycia) promuje zawartość przy użyciu usługi Azure Pipelines. Azure Pipelines to usługa Azure DevOps, która automatyzuje testowanie, zarządzanie i wdrażanie zawartości przy użyciu serii dostosowanych kroków programistycznych. W scenariuszu użycia publikowania zawartości przedsiębiorstwa te potoki mogą być również nazywane potokami ciągłej integracji i wdrażania (lub ciągłego wdrażania/ciągłego wdrażania ). Te potoki często i automatycznie integrują zmiany i usprawniają publikowanie zawartości.

Ważne

Czasami w tym artykule opisano usługę Power BI Premium lub jej subskrypcje pojemności (jednostki SKU P). Należy pamiętać, że firma Microsoft obecnie konsoliduje opcje zakupu i cofnie usługę Power BI Premium na jednostki SKU pojemności. Nowi i istniejący klienci powinni rozważyć zakup subskrypcji pojemności sieci szkieletowej (jednostki SKU F).

Aby uzyskać więcej informacji, zobacz Ważne aktualizacje dostępne w licencjonowaniu usługi Power BI Premium i Power BI Premium — często zadawane pytania.

Metodyka DevOps obsługuje dojrzałe, systematyczne podejście do zarządzania zawartością i publikacji. Umożliwia twórcom zawartości współpracę nad rozwiązaniami i zapewnia szybkie i niezawodne dostarczanie zawartości użytkownikom. W przypadku przestrzegania praktyk DevOps możesz korzystać z usprawnionych przepływów pracy, mniejszej liczby błędów i ulepszonych środowisk dla twórców zawartości i użytkowników zawartości.

Za pomocą usługi Azure DevOps skonfigurujesz rozwiązania Usługi Power BI i zarządzasz nimi. W scenariuszach przedsiębiorstwa można zautomatyzować publikację zawartości za pomocą usługi Azure DevOps i interfejsów API REST usługi Power BI na trzy różne sposoby.

• Interfejsy API REST usługi Power BI z potokami wdrażania usługi Power BI: możesz zaimportować zawartość do obszarów roboczych programowania i używać potoków wdrażania do wdrażania zawartości za pośrednictwem obszarów roboczych testowych i produkcyjnych. Nadal kontrolujesz wdrażanie z usługi Azure DevOps i używasz interfejsów API REST usługi Power BI do zarządzania potokami wdrażania zamiast poszczególnych elementów zawartości. Ponadto używasz punktu końcowego XMLA do wdrażania metadanych modelu danych zamiast pliku programu Power BI Desktop (pbix) z usługą Azure DevOps. Te metadane umożliwiają śledzenie zmian na poziomie obiektu przy użyciu kontroli wersji. Chociaż jest ona bardziej niezawodna i łatwiejsza w obsłudze, takie podejście wymaga licencjonowania w warstwie Premium i umiarkowanego nakładu pracy przy konfigurowaniu importowania i wdrażania zawartości przy użyciu interfejsów API REST usługi Power BI. Użyj tego podejścia, jeśli chcesz uprościć zarządzanie cyklem życia zawartości przy użyciu potoków wdrażania i masz licencję Premium. Punkt końcowy XMLA i potoki wdrażania usługi Power BI to funkcje Premium.
• Interfejsy API REST usługi Power BI: możesz również zaimportować zawartość do obszarów roboczych programowania, testowania i produkcji przy użyciu usługi Azure DevOps i tylko interfejsów API REST usługi Power BI. Takie podejście nie wymaga licencjonowania w warstwie Premium, ale wiąże się z dużym nakładem pracy i konfiguracją skryptów, ponieważ wdrożenie jest zarządzane poza usługą Power BI. Użyj tej metody, jeśli chcesz wdrożyć zawartość usługi Power BI centralnie z usługi Azure DevOps lub gdy nie masz licencji Premium. Aby zapoznać się z porównaniem wizualnym między dwoma pierwszymi podejściami, zobacz diagram przepływu potoku wydania.
• Narzędzia automatyzacji usługi Power BI z potokami wdrażania usługi Power BI: możesz użyć narzędzi automatyzacji usługi Azure DevOps do zarządzania potokami wdrażania zamiast interfejsów API REST usługi Power BI. Ta metoda jest alternatywą dla pierwszej opcji, która korzysta z interfejsów API REST usługi Power BI z potokami wdrażania usługi Power BI. Rozszerzenie narzędzi automatyzacji usługi Power BI jest narzędziem typu open source. Ułatwia ona zarządzanie i publikowanie zawartości z usługi Azure DevOps bez konieczności pisania skryptów programu PowerShell. Użyj tego podejścia, jeśli chcesz zarządzać potokami wdrażania z usługi Azure DevOps przy minimalnym wysiłku tworzenia skryptów i masz pojemność Premium.

Ten artykuł koncentruje się na pierwszej opcji, która korzysta z interfejsów API REST usługi Power BI z potokami wdrażania usługi Power BI. W tym artykule opisano, jak za pomocą usługi Azure DevOps skonfigurować rozwiązania DevOps. W tym artykule opisano również, jak można używać usługi Azure Repos dla repozytoriów zdalnych i automatyzować testowanie zawartości, integrację i dostarczanie za pomocą usługi Azure Pipelines. Usługa Azure DevOps nie jest jedynym sposobem skonfigurowania publikowania zawartości przedsiębiorstwa, ale prosta integracja z usługą Power BI sprawia, że jest to dobry wybór.

Uwaga

Ten scenariusz użycia jest jednym z scenariuszy zarządzania zawartością i wdrażania . W przypadku zwięzłości niektóre aspekty opisane w temacie dotyczącym współpracy i dostarczania zawartości nie zostały omówione w tym artykule. Aby uzyskać pełne pokrycie, najpierw przeczytaj te artykuły.

Napiwek

Usługa Microsoft Fabric udostępnia inne opcje publikowania zawartości przedsiębiorstwa przy użyciu integracji z usługą Git usługi Fabric. Integracja z usługą Git umożliwia łączenie obszaru roboczego usługi Fabric z gałęzią w repozytorium zdalnym usługi Azure Repos. Zawartość zapisana w tej gałęzi zostanie automatycznie zsynchronizowana z obszarem roboczym, tak jakby ta zawartość została opublikowana w obszarze roboczym. Z drugiej strony twórcy zawartości mogą zatwierdzać i wypychać zmiany z obszaru roboczego sieć szkieletowa do repozytorium zdalnego.

Integracja z usługą Git może usprawnić współpracę i publikowanie zawartości, ale wymaga więcej planowania sposobu używania obszarów roboczych sieci szkieletowej i strategii rozgałęziania. Aby uzyskać więcej informacji na temat sposobu konfigurowania i używania integracji z usługą Git w sieci szkieletowej, zobacz Wprowadzenie do integracji z usługą Git lub Samouczek: kompleksowe zarządzanie cyklem życia.

Diagram scenariusza

Na poniższym diagramie przedstawiono ogólne omówienie najpopularniejszych akcji użytkownika i składników usługi Power BI, które obsługują publikowanie zawartości przedsiębiorstwa. Koncentruje się on na korzystaniu z usługi Azure DevOps do programowego zarządzania zawartością i publikowania jej na dużą skalę za pośrednictwem obszarów roboczych programowania, testowania i produkcji w usługa Power BI.

Napiwek

Zachęcamy do pobrania diagramu scenariusza, jeśli chcesz go osadzić w prezentacji, dokumentacji lub wpisie w blogu albo wydrukować go jako plakat na ścianie. Ponieważ jest to obraz skalowalnej grafiki wektorowej (SVG), można go skalować w górę lub w dół bez utraty jakości.

Diagram scenariusza przedstawia następujące akcje, procesy i funkcje użytkownika.

Produkt	Opis
	Twórcy zawartości tworzą modele danych przy użyciu programu Power BI Desktop lub Edytora tabelarycznego i tworzą raporty przy użyciu programu Power BI Desktop. Twórcy zawartości zapisują swoją pracę w repozytorium lokalnym podczas opracowywania.
	Twórcy zawartości mogą sklonować zdalne repozytorium, aby uzyskać lokalną kopię tej zawartości.
	Niektóre źródła danych mogą wymagać lokalnej bramy danych lub bramy sieci wirtualnej na potrzeby odświeżania danych, takich jak te, które znajdują się w prywatnej sieci organizacyjnej.
	Twórcy zawartości regularnie zatwierdzają i wypychają zmiany do repozytorium zdalnego podczas opracowywania przy użyciu klienta Git, takiego jak Visual Studio Code. Na diagramie repozytorium zdalne to Azure Repos.
	Inni twórcy zawartości używają usługi Azure Repos do śledzenia zmian za pomocą kontroli wersji. Współpracują, zatwierdzając zmiany w oddzielnych gałęziach.
	Zmiany zawartości w repozytorium zdalnym wyzwalają usługę Azure Pipelines. Potok weryfikacji to pierwszy wyzwalany potok. Potok weryfikacji wykonuje testy automatyczne w celu zweryfikowania zawartości przed jej opublikowaniem.
	Zawartość przechodząca przez potok weryfikacji wyzwala kolejny potok kompilacji. Potok kompilacji przygotowuje zawartość do publikowania w usługa Power BI. Proces do tego momentu jest zwykle określany jako ciągła integracja .
	Zawartość jest publikowana i wdrażana przy użyciu potoków wydania. Potoki wydania używają interfejsów API REST usługi Power BI lub punktu końcowego XMLA obszaru roboczego do programowego importowania zawartości do usługa Power BI. Wdrażanie przy użyciu potoków wydania jest zwykle określane jako ciągłe wdrażanie (CD).
	Menedżer wersji kontroluje wdrażanie w celu testowania i produkcji obszarów roboczych przy użyciu zatwierdzania wydania usługi Azure Pipelines. W przypadku publikowania zawartości przedsiębiorstwa menedżer wersji zwykle planuje i koordynuje wydanie zawartości w środowiskach testowych i produkcyjnych. Koordynują i komunikują się z twórcami zawartości, uczestnikami projektu i użytkownikami.
	Potok wydania publikuje zawartość w obszarze roboczym programowania lub promuje zawartość z programowania do obszarów roboczych testowych lub testuje do obszarów roboczych produkcyjnych.
	Twórcy zawartości pracujący w obszarze roboczym z trybem licencji pojemności sieci szkieletowej mogą korzystać z integracji z usługą Git. Dzięki integracji z usługą Git twórcy zawartości mogą pracować w prywatnym obszarze roboczym podczas opracowywania. Twórca zawartości synchronizuje gałąź zdalną (zazwyczaj konkretną gałąź funkcji lub gałąź usterek) z usługi Azure Repos do prywatnego obszaru roboczego. Zmiany zawartości są synchronizowane między gałęzią zdalną w usłudze Azure Repos i obszarem roboczym. W tym scenariuszu twórcy zawartości nie muszą używać usługi Azure Pipelines do publikowania zawartości. Twórcy zawartości mogą również regularnie zatwierdzać i wypychać zmiany z obszaru roboczego po opublikowaniu. Gdy wszystko będzie gotowe, twórcy zawartości mogą wysłać żądanie ściągnięcia w celu scalenia zmian w gałęzi głównej.
	W przypadku korzystania z integracji z usługą Git obszar roboczy programowania synchronizuje się z gałęzią główną, aby uzyskać najnowsze wersje zawartości. Ta zawartość zawiera wszystkie zmiany żądań ściągnięcia, które menedżer wersji przegląda, zatwierdza i scala.
	Obszary robocze są ustawione na pojemność sieci szkieletowej, pojemność Premium, Premium na użytkownika lub tryb licencji osadzonej, aby umożliwić korzystanie z potoków wdrażania usługi Power BI i punktu końcowego odczytu/zapisu XMLA.
	Administrator potoku wdrażania konfiguruje potok wdrażania usługi Power BI z trzema etapami: programowanie, testowanie i produkcja. Każdy etap jest wyrównany do oddzielnego obszaru roboczego w usługa Power BI. Ustawienia wdrożenia i dostęp są ustawiane dla potoku wdrażania.
	Obszar roboczy programowania zawiera najnowsze wersje zawartości, w tym wszystkie zatwierdzone i scalone zmiany. Po zatwierdzeniu potok wydania wdraża zawartość z programowania w obszarze roboczym testowym.
	Recenzenci w obszarze roboczym testowym wykonują testy i kontrolę jakości zawartości. Po zatwierdzeniu potok wydania wdraża zawartość z testu w obszarze roboczym produkcyjnym. W przypadku korzystania z integracji z usługą Git z potokami wdrażania obszar roboczy testowy nie jest synchronizowany z żadną gałęzią.
	Po zakończeniu wdrażania potok wdrażania twórcy zawartości ręcznie wykonują działania po wdrożeniu. Działania mogą obejmować konfigurowanie zaplanowanego odświeżania danych lub aktualizowanie aplikacji usługi Power BI dla produkcyjnego obszaru roboczego. W przypadku korzystania z integracji z usługą Git z potokami wdrażania obszar roboczy produkcyjny nie jest synchronizowany z żadną gałęzią.
	Osoby przeglądające zawartość uzyskują dostęp do zawartości przy użyciu produkcyjnego obszaru roboczego lub aplikacji usługi Power BI.

Napiwek

Zalecamy również przejrzenie scenariuszy użycia samoobsługowego publikowania zawartości i zaawansowanego zarządzania modelami danych. Scenariusz użycia publikowania zawartości przedsiębiorstwa opiera się na pojęciach, które wprowadzono w tych scenariuszach.

Kwestie kluczowe

Poniżej przedstawiono niektóre kluczowe kwestie, które należy podkreślić w scenariuszu publikowania zawartości przedsiębiorstwa.

Kontrola wersji

Śledzenie zmian w cyklu życia zawartości jest ważne, aby zapewnić stabilne i spójne dostarczanie zawartości użytkownikom. W tym scenariuszu użycia twórcy zawartości i właściciele zarządzają zmianami zawartości w repozytorium zdalnym przy użyciu kontroli wersji. Kontrola wersji to praktyka zarządzania zmianami w plikach lub kodzie w centralnym repozytorium. Ta praktyka umożliwia lepszą współpracę i skuteczne zarządzanie historią wersji. Kontrola wersji ma zalety dla twórców zawartości, w tym możliwość wycofywania lub scalania zmian.

Twórcy zawartości zwykle tworzą modele danych w edytorze tabelarycznym, aby obsługiwać lepszą kontrolę wersji. W przeciwieństwie do modelu danych opracowywanego w programie Power BI Desktop model danych opracowany w edytorze tabelarycznym jest zapisywany w formacie metadanych czytelnych dla człowieka. Ten format umożliwia kontrolę wersji na poziomie obiektu modelu danych. Podczas współpracy z wieloma osobami w tym samym modelu danych należy użyć kontroli wersji na poziomie obiektu. Aby uzyskać więcej informacji, zobacz zaawansowany scenariusz użycia zarządzania modelami danych. Nie można zobaczyć zmian wprowadzonych w pliku programu Power BI Desktop (pbix), takich jak definicja raportu lub model danych. Na przykład nie można śledzić zmian na stronie raportu, takich jak używane wizualizacje, ich pozycje i mapowania pól ani formatowanie.

Twórcy zawartości przechowują pliki metadanych modelu danych i pliki pbix w centralnym repozytorium zdalnym, na przykład azure Repos. Te pliki są nadzorowane przez właściciela technicznego. Podczas gdy twórca zawartości opracowuje rozwiązanie, właściciel techniczny jest odpowiedzialny za zarządzanie rozwiązaniem i przeglądanie zmian oraz scalanie ich w jednym rozwiązaniu. Usługa Azure Repos udostępnia zaawansowane opcje śledzenia zmian i zarządzania nimi. Takie podejście różni się od podejścia opisanego w scenariuszu użycia samoobsługowego publikowania zawartości, w którym twórca korzysta z magazynu w usłudze OneDrive ze śledzeniem wersji. Utrzymanie dobrze wyselekcjonowanych, udokumentowanych repozytoriów jest niezbędne, ponieważ jest podstawą całej zawartości i współpracy.

Poniżej przedstawiono kilka kluczowych zagadnień, które ułatwiają skonfigurowanie zdalnego repozytorium na potrzeby kontroli wersji.

• Zakres: Jasno zdefiniuj zakres repozytorium. W idealnym przypadku zakres repozytorium jest identyczny z zakresem podrzędnych obszarów roboczych i aplikacji używanych do dostarczania zawartości użytkownikom.
• Dostęp: należy skonfigurować dostęp do repozytorium przy użyciu podobnego modelu uprawnień, który został skonfigurowany dla uprawnień potoku wdrażania i ról obszaru roboczego. Twórcy zawartości potrzebują dostępu do repozytorium.
• Dokumentacja: Dodawanie plików tekstowych do repozytorium w celu udokumentowania jego przeznaczenia, własności, dostępu i zdefiniowanych procesów. Na przykład w dokumentacji można opisać sposób tworzenia i zatwierdzania zmian.
• Narzędzia: aby zatwierdzić i wypchnąć zmiany do repozytorium zdalnego, twórcy zawartości potrzebują klienta Git, takiego jak Visual Studio lub Visual Studio Code. Git to rozproszony system kontroli wersji, który śledzi zmiany w plikach. Aby poznać podstawy usługi Git, zobacz Co to jest usługa Git?.

Uwaga

Rozważ użycie usługi Git Large File Storage (LFS), jeśli planujesz zatwierdzać pliki programu Power BI Desktop (pbix). Usługa Git LFS udostępnia zaawansowane opcje zarządzania plikami, w których zmiany nie są widoczne (nieiffowalne pliki), takie jak plik pbix. Na przykład możesz użyć blokady plików, aby zapobiec równoczesnym zmianom raportu usługi Power BI podczas programowania. Jednak usługa Git LFS ma własnego klienta i konfigurację.

Współpraca z usługą Azure DevOps

W miarę zwiększania zakresu i złożoności rozwiązania może być konieczne, aby wielu twórców zawartości i właścicieli pracowało we współpracy. Twórcy zawartości i właściciele komunikują się i współpracują w centralnym, zorganizowanym centrum przy użyciu usługi Azure DevOps.

Aby współpracować i komunikować się w usłudze Azure DevOps, należy używać usług pomocniczych.

• Azure Boards: właściciele zawartości używają tablic do śledzenia elementów roboczych. Elementy robocze są przypisywane do jednego dewelopera w zespole i opisują problemy, błędy lub funkcje w rozwiązaniu oraz odpowiednie osoby biorące udział w projekcie.
• Witryna typu wiki platformy Azure: Twórcy zawartości udostępniają swojemu zespołowi informacje, aby zrozumieć i współtworzyć rozwiązanie.
• Azure Repos: twórcy zawartości śledzą zmiany w repozytorium zdalnym i scalają je w jednym rozwiązaniu.
• Azure Pipelines: właściciele potoków konfigurują logikę programową w celu wdrożenia rozwiązania — automatycznie lub na żądanie.

Diagram przepływu współpracy

Na poniższym diagramie przedstawiono ogólny przegląd jednego przykładu sposobu, w jaki usługa Azure DevOps umożliwia współpracę w scenariuszu użycia publikowania zawartości przedsiębiorstwa. Ten diagram koncentruje się na użyciu usługi Azure DevOps w celu utworzenia ustrukturyzowanego i udokumentowanego procesu publikowania zawartości.

Diagram przedstawia następujące akcje użytkownika, procesy i funkcje.

Produkt	Opis
	Twórca zawartości tworzy nową, krótkotrwałą gałąź, klonując gałąź główną, która zawiera najnowszą wersję zawartości. Nowa gałąź jest często określana jako gałąź funkcji , ponieważ służy do tworzenia określonej funkcji lub rozwiązywania określonego problemu.
	Twórca zawartości zatwierdza zmiany w repozytorium lokalnym podczas opracowywania.
	Twórca zawartości łączy swoje zmiany z elementami roboczymi zarządzanymi w usłudze Azure Boards. Elementy robocze opisują konkretne zmiany, ulepszenia lub poprawki błędów w zakresie ich gałęzi.
	Twórca zawartości regularnie zatwierdza zmiany. Gdy wszystko będzie gotowe, twórca zawartości publikuje swoją gałąź w repozytorium zdalnym.
	Aby przetestować zmiany, twórca zawartości wdraża swoje rozwiązanie w izolowanym obszarze roboczym na potrzeby programowania (nie pokazano na tym diagramie). Twórca zawartości może również zsynchronizować gałąź funkcji z obszarem roboczym przy użyciu integracji z usługą Fabric Git.
	Twórcy zawartości i właściciele zawartości dokumentują rozwiązanie i jego procesy w witrynie Azure Wiki, która jest dostępna dla całego zespołu deweloperów.
	Gdy wszystko będzie gotowe, twórca zawartości otworzy żądanie ściągnięcia, aby scalić gałąź funkcji z gałęzią główną.
	Właściciel techniczny jest odpowiedzialny za przeglądanie żądania ściągnięcia i scalanie zmian. Po zatwierdzeniu żądania ściągnięcia scalają gałąź funkcji z gałęzią główną.
	Pomyślne scalanie wyzwala wdrożenie rozwiązania w obszarze roboczym programowania przy użyciu usługi Azure Pipeline (nie pokazano na tym diagramie). W przypadku korzystania z integracji z usługą Fabric Git gałąź główna synchronizuje się z obszarem roboczym programowania.
	Menedżer wersji przeprowadza ostateczną weryfikację i zatwierdzenie rozwiązania. To zatwierdzenie wydania uniemożliwia opublikowanie rozwiązania przed jego przygotowaniem. W przypadku publikowania zawartości przedsiębiorstwa menedżer wersji zazwyczaj planuje i koordynuje wydanie zawartości w celu testowania i produkcji obszarów roboczych. Koordynują i komunikują się z twórcami zawartości, uczestnikami projektu i użytkownikami.
	Gdy menedżer wydania zatwierdzi wydanie, usługa Azure Pipelines automatycznie przygotuje rozwiązanie do wdrożenia. Alternatywnie potok wdrażania usługi Azure Pipeline może również wyzwolić potok wdrażania w celu podwyższenia poziomu zawartości między obszarami roboczymi.
	Użytkownicy testować i weryfikować zawartość w obszarze roboczym testowym. W przypadku korzystania z integracji usługi Git z usługą Azure Pipelines do wdrożenia obszar roboczy testowy nie jest synchronizowany z żadną gałęzią.
	Po zaakceptowaniu i zweryfikowaniu zmian przez użytkownika menedżer wydania przeprowadzi ostateczną recenzję i zatwierdzenie rozwiązania w celu wdrożenia w produkcyjnym obszarze roboczym.
	Użytkownicy wyświetlają zawartość opublikowaną w produkcyjnym obszarze roboczym. W przypadku korzystania z integracji usługi Git z usługą Azure Pipelines do wdrożenia obszar roboczy produkcyjny nie jest synchronizowany z żadną gałęzią.

Aby rozwinąć, twórcy zawartości osiągają współpracę przy użyciu strategii rozgałęziania. Strategia rozgałęziania polega na tym, jak twórcy zawartości tworzą, używają i scalają gałęzie, aby skutecznie wprowadzać zmiany zawartości i zarządzać nimi. Indywidualni twórcy zawartości pracują w izolacji w repozytorium lokalnym. Gdy wszystko będzie gotowe, łączą swoje zmiany jako pojedyncze rozwiązanie w repozytorium zdalnym. Twórcy zawartości powinni ograniczyć ich pracę do gałęzi, łącząc je z elementami roboczymi w celu uzyskania konkretnych ulepszeń, ulepszeń lub poprawek błędów. Każdy twórca zawartości tworzy własną gałąź repozytorium zdalnego dla zakresu pracy. Praca wykonywana na ich lokalnym rozwiązaniu jest zatwierdzana i wypychana do wersji gałęzi w repozytorium zdalnym z komunikatem zatwierdzenia. Komunikat zatwierdzenia opisuje zmiany wprowadzone w tym zatwierdzeniu.

Aby scalić zmiany, twórca zawartości otwiera żądanie ściągnięcia. Żądanie ściągnięcia to przesłanie do przeglądu równorzędnego, które może prowadzić do scalenia pracy wykonanej w jednym rozwiązaniu. Scalanie może powodować konflikty, które należy rozwiązać, zanim będzie można scalić gałąź. Przeglądy żądań ściągnięcia są ważne, aby zapewnić, że twórcy przestrzegają standardów organizacyjnych i praktyk dotyczących programowania, jakości i zgodności.

Zalecenia dotyczące współpracy

Zalecamy zdefiniowanie strukturalnego procesu współpracy twórców zawartości. Upewnij się, że określono:

• Jak działa zakres i jak gałęzie są tworzone, nazwane i używane.
• Jak autorzy grupują zmiany i opisują je za pomocą komunikatów zatwierdzenia.
• Kto jest odpowiedzialny za przeglądanie i zatwierdzanie żądań ściągnięcia.
• Jak są rozwiązywane konflikty scalania.
• Sposób scalania zmian w różnych gałęziach w jednej gałęzi.
• Sposób testowania zawartości i przeprowadzania testów przed wdrożeniem zawartości.
• Jak i kiedy zmiany są wdrażane w obszarach roboczych programowania, testowania i produkcji.
• Jak i kiedy wdrażane zmiany lub wersje rozwiązania powinny zostać wycofane.

Ważne

Wartość zapewniana przez metodyę DevOps jest bezpośrednio proporcjonalna do przestrzegania procesów definiujących jego użycie.

Pomyślna współpraca zależy od dobrze zdefiniowanego procesu. Ważne jest, aby jasno opisać i udokumentować pełny przepływ pracy programowania. Upewnij się, że wybrane strategie i procesy są zgodne z istniejącymi rozwiązaniami w zespole, a jeśli nie, sposób zarządzania zmianami. Ponadto upewnij się, że procesy są jasne i przekazywane wszystkim członkom zespołu i uczestnikom projektu. Upewnij się, że członkowie zespołu i uczestnicy projektu, którzy są nowi w procesach, są przeszkoleni w sposobie ich wdrażania i że doceniają wartość pomyślnego wdrożenia metodyki DevOps.

Interfejsy API REST usługi Power BI

Tworzysz logikę programową do importowania i wdrażania zawartości z usługi Azure DevOps przy użyciu interfejsów API REST usługi Power BI. Pliki usługi Power BI (pbix) są importowane do obszaru roboczego przy użyciu operacji importowania. Za pomocą operacji potoku można wdrożyć część zawartości lub całą zawartość do testowania lub produkcyjnych obszarów roboczych przy użyciu potoków wdrażania usługi Power BI. Logika programowa jest definiowana w usłudze Azure Pipelines.

Zalecamy używanie jednostki usługi do wywoływania interfejsów API REST usługi Power BI w potokach. Jednostka usługi jest przeznaczona dla nienadzorowanych, zautomatyzowanych działań i nie opiera się na poświadczeniach użytkownika. Jednak niektóre elementy i działania nie są obsługiwane przez interfejsy API REST usługi Power BI ani w przypadku korzystania z jednostki usługi, takich jak przepływy danych.

W przypadku korzystania z jednostki usługi należy dokładnie zarządzać uprawnieniami. Twoim celem powinno być przestrzeganie zasady najniższych uprawnień. Należy ustawić wystarczające uprawnienia dla jednostki usługi bez uprawnień nadmiernej aprowizacji. Użyj usługi Azure Key Vault lub innej usługi, która bezpiecznie przechowuje wpisy tajne i poświadczenia jednostki usługi.

Uwaga

Jeśli masz model danych, który jest zapisywany jako format metadanych czytelny dla człowieka, nie można go opublikować przy użyciu interfejsów API REST usługi Power BI. Zamiast tego należy opublikować go przy użyciu punktu końcowego XMLA. Pliki metadanych można publikować przy użyciu narzędzi innych firm, takich jak interfejs wiersza polecenia edytora tabelarycznego. Pliki metadanych można również publikować programowo przy użyciu własnego niestandardowego programowania na platformie .NET. Tworzenie niestandardowego rozwiązania wymaga większego nakładu pracy, ponieważ należy użyć rozszerzenia Modelu obiektów tabelarycznych firmy Microsoft (TOM) bibliotek klienckich obiektów zarządzania analizami (AMO).

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. Właściciele potoków mogą dostosować swoje 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. Na przykład usługa Azure Pipeline może uruchamiać testy automatyczne lub modyfikować parametry modelu danych przed wdrożeniem.

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 trzeba mieć wszystkich trzech z tych 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 usługi Power BI. Na przykład nie musisz mieć potoku weryfikacji; Można używać tylko potoków kompilacji i wydań.

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 (opisany na diagramie potoków wydania). Potok kompilacji może również wprowadzać inne 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 programu Power BI Desktop (pbix), które są gotowe do publikacji 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.

Istnieją dwa różne podejścia do publikowania zawartości przy użyciu potoków testów i wydania. Podwyższają poziom zawartości przy użyciu potoku wdrażania usługi Power BI lub publikują zawartość w usługa Power BI z usługi Azure DevOps.

Na poniższym diagramie przedstawiono pierwsze podejście. 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 usługi Power BI. Zawartość jest promowana za pośrednictwem obszarów roboczych tworzenia, testowania i produkcji w usłudze Power BI. Chociaż takie podejście jest bardziej niezawodne i prostsze w obsłudze, wymaga licencjonowania w warstwie Premium.

Diagram przedstawia następujące akcje użytkownika, procesy i funkcje pierwszego podejścia.

Produkt	Opis
	W pierwszym podejściu potoki wydania publikują zawartość przy użyciu punktu końcowego XMLA i interfejsów API REST usługi Power BI z potokami wdrażania usługi Power BI. Zawartość jest publikowana, a następnie promowana za pośrednictwem obszarów roboczych tworzenia, testowania i produkcji. Potoki wdrażania usługi Power BI i punkt końcowy odczytu/zapisu XMLA to funkcje Premium.
	Scalanie gałęzi lub uzupełnianie potoku nadrzędnego wyzwala potok kompilacji. Następnie potok kompilacji przygotowuje zawartość do publikowania i wyzwala potok wydania dewelopera.
	Potok wydania programowania publikuje zawartość w obszarze roboczym programowania przy użyciu punktu końcowego XMLA (dla metadanych modelu danych) lub interfejsów API REST usługi Power BI (dla plików programu Power BI Desktop, które mogą zawierać modele danych i raporty). Potok programowania używa interfejsu wiersza polecenia (CLI) edytora tabelarycznego do wdrażania metadanych modelu danych przy użyciu punktu końcowego XMLA.
	Wyzwalacz zatwierdzania wersji lub wyzwalacza na żądanie aktywuje potok wydania testowego.
	Potok wydania testowego wdraża zawartość przy użyciu operacji wdrażania interfejsu API REST usługi Power BI, które uruchamiają potok wdrażania usługi Power BI.
	Potok wdrażania usługi Power BI promuje zawartość z obszaru roboczego programowania do obszaru roboczego testowego. Po wdrożeniu potok wydania wykonuje działania po wdrożeniu przy użyciu interfejsów API REST usługi Power BI (nie pokazanych na diagramie).
	Wyzwalacz zatwierdzania wersji lub wyzwalacza na żądanie aktywuje potok wydania produkcyjnego.
	Potok wydania produkcyjnego wdraża zawartość przy użyciu operacji wdrażania interfejsu API REST usługi Power BI, które uruchamiają potok wdrażania usługi Power BI.
	Potok wdrażania usługi Power BI promuje zawartość z obszaru roboczego testowego do obszaru roboczego produkcyjnego. Po wdrożeniu potok wydania wykonuje działania po wdrożeniu przy użyciu interfejsów API REST usługi Power BI (nie pokazanych na diagramie).

Na poniższym diagramie przedstawiono drugie podejście. Takie podejście nie korzysta z potoków wdrażania. Zamiast tego używa potoków wydania do publikowania zawartości w obszarach roboczych testowych i produkcyjnych z usługi Azure DevOps. W szczególności drugie podejście nie wymaga licencjonowania w warstwie Premium podczas publikowania tylko plików programu Power BI Desktop przy użyciu interfejsów API REST usługi Power BI. 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ą być bardziej znane z tego podejścia. Zespoły programistyczne korzystające z tego podejścia mogą skonsolidować wdrażanie rozwiązań danych w usłudze Azure DevOps.

Diagram przedstawia następujące akcje, procesy i funkcje użytkownika w drugim podejściu.

Produkt	Opis
	W drugim podejściu potoki wydania publikują zawartość przy użyciu tylko punktu końcowego XMLA i interfejsów API REST usługi Power BI. Zawartość jest publikowana w obszarach roboczych tworzenia, testowania i produkcji.
	Scalanie gałęzi lub uzupełnianie potoku nadrzędnego wyzwala potok kompilacji. Następnie potok kompilacji przygotowuje zawartość do publikowania i wyzwala potok wydania dewelopera.
	Potok wydania programowania publikuje zawartość w obszarze roboczym programowania przy użyciu punktu końcowego XMLA (dla metadanych modelu danych) lub interfejsów API REST usługi Power BI (dla plików programu Power BI Desktop, które mogą zawierać modele danych i raporty). Potok programowania używa interfejsu wiersza polecenia (CLI) edytora tabelarycznego do wdrażania metadanych modelu danych przy użyciu punktu końcowego XMLA.
	Wyzwalacz zatwierdzania wersji lub wyzwalacza na żądanie aktywuje potok wydania testowego.
	Potok wydania programowania publikuje zawartość w obszarze roboczym testowym przy użyciu punktu końcowego XMLA (dla metadanych modelu danych) lub interfejsów API REST usługi Power BI (dla plików programu Power BI Desktop, które mogą zawierać modele danych i raporty). Potok programowania używa interfejsu wiersza polecenia (CLI) edytora tabelarycznego do wdrażania metadanych modelu danych przy użyciu punktu końcowego XMLA. Po wdrożeniu potok wydania wykonuje działania po wdrożeniu przy użyciu interfejsów API REST usługi Power BI (nie pokazanych na diagramie).
	Wyzwalacz zatwierdzania wersji lub wyzwalacza na żądanie aktywuje potok wydania produkcyjnego.
	Potok wydania programistycznego publikuje zawartość w produkcyjnym obszarze roboczym przy użyciu punktu końcowego XMLA (dla metadanych modelu danych) lub interfejsów API REST usługi Power BI (dla plików programu Power BI Desktop, które mogą zawierać modele danych i raporty). Potok programowania używa interfejsu wiersza polecenia (CLI) edytora tabelarycznego do wdrażania metadanych modelu danych przy użyciu punktu końcowego XMLA. Po wdrożeniu potok wydania wykonuje działania po wdrożeniu przy użyciu interfejsów API REST usługi Power BI (nie pokazanych na diagramie).

Potoki wydania powinny zarządzać działaniami po wdrożeniu. Te działania mogą obejmować ustawianie poświadczeń semantycznego modelu lub aktualizowanie aplikacji usługi Power BI dla obszarów roboczych testowych i produkcyjnych. Zalecamy skonfigurowanie powiadomień w celu informowania odpowiednich osób o działaniach związanych z wdrażaniem.

Napiwek

Używanie repozytorium do kontroli wersji umożliwia twórcom zawartości tworzenie procesu wycofywania. Proces wycofywania może odwrócić ostatnie wdrożenie, przywracając poprzednią wersję. Rozważ utworzenie oddzielnego zestawu usługi Azure Pipelines, który można wyzwolić w celu wycofania zmian produkcyjnych. Należy dokładnie zastanowić się, jakie procesy i zatwierdzenia są wymagane do zainicjowania wycofywania. Upewnij się, że te procesy są udokumentowane.

Potoki wdrażania usługi Power BI

Potok wdrażania usługi Power BI składa się z trzech etapów: programowania, testowania i produkcji. Do każdego etapu w potoku wdrażania przypisuje się jeden obszar roboczy usługi Power BI. W przypadku wdrożenia potok wdrażania promuje elementy usługi Power BI z jednego obszaru roboczego do innego.

Potok wydania usługi Azure Pipelines używa interfejsów API REST usługi Power BI do wdrażania zawartości przy użyciu potoku wdrażania usługi Power BI. 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 użytkownicy potoku mogli wyświetlać historię wdrożenia i porównywać zawartość.

Napiwek

W przypadku oddzielenia obszarów roboczych danych od obszarów roboczych raportowania rozważ użycie usługi Azure Pipelines do organizowania publikowania zawartości przy użyciu wielu potoków wdrażania usługi Power BI. Najpierw wdrażany jest model semantyczny, a następnie odświeżany. Na koniec raporty są wdrażane. Takie podejście pomaga uprościć wdrażanie.

Licencjonowanie w warstwie Premium

Potoki wdrażania usługi Power BI i punkt końcowy odczytu/zapisu XMLA to funkcje Premium. Te funkcje są dostępne z pojemnością usługi Power BI Premium i usługą Power BI Premium na użytkownika (PPU).

PpU to ekonomiczny sposób zarządzania publikowaniem zawartości przedsiębiorstwa na potrzeby obszarów roboczych tworzenia i testowania, które zwykle mają kilku użytkowników. Takie podejście ma dodatkową zaletę izolowania obciążeń programistycznych i testowych z obciążeń produkcyjnych.

Uwaga

Nadal można skonfigurować publikowanie zawartości przedsiębiorstwa bez licencji Premium, zgodnie z opisem w drugiej metodzie w sekcji potoku wydania. W drugim podejściu używasz usługi Azure Pipelines do zarządzania wdrażaniem plików programu Power BI Desktop w obszarach roboczych tworzenia, testowania i produkcji. Nie można jednak wdrożyć metadanych modelu przy użyciu punktu końcowego XMLA, ponieważ nie można opublikować semantycznego modelu formatu metadanych za pomocą interfejsów API REST usługi Power BI. Ponadto nie można podwyższyć poziomu zawartości za pośrednictwem środowisk z potokami wdrażania bez licencji Premium.

Konfiguracja bramy

Zazwyczaj brama danych jest wymagana podczas uzyskiwania dostępu do źródeł danych znajdujących się w prywatnej sieci organizacyjnej lub sieci wirtualnej. Dwiema celami bramy są odświeżenie zaimportowanych danych i wyświetlenie raportu, który wykonuje zapytania dotyczące połączenia na żywo lub modelu semantycznego trybu DirectQuery (nie przedstawiono na diagramie scenariusza).

Podczas pracy z wieloma środowiskami często konfiguruje się połączenia programistyczne, testowe i produkcyjne z różnymi systemami źródłowymi. W takim przypadku użyj reguł źródła danych i reguł parametrów, aby zarządzać wartościami, które różnią się między środowiskami. Za pomocą usługi Azure Pipelines można zarządzać bramami przy użyciu operacji bramy interfejsów API REST usługi Power BI.

Uwaga

Scentralizowana brama danych w trybie standardowym jest zdecydowanie zalecana w przypadku bram w trybie osobistym. W trybie standardowym brama danych obsługuje połączenia na żywo i operacje trybu DirectQuery (oprócz zaplanowanych operacji odświeżania danych).

Nadzór systemowy

Dziennik aktywności rejestruje zdarzenia występujące w usługa Power BI. Administratorzy usługi Power BI mogą używać dziennika aktywności do przeprowadzania inspekcji działań wdrażania.

Do utworzenia spisu dzierżawy można użyć interfejsów API skanowania metadanych usługi Power BI. Wyniki interfejsu API są przydatne do sprawdzania, które elementy zostały wdrożone w każdym obszarze roboczym, w celu sprawdzenia pochodzenia i zweryfikowania ustawień zabezpieczeń.

Istnieje również dziennik inspekcji w usłudze Azure DevOps, który znajduje się poza usługa Power BI. Administratorzy usługi Azure DevOps mogą używać dziennika inspekcji do przeglądania działań w repozytoriach zdalnych i potokach.

Powiązana zawartość

Inne przydatne scenariusze ułatwiające podejmowanie decyzji dotyczących implementacji usługi Power BI można znaleźć w artykule Scenariusze użycia usługi Power BI.