Planowanie implementacji usługi Power BI: opracowywanie zawartości i zarządzanie zmianami

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

• 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ć role, takie jak menedżerowie wydań, którzy obsługują cykl życia wydań zawartości, lub inżynierowie, którzy tworzą i zarządzają składnikami potrzebnymi do efektywnego używania i zarządzania cyklem życia.
• Twórcy zawartości i właściciele zawartości: użytkownicy, którzy tworzą zawartość, którą chcą opublikować w portalu sieci szkieletowej, 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 to procesy i praktyki używane do obsługi zawartości od jej tworzenia do ewentualnego wycofania. W pierwszym etapie zarządzania cyklem życia planujesz i projektujesz zawartość, która obejmuje planowanie rozwiązań i podejmowanie kluczowych decyzji mających wpływ na podejście do zarządzania cyklem życia. W drugim etapie tworzysz zawartość i zarządzasz zmianami.

Zarządzanie zmianami zawartości w trakcie cyklu życia jest ważne, aby zapewnić skuteczną współpracę między twórcami zawartości i stabilnym i spójnym dostarczaniem zawartości użytkownikom.

Na poniższej ilustracji przedstawiono cykl życia zawartości usługi Power BI z wyróżnieniem etapu drugiego, w którym tworzysz zawartość i zarządzasz zmianami.

Twórcy zawartości i właściciele powinni zarządzać zmianami zawartości przy użyciu kontroli wersji. Kontrola wersji to praktyka zarządzania zmianami w plikach lub kodzie w centralnym repozytorium. Ta praktyka ułatwia wydajniejszą współpracę i zarządzanie zawartością.

Inne zalety kontroli wersji obejmują następujące możliwości:

• Połącz zmiany od wielu twórców zawartości i rozwiąż konflikty podczas scalania.
• Zidentyfikuj, która zawartość została zmieniona, i co się zmieniło w tej zawartości.
• Połącz zmiany zawartości z określonymi elementami roboczymi.
• Grupuj zmiany w odrębne wydania z uwzględnieniem historii wersji.
• Wycofaj zmiany lub całe wersje zawartości.

Pierwszym krokiem do skonfigurowania kontroli wersji jest podjęcie decyzji o sposobie tworzenia zawartości.

Podejmowanie decyzji o sposobie opracowywania zawartości

W zależności od sposobu tworzenia zawartości będziesz podejmować różne decyzje dotyczące sposobu zarządzania nią. Na przykład w przypadku raportów i modeli semantycznych usługi Power BI plik programu Power BI Desktop (pbix) ma mniej opcji kontroli wersji w porównaniu z formatem projektu programu Power BI Desktop (pbip). Dzieje się tak, ponieważ plik pbix jest formatem binarnym, natomiast format pbip zawiera zawartość i metadane czytelne dla człowieka oparte na tekście. Posiadanie zawartości i metadanych z możliwością odczytu przez człowieka umożliwia łatwiejsze śledzenie zmian modelu i raportów przy użyciu kontroli źródła. Kontrola źródła polega na wyświetlaniu zmian w zawartości i zarządzaniu nimi w kodzie i metadanych.

Power BI Desktop

Program Power BI Desktop umożliwia tworzenie semantycznych modeli lub raportów, które można zapisać jako pliki pbix lub pbip. W przypadku korzystania z programu Power BI Desktop można również używać dodatkowych niestandardowych plików zawartości. W przypadku tworzenia zawartości przy użyciu programu Power BI Desktop należy podjąć pewne kluczowe decyzje:

• Którego formatu pliku użyć: możesz zapisać zawartość jako pliki pbix lub pbip. Aby uzyskać więcej informacji, zobacz Wybieranie formatu zawartości w dalszej części tego artykułu.
• Jak zarządzać zawartością niestandardową: możesz dodawać motywy, wizualizacje niestandardowe lub obrazy do plików programu Power BI Desktop, co może wymagać odrębnych zagadnień dotyczących zarządzania cyklem życia. Na przykład gdy twórcy zawartości tworzą własne wizualizacje niestandardowe, powinni zapisywać definicję wizualizacji i zarządzać nią w osobnym pliku.
• Jak zarządzać funkcjami w wersji zapoznawczej: możesz wyrazić zgodę na korzystanie z funkcji lub ustawień w wersji zapoznawczej w programie Power BI Desktop, co zmienia zawartość i sposób jej używania. Na przykład możesz wykonać dodatkowe kroki w celu zweryfikowania zawartości korzystającej z funkcji w wersji zapoznawczej.

Tworzenie w Sieci Web

Niektóre treści, takie jak przepływy danych, pulpity nawigacyjne i karty wyników, można tworzyć tylko w portalu Fabric. Możesz również utworzyć lub zmodyfikować część zawartości — na przykład semantyczne modele, raporty i raporty podzielone na strony — zarówno w portalu sieci szkieletowej, jak i za pomocą narzędzi lokalnych. Podczas tworzenia zawartości przy użyciu tworzenia w Internecie należy podjąć kluczowe decyzje:

• Jak zarządzać zmianami: możesz wprowadzać zmiany w wielu typach elementów przy użyciu tworzenia w Internecie, ale te zmiany mogą zostać zapisane natychmiast, zastępując poprzednie wersje. Jeśli na przykład współpracujesz z innymi osobami, możesz uniknąć tworzenia w Internecie elementów udostępnionych, pracując zamiast tego na własnej kopii.
• Jak pobrać kopie zapasowe zawartości: możesz tworzyć zawartość, na przykład raporty lub modele semantyczne przy użyciu tworzenia w Internecie, ale tych elementów nie można pobrać do lokalnych plików pbix. Możesz na przykład utworzyć kopię zapasową tej zawartości, pobierając i przechowując jej metadane.

Inne narzędzia

Możesz użyć innych narzędzi do tworzenia niektórych typów zawartości lub zarządzania nimi. Te narzędzia mogą zapewniać dodatkowe korzyści, lepiej odpowiadać przepływowi pracy lub być wymagane do zarządzania określonymi funkcjami lub typami zawartości. Do tworzenia zawartości i zarządzania nią można użyć zarówno innych narzędzi firmy Microsoft, jak i narzędzi innych firm. Inne narzędzia, których można użyć do tworzenia zawartości lub zarządzania nią, są następujące.

• Visual Studio lub Visual Studio Code: zintegrowane środowisko programistyczne dla deweloperów do tworzenia i zarządzania modelami semantycznymi lub notatnikami Fabric. Zarówno w programie Visual Studio, jak i programie Visual Studio Code deweloperzy mogą również wykonywać zarządzanie kontrolą źródła (SCM), zatwierdzając i wypychając zmiany lokalne do repozytorium zdalnego.
• Edytor tabelaryczny: narzędzie innej firmy do tworzenia modeli semantycznych i zarządzania nimi.
• Excel: narzędzie klienckie do tabel przestawnych i tabel połączonych na żywo, które współpracują z modelem semantycznym.
• Power BI Report Builder: aplikacja klasyczna do tworzenia plików raportów stronicowanych (.rdl).

Podczas tworzenia zawartości przy użyciu innych narzędzi należy podjąć kluczowe decyzje:

• Jak zarządzać licencjami: Inne narzędzia mogą wymagać dodatkowych licencji, którymi należy zarządzać.
• Jak opublikować zawartość: Inne narzędzia mogą wymagać dodatkowych kroków publikowania zawartości, takich jak używanie punktów końcowych XMLA lub interfejsów API REST usługi Power BI.

Po podjęciu decyzji o sposobie tworzenia zawartości należy wybrać format, który będzie używany do zapisywania zawartości i zarządzania nią.

Wybieranie formatu zawartości

W zależności od zawartości, która zostanie utworzona i których narzędzi będziesz używać, zawartość może używać różnych formatów plików. Jednak nawet w ramach narzędzia musisz wybierać pomiędzy różnymi formatami. Na przykład w przypadku raportów i modeli semantycznych tworzonych za pomocą programu Power BI Desktop należy wybrać pliki pbix i pbip. Ta decyzja ma wpływ funkcjonalny nie tylko na sposób tworzenia zawartości, ale także sposobu zarządzania tą zawartością w trakcie jej cyklu życia oraz efektywnego wykonywania określonych zadań programistycznych. Na przykład należy użyć plików pbip, jeśli chcesz opracować zawartość w programie Power BI Desktop, ale opublikować ją przy użyciu integracji z usługą Git.

Format pliku zawartości może ulec zmianie podczas jego cyklu życia. Na przykład możesz zacząć tworzyć pliki pbix dla raportów i modeli, początkowo. Jeśli jednak nowi twórcy zawartości chcą współpracować z Tobą lub gdy chcesz zwiększyć produktywność, możesz przełączyć się na inny format, taki jak pliki pbip.

W poniższych sekcjach omówiono typowe formaty, które należy wybrać w usłudze Power BI.

Format pliku programu Power BI Desktop (pbix)

Domyślnym i najbardziej typowym formatem raportów i modeli usługi Power BI jest format pliku pbix. Ten format binarny jest łatwy do zarządzania i używania dla większości osób. Nie można jednak otworzyć ani użyć zawartości pliku do śledzenia zmian ani zwiększenia produktywności deweloperów.

Użyj formatu pliku pbix, gdy:

• Zamierzasz publikować zawartość przy użyciu odświeżania w usłudze OneDrive.
• Twórcy zawartości chcą używać i udostępniać pojedynczy plik, a nie folder wielu plików (na przykład w formacie pbip).
• Twórcy zawartości preferują format .pbix, ponieważ jest on prostszy.

Format pliku projektów usługi Power BI (pbip)

Zamiast pliku .pbix można również zapisywać zawartość przy użyciu formatu projektów Power BI (.pbip). Ten format dzieli plik na strukturę folderów. W strukturze folderów pliku pbip istnieje wiele plików metadanych, które można otworzyć i odczytać, które zawierają definicje i konfiguracje modeli i raportów. Ponieważ możesz otworzyć i odczytać zawartość pliku, możesz wprowadzić zmiany w nich ręcznie lub programowo, co może spowodować znaczne ulepszenia produktywności. Niektóre funkcje w usłudze Fabric, takie jak integracja z usługą Git, wymagają również używania formatu pbip zamiast formatu pbix, jeśli tworzysz zawartość w programie Power BI Desktop.

Na poniższej ilustracji przedstawiono różnice między plikami pbix i plikami pbip:

Podsumowując, użytkownicy lub zautomatyzowane procesy mogą wyświetlać i modyfikować zawartość pliku pbip bez otwierania go w programie Power BI Desktop. Natomiast plik pbix jest plikiem binarnym i nie ma obsługiwanych metod wyświetlania ani modyfikowania jego zawartości. Istnieją różne scenariusze, w których chcesz mieć możliwość wyświetlania lub zmieniania zawartości metadanych, takich jak:

• Chcesz przeprowadzić kontrolę wersji, śledząc zmiany i zarządzając nimi, uzyskując wgląd w to, co się zmieniło.
• Chcesz wprowadzić zmiany zbiorczo lub wyszukać coś w pliku.
• Chcesz ponownie użyć elementów pliku, takich jak wizualizacja, tabela lub miara.
• Chcesz wyświetlić właściwości lub ustawienia, które nie są widoczne w interfejsie użytkownika programu Power BI Desktop.
• Chcesz zautomatyzować niektóre procesy, takie jak skanowanie metadanych w celu naruszenia najlepszych rozwiązań przed opublikowaniem zawartości.

Format pliku .pbip może również używać formatów TMDL lub PBIR dla definicji semantycznych modelu i raportu, które mają swoje zalety oraz kwestie, o których należy pamiętać.

Użyj formatu pliku pbip, gdy:

• Planujesz używać integracji z usługą Git zamiast odświeżania OneDrive, aby publikować lub wdrażać zawartość.
• Planujesz używać kontroli źródła do śledzenia zmian i zarządzania nimi.
• Planujesz używać programu Power BI Desktop w połączeniu z innymi narzędziami do tworzenia modeli lub raportów.
• Wielu twórców zawartości będzie współpracować ze sobą nad modelami lub raportami.
• Chcesz skorzystać z ulepszeń produktywności i zaoszczędzić czas na tworzeniu modeli lub raportów.
• Planujesz zautomatyzować części procesu programowania, testowania lub wdrażania.
• Chcesz utworzyć strukturę plików modelu i raportów na różne sposoby (na przykład wiele raportów w folderze .Report, i wiele modeli w folderze .SemanticModel).

Format pliku tabelarycznego języka definicji modelu (tmdl)

Podczas zapisywania modelu jako pliku pbip można zapisać go jako pojedynczy plik bim, który używa języka TMSL (Tabular Model Scripting Language) lub w strukturze folderów wielu plików tmdl, które używają nowego języka definicji modelu tabelarycznego. Język TMDL używa składni podobnej do kodu YAML dla definicji modelu semantycznego, które ułatwiają odczytywanie zmian modelu i zarządzanie nimi.

Poniżej przedstawiono przykładowy wygląd formatu TMDL:

Niektóre zalety nowego formatu TMDL są następujące:

• Możesz lepiej korzystać z kontroli źródła i integracji z usługą Git, ponieważ metadane modelu są bardziej zwięzłe, ustrukturyzowane i łatwiejsze do odczytania.
• Można łatwiej scalić zmiany bez tworzenia konfliktów.
• Możesz zwiększyć wydajność niektórych zadań raportowania, takich jak ponowne używanie lub kopiowanie obiektów modelu między modelami (na przykład w tabeli dat).

Poniżej przedstawiono przykład kontroli źródła w formacie TMDL:

Użyj formatu TMDL, gdy:

• Planujesz używać kontroli źródła do śledzenia zmian i zarządzania nimi.
• Chcesz zwiększyć produktywność deweloperów, wprowadzając zmiany metadanych.
• Model semantyczny jest opracowywany przy użyciu innych narzędzi, takich jak Visual Studio Code lub Tabular Editor.

Format raportu rozszerzonego usługi Power BI (PBIR).

Podczas zapisywania zawartości jako pliku pbip można użyć domyślnego formatu raportu lub nowego formatu PBIR. Ten nowy format oferuje kilka zalet, które mogą zwiększyć produktywność i współpracę deweloperów, szczególnie w przypadku korzystania z formatu PBIR z plikami pbip.

Poniżej przedstawiono przykładowy wygląd formatu PBIR:

Niektóre zalety korzystania z formatu PBIR są następujące:

• Możesz lepiej użyć kontroli źródła i integracji z usługą Git, ponieważ metadane raportu są bardziej zwięzłe, ustrukturyzowane i łatwiejsze do odczytania.
• Możesz poprawić swoją wydajność w niektórych zadaniach raportowania, takich jak:
  • Ponowne używanie lub kopiowanie elementów wizualnych między stronami przez skopiowanie visual.json.
  • Ponowne używanie lub kopiowanie stron między raportami.
  • Znajdowanie i zastępowanie niestandardowych kolorów, pól i innych konfiguracji wizualizacji jednocześnie.
  • Naprawianie "uszkodzonych" wizualizacji z polami, które zostały przemianowane lub przeniesione między tabelami.
• Możesz dodać adnotacje metadanych do raportów metadanych, aby ułatwić niektóre automatyzacje lub zadania, które obsługują ciągłą integrację/ciągłe wdrażanie (CI/CD).
• Możesz wykorzystać narzędzia, takie jak semantic-link-labs, które mają większą użyteczność z nowym formatem PBIR.

Użyj formatu PBIR, gdy:

• Planujesz używać kontroli źródła do śledzenia zmian i zarządzania nimi.
• Chcesz zwiększyć produktywność twórców raportów, wprowadzając zmiany metadanych.
• Chcesz wprowadzić programowe lub automatyczne zmiany w raporcie.

Format pliku szablonu usługi Power BI (pbit)

Możesz również zapisać raport usługi Power BI lub model semantyczny jako plik pbit. Jednak pliki pbit są przeznaczone do ponownego użycia określonego układu raportu lub struktury modelu. Nie należy używać formatu pbit do zapisywania zawartości usługi Power BI i zarządzania nią podczas opracowywania. Zamiast tego należy używać plików pbit, gdy chcesz utworzyć szablony wielokrotnego użytku, aby udostępniać je innym osobom w organizacji.

Inne formaty

Podczas tworzenia innej zawartości w usłudze Power BI (na przykład pulpitów nawigacyjnych, przepływów danych lub raportów podzielonych na strony), może się zdarzyć, że nie będziesz mieć plików zawartości, jeśli tworzysz element w środowisku Fabric. Alternatywnie możesz mieć tylko definicję elementu zapisaną w kontroli źródła. Aby uzyskać więcej informacji, zobacz Wybieranie miejsca przechowywania plików w poprzednim artykule z tej serii.

Decydowanie o sposobie konfigurowania i używania obszarów roboczych

Podczas tworzenia zawartości należy użyć wielu obszarów roboczych (lub etapów), aby oddzielić zawartość produkcyjną używaną przez organizację od zawartości opracowywanej lub weryfikowanej. Istnieje kilka zalet używania oddzielnych obszarów roboczych dla zawartości:

• Zawartość można opracowywać i testować bez wpływu na zawartość, która jest obecnie używana. Pozwala to uniknąć zmian, które mogą spowodować niezamierzone zakłócenia zawartości w środowisku produkcyjnym.
• Możesz użyć oddzielnych zasobów do tworzenia i testowania zawartości, takich jak używanie oddzielnych bram danych lub pojemności sieci szkieletowej. Pozwala to uniknąć tego, że zasoby używane do programowania i testowania zakłócają obciążenia produkcyjne, powodując powolne odświeżanie danych lub raporty.
• Można utworzyć bardziej ustrukturyzowany proces tworzenia, testowania i wydawania zawartości, używając odrębnych środowisk dla każdego z tych etapów. Pomaga to zwiększyć produktywność.

W Fabric i Power BI zalecamy używanie oddzielnych obszarów roboczych Fabric, zgodnie z opisem w artykułach dotyczących planowania na poziomie dzierżawy i na poziomie obszaru roboczego.

Istnieje wiele sposobów używania obszarów roboczych systemu Fabric do oddzielania środowisk. Zazwyczaj oprócz środowiska lokalnego używasz co najmniej dwóch obszarów roboczych do zarządzania zawartością w trakcie jego cyklu życia.

Odpowiedz na następujące pytania podczas planowania sposobu używania oddzielnych obszarów roboczych w całym cyklu życia tej zawartości:

• Ile obszarów roboczych potrzebujesz?
• Czy rozdzielisz obszary robocze według typu elementu?
• Kto będzie miał dostęp do każdego obszaru roboczego?
• Czy obszary robocze będą należeć do potoku wdrażania sieci szkieletowej lub czy zaaranżujesz wdrożenie przy użyciu innych podejść, takich jak przy użyciu usługi Azure Pipelines?
• Jak będziesz zarządzać publikowaniem między obszarami roboczymi? Czy na przykład należy upewnić się, że raporty w obszarze roboczym testowym dla raportów łączą się z modelami semantycznymi w osobnym obszarze roboczym testowym dla elementów danych?
• Czy należy również używać oddzielnych zasobów pomocniczych dla elementów w obszarach roboczych produkcyjnych, takich jak oddzielny lokalny klaster bramy danych?

"Poniższe sekcje oferują przegląd różnych podejść, które można zastosować do separacji przestrzeni roboczych w celu ułatwienia zarządzania cyklem życia projektu."

Obszary robocze testowania i produkcji

W przypadku dostarczania prostszej zawartości, która nie jest krytyczna dla organizacji, często wystarczy dwa obszary robocze. W tym scenariuszu twórcy zawartości zwykle mają ograniczoną współpracę nad tymi samymi elementami i lokalnie opracowują zawartość.

Na poniższym diagramie przedstawiono ogólny przykład użycia oddzielnych środowisk tylko z obszarem roboczym testowym i produkcyjnym.

Diagram przedstawia następujące procesy i składniki w celu oddzielenia obszarów roboczych w tym podejściu.

Produkt	Opis
	Twórcy zawartości tworzą zawartość w swoim środowisku lokalnym.
	Gdy wszystko będzie gotowe, twórcy zawartości publikują zawartość w testowym obszarze roboczym. Twórcy zawartości mogą opracowywać zawartość, którą można tworzyć tylko za pomocą tworzenia w Internecie i przeprowadzać walidację zawartości w obszarze roboczym testowym.
	Gdy wszystko będzie gotowe, twórcy zawartości wdrażają zawartość w produkcyjnym obszarze roboczym. W produkcyjnym obszarze roboczym twórcy zawartości rozpowszechniają zawartość, publikując aplikację usługi Power BI lub udostępniając zawartość z obszaru roboczego.

Obszary robocze tworzenia, testowania i produkcji

Podczas dostarczania zawartości krytycznej dla działania firmy zazwyczaj używa się co najmniej trzech oddzielnych obszarów roboczych. W tym scenariuszu twórcy zawartości często współpracują w dodatkowym obszarze roboczym programowania zawierającym najnowszą wersję rozwiązania.

Na poniższym diagramie przedstawiono ogólny przykład użycia oddzielnych środowisk z obszarem roboczym programowania, testowania i produkcji.

Diagram przedstawia następujące procesy i składniki w celu oddzielenia obszarów roboczych w tym podejściu.

Produkt	Opis
	Twórcy zawartości tworzą zawartość w swoim środowisku lokalnym.
	Gdy będą gotowi, twórcy zawartości publikują zawartość w środowisku deweloperskim. W obszarze roboczym programowania twórcy zawartości mogą opracowywać zawartość, którą można tworzyć tylko za pomocą tworzenia w Internecie. Twórcy zawartości mogą również weryfikować zawartość w obszarze roboczym programowania.
	Gdy wszystko będzie gotowe, twórcy zawartości wdrażają zawartość w testowym obszarze roboczym. W obszarze roboczym testowym użytkownicy weryfikują zawartość w obszarze roboczym lub aplikacji.
	Gdy wszystko będzie gotowe, twórcy zawartości wdrażają zawartość w produkcyjnym obszarze roboczym. W produkcyjnym obszarze roboczym twórcy zawartości rozpowszechniają zawartość, publikując aplikację usługi Power BI lub udostępniając zawartość z obszaru roboczego.

Prywatny obszar roboczy z integracją z usługą Git

Podczas dostarczania zawartości krytycznej dla działania firmy każdy deweloper może również używać własnego , prywatnego obszaru roboczego do programowania. W tym scenariuszu prywatny obszar roboczy umożliwia twórcom treści testowanie treści w portalu Fabric lub korzystanie z takich funkcji jak zaplanowane odświeżanie, bez ryzyka zakłóceń dla innych osób w zespole deweloperskim. Twórcy zawartości mogą również tutaj tworzyć zawartość w portalu Fabric, na przykład przepływy danych. Prywatne obszary robocze mogą być dobrym wyborem w przypadku zarządzania zmianami zawartości przy użyciu integracji z usługą Git razem z usługą Azure DevOps.

Na poniższym diagramie przedstawiono ogólny przykład użycia oddzielnych środowisk przy użyciu prywatnego obszaru roboczego z integracją z usługą Git.

Diagram przedstawia następujące procesy i składniki w celu oddzielenia obszarów roboczych w tym podejściu.

Produkt	Opis
	Każdy twórca zawartości opracowuje zawartość we własnym środowisku lokalnym.
	Gdy wszystko będzie gotowe, twórcy zawartości zatwierdzają i wypychają zmiany do repozytorium zdalnego, takiego jak repozytorium Git usługi Azure Repos.
	W zdalnym repozytorium Git twórcy zawartości śledzą zmiany zawartości i zarządzają nimi przy użyciu kontroli źródła, a także rozgałęziają i scalają zawartość w celu ułatwienia współpracy.
	Twórcy zawartości synchronizują gałąź repozytorium zdalnego z prywatnym obszarem roboczym. Po zsynchronizowaniu najnowsze zmiany, które twórca zatwierdza i przesyła do gałęzi, są widoczne w tym prywatnym obszarze roboczym. Różni twórcy zawartości pracują na własnych, oddzielnych gałęziach podczas wprowadzania zmian.
	W prywatnych obszarach roboczych twórcy zawartości mogą opracowywać zawartość przy użyciu tworzenia w Internecie i weryfikować własne zmiany. Zmiany zawartości wprowadzone przez edytowanie online mogą być synchronizowane z gałęzią w repozytorium Git, gdy twórca zawartości zatwierdza te zmiany z obszaru roboczego i pcha je. Różne twórcy zawartości pracują we własnych, oddzielnych prywatnych obszarach roboczych.
	Gdy są gotowi, twórcy zawartości wykonują pull request, aby scalić swoje zmiany w głównej gałęzi.
	Po scaleniu zmian gałąź główna synchronizuje się z obszarem roboczym programowania.
	W obszarze roboczym twórcy zawartości mogą opracowywać treści, które nie są obsługiwane przez integrację Fabric z Git, takie jak pulpity nawigacyjne. Twórcy zawartości weryfikują również zintegrowane rozwiązanie, które zawiera wszystkie najnowsze zmiany.
	Gdy wszystko będzie gotowe, twórcy zawartości wdrażają zawartość w testowym obszarze roboczym. W obszarze roboczym testowym użytkownicy wykonują testy akceptacyjne zawartości.
	Gdy wszystko będzie gotowe, twórcy zawartości wdrażają zawartość w produkcyjnym obszarze roboczym. W produkcyjnym obszarze roboczym twórcy zawartości rozpowszechniają zawartość, publikując aplikację usługi Power BI lub udostępniając zawartość z obszaru roboczego.

Zasoby pomocnicze dla przestrzeni roboczych

W przypadku korzystania z oddzielnych środowisk należy również rozważyć, w jaki sposób będzie to miało wpływ na różne zasoby pomocnicze używane w tych środowiskach. W przypadku tych zasobów pomocniczych należy rozważyć, czy należy je również rozdzielić na tę samą liczbę etapów, czy też sposób koordynowania ich użycia w tych środowiskach.

• Bramy: rozważ użycie oddzielnych lokalnych klastrów bram danych i bram sieci wirtualnej dla obciążeń produkcyjnych. Jest to korzystne, aby zapobiec zakłóceniom, i zapewnić dostępność, gdy trzeba zaktualizować te bramy.
• Aplikacje: rozważ posiadanie oddzielnych aplikacji dla obszarów roboczych testowych i produkcyjnych. Nie można wdrażać ani kopiować aplikacji między etapami. Aplikacje w obszarze roboczym testowym mają ułatwić testowanie zawartości i środowiska aplikacji przed wdrożeniem zmian w produkcyjnym obszarze roboczym. Aplikacje w obszarze roboczym produkcyjnym mają na celu dostarczanie zawartości użytkownikom końcowym w ustrukturyzowanej strukturze i środowisku.
• Azure DevOps: Jeśli zamierzasz używać usługi Azure DevOps do współpracy i organizowania kontroli źródła i wdrażania, rozważ użycie gałęzi i usługi Azure Pipelines do wdrażania zawartości między tymi środowiskami. Aby uzyskać więcej informacji na temat wdrażania zawartości przy użyciu usługi Azure Pipelines, zobacz Etap 4: Wdrażanie zawartości.

Po podjęciu decyzji o sposobie konfigurowania i używania obszarów roboczych następnym krokiem jest podjęcie decyzji o sposobie kontrolowania wersji w celu śledzenia zmian zawartości i zarządzania nimi.

Decydowanie o sposobie używania kontroli wersji

W usłudze Power BI możesz kontrolować wersję przy użyciu programu SharePoint/OneDrive lub za pomocą zdalnego repozytorium Git, takiego jak usługa Azure Repos, która jest składnikiem usługi Azure DevOps. Zamiast usługi Azure DevOps możesz również użyć usługi GitHub. W obu podejściach dodajesz lokalne pliki zawartości do zdalnego miejsca przechowywania, aby ułatwić zarządzanie zmianami i ich śledzenie. Zalecamy używanie programu SharePoint lub OneDrive tylko w przypadku mniejszych i prostszych projektów, ponieważ brakuje funkcji i niezawodności obsługi większych lub bardziej skomplikowanych scenariuszy.

Poniżej przedstawiono kilka ogólnych zagadnień, które ułatwiają konfigurowanie kontroli wersji i korzystanie z nich.

• Alerty: Należy skonfigurować alerty na przypadek, gdy inne osoby dodają, usuwają lub modyfikują pliki krytyczne.
• Zakres: Jasno zdefiniuj zakres lokalizacji magazynu zdalnego. W idealnym przypadku zakres lokalizacji magazynu zdalnego 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 lokalizacji magazynu zdalnego przy użyciu podobnego modelu uprawnień jak ten skonfigurowany dla uprawnień potoku wdrażania i ról obszaru roboczego. Twórcy zawartości potrzebują dostępu do zdalnej lokalizacji magazynu.
• Dokumentacja: Dodawanie plików tekstowych do zdalnej lokalizacji magazynu w celu opisania lokalizacji magazynu zdalnego i jego przeznaczenia, własności, dostępu i zdefiniowanych procesów.

W poniższych sekcjach opisano każde z podejść i kluczowe zagadnienia, które należy rozważyć.

Kontrola wersji przy użyciu programu SharePoint lub usługi OneDrive for Work and School

Program SharePoint ma wbudowaną kontrolę wersji dla plików. Twórcy zawartości mogą tworzyć semantyczne modele lub raporty lokalnie, a ich zmiany są synchronizowane z biblioteką dokumentów programu SharePoint lub OneDrive for Work i School.

Na poniższym diagramie przedstawiono ogólny przegląd sposobu przeprowadzania kontroli wersji przy użyciu programu SharePoint lub usługi OneDrive.

Na diagramie opisano następujące procesy i składniki.

Produkt	Opis
	Twórcy zawartości tworzą semantyczne modele i raporty w swoim środowisku lokalnym i zapisują te modele i raporty jako pliki pbix.
	Gdy wszystko będzie gotowe, twórcy zawartości zapisują swoje zmiany, które synchronizują ze zdalnym programem SharePoint lub biblioteką OneDrive for Work and School.
	W bibliotece zdalnej twórcy zawartości śledzą zmiany na poziomie plików, które ułatwiają kontrolę wersji.
	Twórcy zawartości mogą połączyć opublikowany model semantyczny lub raport z plikiem pbix w celu ułatwienia odświeżania w usłudze OneDrive. OneDrive automatycznie aktualizuje zmiany w zawartości co godzinę.
	W obszarze roboczym Fabric twórcy zawartości widzą zmiany w zawartości Power BI po zakończeniu odświeżania OneDrive.

Podsumowując, twórcy zawartości mogą połączyć opublikowany model semantyczny lub raport z plikiem pbix przechowywanym w bibliotece programu SharePoint lub OneDrive for Work i School. Dzięki temu twórcy zawartości nie muszą już publikować modelu semantycznego, aby zobaczyć zmiany. Zamiast tego zmiany są widoczne po automatycznym odświeżeniu usługi OneDrive, które odbywa się co godzinę. Chociaż wygodne, takie podejście wiąże się z pewnymi kwestiami i nie można go łatwo odwrócić.

Chociaż można łatwo skonfigurować i zarządzać, kontrola wersji w programie SharePoint lub usłudze OneDrive ma więcej ograniczeń. Na przykład nie można wyświetlić zmian w zawartości i nie można również porównywać wersji. Ponadto nie można skonfigurować bardziej zaawansowanych procesów do zarządzania tymi zmianami (na przykład rozgałęziania lub żądań ściągnięcia opisanych w dalszej części tego artykułu).

Rozważ użycie programu SharePoint lub usługi OneDrive do śledzenia zmian i zarządzania nimi w następujących scenariuszach:

• Zawartość składa się tylko z semantycznych modeli lub raportów zapisanych jako pliki pbix.
• Użytkownicy samoobsługi tworzą zawartość i zarządzają nią.
• Twórcy zawartości współpracują przy użyciu usługi Microsoft Teams.
• Twórcy zawartości nie mają doświadczenia z zarządzaniem usługą Git i kontrolą źródła.
• Twórcy zawartości zarządzają pojedynczym elementem z ograniczoną złożonością i współpracą.
• Pliki pbix mają zastosowaną etykietę poufności, która szyfruje ich zawartość.

Unikaj korzystania z programu SharePoint lub usługi OneDrive, aby śledzić zmiany i zarządzać nimi w następujących scenariuszach:

• Zawartość składa się z typów elementów innych niż modele semantyczne i raporty.
• Zawartość jest złożona lub duża w zakresie.
• Twórcy zawartości muszą pracować wspólnie nad tym samym elementem w tym samym czasie.

W poniższych sekcjach opisano dodatkowe zagadnienia dotyczące efektywnego korzystania z kontroli wersji przy użyciu programu SharePoint lub usługi OneDrive w usłudze Power BI.

Integracja aplikacji Microsoft Teams

Możesz użyć bibliotek dokumentów z usługi Microsoft Teams, jeśli twórcy zawartości używają ich do współpracy. Biblioteki dokumentów to witryny programu SharePoint i korzystanie z bibliotek dokumentów (zamiast oddzielnej witryny programu SharePoint lub folderu usługi OneDrive) zapewnia centralizację zawartości, plików i współpracy.

Pliki zaewidencjonowania i wyewidencjonowania

Należy wyewidencjonować pliki, nad którymi pracujesz, aby uniknąć możliwych konfliktów zmian. Po zakończeniu wprowadzania zmian zaewidencjonuj pliki z komentarzami, które opisują zmianę. Ewidencjonowanie i wyewidencjonowywanie plików pomaga poprawić współpracę między twórcami zawartości podczas korzystania z programu SharePoint lub usługi OneDrive dla Firm i Szkół w celu kontroli wersji. Jeśli zaewidencjonujesz i wyewidencjonujesz pliki z wieloma twórcami zawartości, możesz zmodyfikować bibliotekę witryn programu SharePoint, aby wyświetlić ostatnią aktualizację i komentarze ostatniego zaewidencjonowania.

Historia wersji

Upewnij się, że utworzono kopię zapasową zawartości w oddzielnej lokalizacji w przypadku nieoczekiwanych zakłóceń w bibliotece dokumentów witryny programu SharePoint. Należy również ustawić limity liczby wersji przechowywanych w witrynie programu SharePoint i usunąć stare wersje. Dzięki temu historia wersji pozostaje znacząca i nie zajmuje zbyt dużo miejsca.

Aby uzyskać bardziej zaawansowaną kontrolę wersji, można przechowywać pliki w repozytorium zdalnym, na przykład Azure Repos, i zarządzać zmianami przy użyciu kontroli źródła.

Kontrola źródła przy użyciu zdalnego repozytorium Git

Zdalne repozytorium Git ułatwia kontrolę źródła plików, co umożliwia twórcom zawartości więcej opcji śledzenia zmian i zarządzania nimi. Krótko mówiąc, twórcy zawartości mogą opracowywać zawartość lokalnie lub w usłudze Power BI, a następnie zatwierdzać i wypychać te zmiany do zdalnego repozytorium Git, takiego jak Azure Repos lub GitHub.

Na poniższym diagramie przedstawiono ogólny przegląd sposobu przeprowadzania kontroli źródła przez lokalne opracowywanie zawartości, a następnie zatwierdzanie zmian w repozytorium zdalnym, które może być synchronizowane z obszarem roboczym usługi Fabric przy użyciu integracji z usługą Git.

Na diagramie opisano następujące procesy i składniki.

Produkt	Opis
	Twórcy zawartości tworzą semantyczne modele i raporty w swoim środowisku lokalnym i zapisują te modele i raporty jako pliki pbip. Twórcy zawartości mogą również tworzyć semantyczne modele i zapisywać metadane modelu.
	Gdy wszystko będzie gotowe, twórcy zawartości zapisują swoje zmiany, które zatwierdzają i wypychają do zdalnego repozytorium Git w regularnych odstępach czasu.
	W zdalnym repozytorium Git twórcy zawartości śledzą zmiany na poziomie obiektu, co ułatwia kontrolę wersji. Twórcy treści mogą także tworzyć gałęzie do pracy nad treścią i scalać swoje zmiany w jedną gałąź przy użyciu pull requestów.
	Twórcy zawartości mogą synchronizować zawartość z repozytorium zdalnego przy użyciu integracji z usługą Git. Mogą również wdrażać zawartość przy użyciu innych metod, takich jak usługa Azure Pipelines wraz z interfejsami API REST.
	W obszarze roboczym Fabric autorzy zobaczą zmiany zawartości Power BI po zsynchronizowaniu lub wdrożeniu. Twórcy zawartości mogą tworzyć zawartość, na przykład przepływy danych lub notesy w obszarze roboczym. Jeśli korzystają z integracji z usługą Git, twórcy zawartości łączą ten obszar roboczy z określoną gałęzią repozytorium zdalnego.
	Twórcy zawartości mogą zatwierdzać i wypychać zmiany z obszaru roboczego do repozytorium zdalnego przy użyciu integracji z usługą Git. Te zmiany mogą importować definicje elementów dla obsługiwanej zawartości utworzonej w obszarze roboczym, takich jak przepływy danych i notesy.

Podsumowując, twórcy zawartości przechowują pliki pbip, pliki metadanych i dokumentację w centralnym repozytorium zdalnym usługi 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 oferuje bardziej zaawansowane opcje śledzenia zmian i zarządzania nimi w porównaniu z programem SharePoint i usługą OneDrive. Utrzymanie dobrze wyselekcjonowanych, udokumentowanych repozytoriów jest niezbędne, ponieważ jest podstawą całej zawartości i współpracy.

Rozważ użycie kontroli źródła do śledzenia zmian i zarządzania nimi w następujących scenariuszach:

• Scentralizowane lub zdecentralizowane zespoły tworzą zawartość i zarządzają nią.
• Twórcy zawartości współpracują przy użyciu usługi Azure DevOps.
• Twórcy zawartości znają usługę Git, zarządzanie kontrolą źródła lub zasady metodyki DataOps.
• Twórcy zawartości zarządzają złożoną lub ważną zawartością lub oczekują, że zawartość będzie skalowana i zwiększa złożoność i znaczenie.

Poniżej przedstawiono kilka wymagań wstępnych i zagadnień, które ułatwiają efektywne korzystanie z kontroli źródła w usłudze Azure DevOps.

• Git: aby zatwierdzić i wypchnąć zmiany do repozytorium zdalnego, twórcy zawartości muszą pobrać i zainstalować usługę Git. 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?.
• Narzędzia: aby korzystać z usługi Git, twórcy zawartości muszą używać interfejsu wiersza polecenia (CLI) lub graficznego klienta interfejsu użytkownika (GUI) dla programu SCM, takiego jak Visual Studio lub Visual Studio Code.
• Licencje i uprawnienia: Aby utworzyć repozytorium Git usługi Azure Repos i korzystać z niego, twórcy zawartości muszą mieć następujące elementy:
  • Poziom dostępu ustawiony na Podstawowy (w przeciwieństwie do Interesariusza).
  • Należy do organizacji i projektu.
  • Odpowiednie uprawnienia repozytorium.
• Integracja z Git w Microsoft Fabric: Aby zsynchronizować zawartość w zdalnym repozytorium z obszarem roboczym Microsoft Fabric, twórcy używają integracji z Git w Microsoft Fabric. Ważne jest, aby śledzić i zarządzać zmianami w zawartości utworzonej w portalu Fabric, takimi jak przepływy danych.

Kluczową zaletą korzystania z kontroli źródła w usłudze Azure Repos lub GitHub jest ulepszona współpraca między twórcami zawartości a większą częścią dostosowywania i nadzoru nad zmianami zawartości i wdrażaniem.

Na poniższym diagramie przedstawiono ogólny przegląd sposobu, w jaki usługa Azure DevOps umożliwia współpracę z kontrolą źródła. Możesz również użyć usługi GitHub Enterprise zamiast usługi AzureDevOps, która będzie obejmować różne usługi, które wykonują podobną funkcję.

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ą.

W poniższych sekcjach opisano dodatkowe zagadnienia dotyczące efektywnego korzystania z kontroli źródła przy użyciu usług Azure DevOps i Power BI.

Korzystanie z gałęzi

Twórcy zawartości osiągają współpracę przy użyciu strategii rozgałęziania. Strategia rozgałęziania umożliwia poszczególnym twórcom zawartości pracę 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 opisowym komunikatem zatwierdzenia. Komunikat zatwierdzenia opisuje zmiany wprowadzone w tym zatwierdzeniu.

W przypadku używania strategii rozgałęziania do zarządzania zawartością Fabric należy wziąć pod uwagę następujące czynniki.

• Którą gałąź twórcy treści powinni sklonować do swojej pracy. Jeśli na przykład te gałęzie są klonem głównej gałęzi (nazywanej rozwojem opartym na gałęzi głównej) lub jeśli są to inne gałęzie, takie jak gałęzie wydawnicze dla określonych, planowanych wersji zawartości.
• Czy ustalisz zakres określonych prac związanych z odrębnymi wersjami zawartości, używając gałęzi wydań.
• Które gałęzie łączą się z którym obszarem roboczym podczas korzystania z integracji z usługą Fabric Git.

Zmiany grupowe w zatwierdzeniach

Podczas tworzenia zawartości twórcy powinni regularnie wprowadzać zmiany w partiach (lub grupach). Te zmiany powinny dotyczyć określonego elementu roboczego rozwiązania (takiego jak funkcja lub problem). Gdy wszystko będzie gotowe, twórcy zawartości zatwierdzą te przygotowane zmiany.

Dzielenie zmian w partie w ten sposób ma kilka korzyści.

• Ułatwia tworzenie struktury i daje twórcom zawartości szansę na przejrzenie i udokumentowanie zmian, które zostały pogrupowane.
• Poprawia to dopasowanie między planowaniem i opracowywaniem, co ułatwia łączenie funkcji i problemów oraz uzyskanie przejrzystości w sposobie kontynuowania pracy.
• Właściciele techniczni mogą łatwiej przeglądać żądania pull requestów od twórców zawartości, jeśli zmiany są odpowiednio zgrupowane i mają jasne wiadomości zatwierdzenia.

Podczas etapu i zatwierdzania zmian w zawartości usługi Power BI należy wziąć pod uwagę następujące czynniki.

• Niezależnie od tego, czy dodasz do indeksu i zatwierdzisz zmiany z repozytorium lokalnego, czy z obszaru roboczego Fabric.
• Umieść pliki pbip w folderach najwyższego poziomu podczas przechowywania wielu modeli lub raportów w jednym repozytorium. Ułatwi to identyfikowanie i grupowanie wprowadzanych zmian.
• Ignoruj nieszkodliwe lub nieprzydatne zmiany metadanych przy użyciu pliku gitignore lub pliku gitattributes. Zapewni to, że wszystkie zmiany, które zatwierdzisz, będą istotne.

Tworzenie żądań ściągnięcia w celu scalenia zmian

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.

Jeśli używasz żądań ściągnięcia do scalania zmian w zawartości usługi Power BI, rozważ następujące czynniki.

• Jakie standardy i praktyki będą używane do przeprowadzania przeglądu, jeśli istnieją. Można na przykład użyć reguł z analizatora najlepszych rozwiązań dla modeli semantycznych.
• Jak zapoznasz się ze zmianami w metadanych raportu, które nie są łatwe do odczytania i zrozumienia bez korzystania z narzędzi innych firm.
• Sposób rozwiązywania konfliktów scalania i rozwiązywania ich.

Lista kontrolna — podczas planowania, gdzie będą przechowywane pliki, kluczowe decyzje i akcje obejmują:

Treści powiązane

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