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

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

Uwaga

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

Napiwek

Ten artykuł koncentruje się na kluczowych decyzjach i zagadnieniach, które ułatwiają opracowywanie zawartości i zarządzanie zmianami w całym cyklu życia. Aby uzyskać więcej wskazówek dotyczących opracowywania zawartości i zarządzania zmianami, zobacz:

• Co to jest zarządzanie cyklem życia w usłudze Microsoft Fabric?: ten artykuł zawiera wprowadzenie techniczne i samouczek dotyczący potoków integracji i wdrażania usługi Git usługi Fabric.
• Najlepsze rozwiązania dotyczące zarządzania cyklem życia: ten artykuł zawiera praktyczne porady i wskazówki dotyczące korzystania z funkcji zarządzania cyklem życia usługi Fabric i Power BI w celu tworzenia zawartości i zarządzania zmianami.
• Integracja programu Power BI Desktop z usługą OneDrive i programem SharePoint: ten artykuł zawiera omówienie opcji używania i przechowywania plików zapisanych w usłudze OneDrive for Work i School lub SharePoint podczas wykonywania kontroli wersji przy użyciu plików pbix.
• Wprowadzenie do usługi Git w usłudze Azure Repos: ta seria artykułów zawiera praktyczne porady, samouczki i wskazówki dotyczące wykonywania kontroli źródła przy użyciu repozytorium Git w usłudze Azure Repos.

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:

• Scal zmiany z wielu twórców zawartości i obsłuż konflikty 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ębnych wersjach z historią wersji.
• Wycofaj zmiany lub całe wersje zawartości.

Napiwek

Zalecamy używanie kontroli wersji dla całej tworzonej zawartości, jeśli jest to możliwe. Korzystanie z kontroli wersji ma znaczne korzyści zarówno dla twórców zawartości, jak i konsumentów oraz zmniejsza ryzyko zakłóceń spowodowanych utratą plików lub brakiem możliwości wycofania zmian.

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.

Napiwek

Podczas tworzenia modeli semantycznych i raportów przy użyciu programu Power BI Desktop zalecamy używanie plików pbip zamiast plików pbix. Podczas tworzenia modeli semantycznych przy użyciu narzędzi XMLA zalecamy użycie formatu TMDL (Tabular Model Definition Language) zamiast plików bim.

Formaty pbip i TMDL obsługują łatwiejsze śledzenie i scalanie zmian na poziomie obiektu. Oznacza to, że można wyświetlać zmiany poszczególnych obiektów i zarządzać nimi, takimi jak miary lub tabele języka DAX.

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. Istnieją dodatkowe pliki zawartości niestandardowej, które mogą być również używane podczas korzystania z programu Power BI Desktop. 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. Na przykład integracja z usługą Git wymaga użycia plików pbip, twórcy samoobsługi mogą łatwiej zarządzać plikami pbix i obsługiwać je w usłudze Teams, SharePoint lub OneDrive.
• 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 sieci szkieletowej. 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.

Napiwek

Podczas tworzenia przepływów danych i kart wyników zalecamy pobranie definicji elementów w celu zarządzania zmianami i przechowywania kopii zapasowej. Przepływ danych i pobieranie kart wyników można zautomatyzować przy użyciu interfejsów API REST sieci szkieletowej. W szczególności możesz użyć odpowiednio punktów końcowych Pobierz przepływ danych i Pobierz karty wyników.

Uwaga

Niektóre treści — takie jak pulpity nawigacyjne — nie mają możliwości pobrania definicji. W przypadku tej zawartości nie można łatwo śledzić zmian ani pobierać kopii zapasowej.

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 służące do tworzenia modeli semantycznych lub notesów sieci szkieletowej i zarządzania nimi. 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 połączonych na żywo tabel, które współpracują z modelem semantycznym.
• Power BI Report Builder: aplikacja klasyczna do tworzenia plików raportu podzielonego na strony (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ć miejsce publikowania i testowania zawartości podczas jej opracowywania.

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 obszarze Sieć szkieletowa i usługa Power BI zalecamy używanie oddzielnych obszarów roboczych sieci Szkieletowej zgodnie z opisem w artykułach dotyczących planowania na poziomie dzierżawy i na poziomie obszaru roboczego.

Ważne

Korzystanie z oddzielnych środowisk jest niezbędnym krokiem w celu zapewnienia sukcesu podejścia do zarządzania cyklem życia zawartości.

Istnieje wiele sposobów używania obszarów roboczych sieci Szkieletowej 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?
• KtoTo będzie mieć 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?

W poniższych sekcjach przedstawiono ogólne omówienie różnych podejść, które można wykonać w celu ułatwienia zarządzania cyklem życia.

Uwaga

W poniższych sekcjach opisano sposób konfigurowania i używania oddzielnych obszarów roboczych. Zawartość można wdrożyć w tych obszarach roboczych przy użyciu jednego z następujących czterech podejść:

• Publikowanie z programu Power BI Desktop.
• Wdrażanie zawartości z innego obszaru roboczego przy użyciu potoków wdrażania sieci szkieletowej.
• Synchronizowanie zawartości ze zdalnego repozytorium Git przy użyciu integracji z usługą Git.
• Programowe wdrażanie zawartości przy użyciu interfejsów API REST sieci szkieletowej, interfejsów API REST usługi Power BI lub punktów końcowych XMLA.

Aby uzyskać więcej informacji na temat tych metod wdrażania zawartości, zobacz Etap 4: Wdrażanie zawartości w dalszej części tej serii.

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.

Uwaga

Istnieje wiele różnych sposobów konfigurowania i używania oddzielnych obszarów roboczych oraz wdrażania zawartości między tymi obszarami roboczymi. Zalecamy jednak, aby nie wykonywać programowania lokalnego, a następnie publikować zawartość bezpośrednio w obszarze roboczym produkcyjnym. Może to prowadzić do zapobiegania zakłóceniom i błędom.

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 wszystko będzie gotowe, twórcy zawartości publikują zawartość w obszarze roboczym programowania. 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.

Uwaga

Możesz użyć maksymalnie dziesięciu różnych środowisk z potokami wdrażania. Na przykład możesz chcieć mieć środowisko przedprodukcyjne między testowaniem i produkcją, które jest przeznaczone specjalnie dla specjalnych typów weryfikacji, takich jak testowanie wydajnościowe.

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 zawartości testowanie zawartości w portalu sieci szkieletowej lub korzystanie z takich funkcji jak zaplanowane odświeżanie bez ryzyka zakłóceń dla innych osób w zespole deweloperów. Twórcy zawartości mogą również tworzyć zawartość w portalu sieci szkieletowej tutaj, 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.

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.

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.

Uwaga

Diagram przedstawia oddzielnych deweloperów pracujących nad oddzielnymi gałęziami rozwiązania (jedną gałąź i gałąź druga) przed scaleniem zmian w gałęzi głównej. Jest to uproszczony obraz strategii rozgałęziania Git, aby zilustrować, w jaki sposób deweloperzy mogą zintegrować swoje zmiany ze zdalnym repozytorium Git i korzystać z integracji z usługą Git w usłudze Fabric.

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 zatwierdzające i wypychane przez twórcę 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 wprowadzonej przez tworzenie w Internecie mogą być synchronizowane z gałęzią w repozytorium Git, gdy twórca zawartości zatwierdza te zmiany z obszaru roboczego i wypycha je. Różne twórcy zawartości pracują we własnych, oddzielnych prywatnych obszarach roboczych.
	Gdy wszystko będzie gotowe, twórcy zawartości wykonują żądanie ściągnięcia, aby scalić swoje zmiany w głównej gałęzi rozwiązania.
	Po scaleniu zmian gałąź główna synchronizuje się z obszarem roboczym programowania.
	W obszarze roboczym programowania twórcy zawartości mogą opracowywać zawartość, która nie jest obsługiwana przez integrację usługi Git z usługą Fabric, taką 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 obszarów 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, ale także zapewnić czas działania, 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. W obu podejściach dodasz lokalne pliki zawartości do zdalnej lokalizacji magazynu, aby ułatwić śledzenie zmian i zarządzanie nimi. 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: alerty należy skonfigurować, gdy inne osoby dodają, usuń lub zmodyfikujemy 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ń, który został 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 podejście i kluczowe zagadnienia, które należy uż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.

Napiwek

Używaj programu SharePoint lub OneDrive tylko do kontroli wersji w prostszych, mniejszych scenariuszach, takich jak publikowanie zawartości samoobsługowej. W przypadku większych lub bardziej skomplikowanych scenariuszy należy rozważyć przeprowadzenie kontroli źródła przy użyciu zdalnego repozytorium Git.

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. Odświeżanie w usłudze OneDrive automatycznie publikuje zmiany zawartości co godzinę.
	W obszarze roboczym Sieć szkieletowa twórcy zawartości zobaczą zmiany zawartości usługi Power BI po zakończeniu odświeżania w usłudze OneDrive.

Ważne

Kontrolę wersji można wykonywać tylko przy użyciu plików programu SharePoint lub OneDrive dla programu Power BI Desktop zawierających semantyczne modele lub raporty. Nie można łatwo przeprowadzić kontroli wersji przy użyciu programu SharePoint lub usługi OneDrive dla innych typów elementów usługi Power BI, takich jak przepływy danych, lub dla typów elementów sieci szkieletowej, takich jak notesy. W przypadku tych innych typów elementów należy przeprowadzić kontrolę wersji przy użyciu zdalnego repozytorium Git, takiego jak Azure Repos.

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 zagadnieniami 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ść.

Uwaga

Usługa OneDrive i program SharePoint obsługują zawartość, która ma zastosowane etykiety poufności, z wyjątkiem niektórych ograniczonych scenariuszy. Z kolei integracja usługi Git z usługą Fabric nie obsługuje etykiet poufności.

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 zaewidencjonuj i wyewidencjonuj

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ę. Pliki ewidencjonowania i wyewidencjonowania ułatwiają współpracę między twórcami zawartości podczas korzystania z programu SharePoint lub usługi OneDrive for Work i School na potrzeby 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ługa Power BI, a następnie zatwierdzać i wypychać te zmiany do zdalnego repozytorium Git, takiego jak Azure Repos

Uwaga

Możesz również przeprowadzić kontrolę źródła zawartości bez korzystania z integracji z usługą Git. W tym scenariuszu nadal śledzisz zmiany zawartości w zdalnym repozytorium Git i zarządzasz nimi, ale wdrażasz zawartość przy użyciu interfejsów API REST lub punktów końcowych odczytu/zapisu XMLA. Aby uzyskać więcej informacji na temat tych metod wdrażania zawartości, zobacz Etap 4: Wdrażanie zawartości.

Na poniższym diagramie przedstawiono ogólne omówienie sposobu wykonywania kontroli źródła przez program

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 zawartości mogą również tworzyć gałęzie do pracy nad zawartością i scalać zmiany w jedną gałąź przy użyciu żądań ściągnięcia.
	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 Sieć szkieletowa twórcy zawartości zobaczą zmiany zawartości usługi Power BI po zakończeniu synchronizacji lub wdrożenia. 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 Wartość Podstawowa (w przeciwieństwie do uczestników projektu).
  • Należy do organizacji i projektu.
  • Odpowiednie uprawnienia repozytorium.
• Integracja z usługą Git sieci szkieletowej: aby zsynchronizować zawartość w repozytorium zdalnym z obszarem roboczym usługi Microsoft Fabric, twórcy zawartości używają integracji z usługą Fabric Git. Jest to ważne, aby śledzić zmiany w zawartości utworzonej w portalu sieci szkieletowej i zarządzać nimi, takimi jak przepływy danych.

Napiwek

Aby ułatwić kontrolę źródła przy użyciu programowania lokalnego, zalecamy użycie aplikacji klienckiej, takiej jak Visual Studio Code. Program Power BI Desktop służy do tworzenia zawartości, a następnie można użyć programu Visual Studio Code do zarządzania kontrolą źródła tej zawartości, przemieszczania, zatwierdzania i wypychania zmian do repozytorium zdalnego.

Ostrzeżenie

Integracja z usługą Git w sieci szkieletowej ma pewne ograniczenia dotyczące obsługiwanych elementów i scenariuszy. Upewnij się, że najpierw sprawdzisz, czy integracja z usługą Fabric Git najlepiej odpowiada konkretnemu scenariuszowi, czy też należy zastosować inne podejście do implementowania kontroli źródła.

Ponadto etykiety poufności nie są obsługiwane w przypadku integracji z usługą Fabric Git, a eksportowanie elementów z etykietami poufności może być wyłączone. Jeśli zawartość ma etykiety poufności, należy zaplanować sposób kontrolowania wersji przy jednoczesnym zachowaniu zgodności z zasadami ochrony przed utratą danych.

Kluczową zaletą korzystania z kontroli źródła w usłudze Azure Repos 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.

Uwaga

Na poprzednim diagramie przedstawiono jeden przykład współpracy przy użyciu usługi Azure DevOps. Wybierz podejście, które najlepiej odpowiada potrzebom i sposób pracy zespołu.

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.

Ważne

Efektywne korzystanie z rozgałęziania, zatwierdzeń, żądań ściągnięcia i scalania jest niezbędne do większości korzyści z kontroli źródła podczas zarządzania cyklem życia zawartości usługi 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ą sieci szkieletowej należy wziąć pod uwagę następujące czynniki.

• Którzy twórcy zawartości gałęzi powinni klonować na własną pracę. Jeśli na przykład te gałęzie są klonem gałęzi głównej (nazywanej programowaniem opartym na magistrali) lub jeśli są to inne gałęzie, takie jak gałęzie wydania dla określonych, planowanych wersji zawartości.
• Określa, czy zakres specyficzny będzie dotyczyć odrębnych wersji zawartości przy użyciu gałęzi wydań.
• Które gałęzie łączą się z którym obszarem roboczym podczas korzystania z integracji z usługą Fabric Git.

Napiwek

Zobacz Wdrażanie strategii rozgałęziania Usługi Git, aby uzyskać szczegółowe wskazówki i zalecenia dotyczące sposobu, w jaki najlepiej wykorzystać strategię rozgałęziania w celu efektywnego ułatwienia współpracy.

Zmiany wsadowe 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 ściągnięcia od twórców zawartości, jeśli zmiany są odpowiednio wsadowe i mają jasne komunikaty 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 przygotujesz i zatwierdź zmiany z repozytorium lokalnego, czy z obszaru roboczego Sieć szkieletowa.
• Umieść pliki pbip w folderach najwyższego poziomu podczas przechowywania wielu modeli lub raportów w jednym repozytorium. Ułatwi to identyfikowanie i grupowanie w wprowadzanych zmianach.
• 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.

Napiwek

Zobacz Zapisywanie pracy z zatwierdzeniami , aby uzyskać szczegółowe wskazówki i zalecenia dotyczące sposobu przygotowania i zatwierdzenia pracy w repozytorium Git.

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.

Napiwek

Zobacz About pull requests and Merge strategies and squash merge (Informacje o żądaniach ściągnięcia i strategiach scalania) i scalania scalania , aby uzyskać szczegółowe wskazówki i zalecenia dotyczące najlepszego użycia żądań ściągnięcia w celu ułatwienia współpracy przez scalanie zmian w zawartości.

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

• Wybierz narzędzia programistyczne: Upewnij się, że twoje podejście do tworzenia zawartości jest zgodne z sposobem współpracy z innymi twórcami zawartości i korzystania z kontroli wersji.
• Wybór między formatami pbip i pbix dla modeli i raportów: zazwyczaj format pbip jest bardziej korzystny dla kontroli źródła, ale użytkownicy samoobsługi mogą łatwiej znaleźć pliki pbix.
• Oddzielny semantyczny model i opracowywanie raportów: Kontrola wersji jest najbardziej efektywna podczas zarządzania zmianami dla różnych typów elementów, oddzielnie. Oddzielenie modelu i opracowywania raportów jest uważane za dobrą praktykę.
• Zdecyduj, ile obszarów roboczych potrzebujesz: Używanie oddzielnych środowisk ma kluczowe znaczenie dla sukcesu zarządzania cyklem życia zawartości. Upewnij się, że wyjaśniono, ile obszarów roboczych potrzebujesz i przeprowadzisz odpowiednie planowanie na poziomie obszaru roboczego.
• Zdecyduj, w jaki sposób zaimplementujesz kontrolę wersji: zdecyduj między prostszą metodą przy użyciu programu SharePoint lub OneDrive dla Firm albo przy użyciu usługi Azure DevOps, aby ułatwić kontrolę źródła.
• Skonfiguruj repozytorium zdalne: utwórz przestrzeń ze strukturą w folderze OneDrive lub repozytorium Git, w którym będzie przechowywana zawartość do śledzenia zmian i zarządzania nimi.
• Jeśli używasz kontroli źródła, skonfiguruj pliki .gitignore i .gitattributes: Upewnij się, że skonfigurowaliśmy repozytorium, aby śledzić tylko istotne zmiany.
• Jeśli używasz kontroli źródła, zdefiniuj strategie rozgałęziania i scalania: Upewnij się, że definiujesz jasne procesy konfigurowania i używania kontroli źródła w celu uzyskania najlepszej obsługi programowania. Unikaj nadmiernego komplikowania procesu. Zamiast tego spróbuj uzupełnić bieżący sposób pracy w zespołach programistycznych.

Powiązana zawartość

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