Udostępnij za pośrednictwem


Planowanie implementacji usługi Power BI: Planowanie i projektowanie zawartości

Uwaga

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

Ten artykuł ułatwia planowanie i projektowanie zawartości 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.
  • Twórcy zawartości i właściciele zawartości: użytkownicy, którzy tworzą zawartość, którą chcą publikować w portalu sieci szkieletowej, aby udostępniać je innym osobom. Te osoby są odpowiedzialne za zarządzanie cyklem życia tworzonej zawartości usługi Power BI.

Zarządzanie cyklem życia składa się z procesów i praktyk używanych do obsługi zawartości z jej tworzenia do ewentualnego wycofania. Jak opisano w pierwszym artykule z tej serii, zarządzanie cyklem życia zawartości usługi Power BI jest ważne, aby zapewnić niezawodne i spójne dostarczanie zawartości użytkownikom biznesowym.

Pierwszym etapem cyklu życia zawartości jest planowanie i projektowanie zawartości. Zwykle rozpoczynasz cykl życia zawartości, wykonując planowanie rozwiązań analizy biznesowej. Zbierasz wymagania , aby zrozumieć i zdefiniować problem, który powinien rozwiązać Twoje rozwiązanie, i dotrzeć do projektu rozwiązania. Podczas tego etapu planowania i projektowania należy podjąć kluczowe decyzje, aby przygotować się do późniejszych etapów.

Na poniższej ilustracji przedstawiono cykl życia zawartości usługi Power BI z wyróżnionym etapem, w którym planujesz i projektujesz zawartość.

Diagram przedstawia cykl życia zawartości usługi Power BI. Wyróżniono etap 1 dotyczący planowania i projektowania zawartości.

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 zagadnieniach i decyzjach dotyczących planowania i projektowania zawartości w odniesieniu do zarządzania cyklem życia.

  • Aby uzyskać więcej informacji na temat efektywnego planowania i projektowania rozwiązania sieci szkieletowej lub usługi Power BI, zalecamy przeczytanie artykułu dotyczącego planowania rozwiązania.
  • Aby uzyskać więcej informacji na temat efektywnego planowania migracji usługi Power BI, zalecamy przeczytanie serii migracji usługi Power BI.

Podczas zbierania wymagań należy jasno opisać aspekty zawartości, które mają wpływ na podejście do zarządzania cyklem życia. Te aspekty należy udokumentować w ramach planowania i projektowania rozwiązania.

W poniższych sekcjach w tym artykule opisano kluczowe aspekty i zagadnienia dotyczące rozwiązania, które motywuje twoje podejście do zarządzania cyklem życia podczas planowania i projektowania zawartości.

Identyfikowanie i opisywanie zawartości

Podczas projektowania rozwiązania należy opisać zawartość, kto ją utworzy, kto będzie go obsługiwać, oraz jak krytyczna jest ta zawartość dla organizacji. Należy rozwiązać te czynniki podczas lub po zakończeniu zbierania wymagań w ramach projektu rozwiązania.

Uwaga

Podobnie jak w przypadku wymagań, odpowiedzi na te pytania mogą ulec zmianie podczas opracowywania rozwiązania lub w późniejszym cyklu życia. Po udzieleniu odpowiedzi na te pytania należy przygotować się do okresowego ponownego oceniania ich podczas wprowadzania zmian w zawartości lub skalowania ich w liczbie użytkowników, którym służy.

Odpowiedz na następujące pytania dotyczące zawartości, aby ułatwić podejmowanie późniejszych decyzji dotyczących zarządzania cyklem życia.

Jaki jest format zawartości?

Typ, zakres i złożoność zawartości motywują kluczowe decyzje dotyczące sposobu zarządzania nią. Na przykład pojedynczy raport dla ograniczonej grupy odbiorców wymaga innego podejścia do zarządzania cyklem życia w porównaniu z modelem semantycznym, który będzie używany przez całą organizację i przez wiele różnych obciążeń podrzędnych.

Odpowiedz na pytania podobne do poniższych, aby ułatwić określenie typu tworzonej zawartości.

  • Które typy elementów mają zostać utworzone i ilu z nich? Na przykład czy utworzysz elementy danych, takie jak przepływy danych lub semantyczne modele, elementy raportowania, takie jak raporty lub pulpity nawigacyjne, czy kombinacja obu tych elementów?
  • W jaki sposób zawartość jest dostarczana do użytkowników zawartości? Na przykład użytkownicy będą używać elementów danych do tworzenia własnej zawartości, czy będą wyświetlać tylko scentralizowane raporty, czy kombinację obu tych elementów?
  • Jak złożona jest zawartość? Czy na przykład jest to mały prototyp, czy duży semantyczny model obejmujący wiele procesów biznesowych?
  • Czy oczekujesz, że skala, zakres i złożoność zawartości będą rosnąć wraz z upływem czasu? Na przykład zawartość będzie obejmować inne regiony lub obszary biznesowe w przyszłości?
  • Jak długo oczekujesz, że firma będzie potrzebować tej zawartości? Czy na przykład ta zawartość będzie wspierać kluczową inicjatywę firmy, która ma skończony harmonogram?

Napiwek

Rozważ utworzenie diagramu architektonicznego w celu opisania formatu zawartości. Można uwzględnić różne źródła danych, typy elementów i odbiorców zawartości oraz relacje między tymi odrębnymi składnikami. Diagram architektoniczny może pomóc w zwięzłym przedstawianiu zawartości i jej złożoności oraz ułatwia planowanie zarządzania cyklem życia. Ikony sieci szkieletowej i ikony platformy Azure umożliwiają tworzenie tych diagramów w oprogramowaniu zewnętrznym. Alternatywnie możesz użyć diagramów platformy Azure, które są dostarczane z ikonami i narzędziami do rysowania, aby tworzyć te diagramy.

Przykład takich diagramów można znaleźć na diagramach scenariuszy planowania implementacji usługi Power BI.

KtoTo utworzy i będzie obsługiwać zawartość?

Twórcy zawartości mają różne potrzeby, umiejętności i przepływy pracy. Te czynniki będą miały wpływ na powodzenie różnych podejść do zarządzania cyklem życia. Większe, centralne zespoły ze współpracą często wymagają bardziej zaawansowanego zarządzania cyklem życia zawartości niż mniejsze zespoły twórców samoobsługi.

Odpowiedz na pytania podobne do poniższych, aby ułatwić określenie, kto utworzy lub będzie obsługiwał zawartość.

  • Ilu różnych osób oczekuje się utworzenia tej zawartości? Czy wielu twórców zawartości współpracuje, czy jest jedną osobą odpowiedzialną za tworzenie zawartości?
  • Czy twórcy zawartości znają zarządzanie cyklem życia i powiązane pojęcia, takie jak kontrola wersji? Czy twórcy zawartości rozumieją zalety zarządzania cyklem życia?
  • Czy twórcy zawartości, którzy opracowują rozwiązanie, będą tymi samymi osobami, które ją obsługują po wdrożeniu?
  • Czy twórcy zawartości lub ich zespoły mają istniejące praktyki zarządzania cyklem życia w celu obsługi istniejących rozwiązań?
  • Czy twórcy zawartości korzystają obecnie z narzędzi do zarządzania cyklem życia, takich jak Azure DevOps?

Ważne

Upewnij się, że użytkownik jasno udokumentował, kto jest odpowiedzialny za tworzenie zawartości i kto będzie go obsługiwał po wdrożeniu w środowisku produkcyjnym. Zaangażuj wszystkie te osoby w planowaniu zarządzania cyklem życia zawartości.

Jaka jest ważność zawartości?

W zależności od tego, jak ważna jest zawartość dla firmy, podejmujesz różne decyzje dotyczące zarządzania nią. Zawartość krytyczna dla działania firmy wymaga bardziej niezawodnych metod zarządzania cyklem życia zawartości w celu ochrony jakości i ograniczenia możliwych zakłóceń.

Odpowiedz na pytania podobne do poniższych, aby określić, czy zawartość jest krytyczna.

  • Jak krytyczna jest ta zawartość dla firmy? Jak pilna jest prośba o jej opracowanie?
  • Czy decyzje lub działania krytyczne dla działania firmy będą podejmowane na podstawie informacji dostarczonych przez tę zawartość?
  • Jak ogólnie można oczekiwać dystrybucji tej zawartości (od całej organizacji do ograniczonego lokalnego zespołu)?
  • Czy kierownictwo lub inni decydenci strategiczni będą polegać na tej treści dla swojej pracy?
  • Jaki jest wpływ tej zawartości? Na przykład jeśli zawartość jest nagle niedostępna, jaki będzie wpływ na działalność biznesową, na przykład utracone przychody lub przerwane procesy biznesowe?

W przypadku wystarczająco zidentyfikowanych i opisanych zawartości, którą utworzysz, należy wybrać sposób współpracy twórców zawartości.

Decydowanie o tym, jak twórcy zawartości powinni współpracować

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. Podczas tworzenia złożonych rozwiązań zalecamy używanie skutecznych narzędzi, które ułatwiają strukturę, zarządzanie i obsługę współpracy. Istnieje wiele sposobów współpracy podczas tworzenia zawartości usługi Power BI, na przykład przy użyciu usługi Microsoft Teams lub Azure DevOps.

Napiwek

Nawet jeśli twórcy zawartości działają niezależnie, nadal mogą korzystać z planowania i struktury pracy przy użyciu narzędzi, takich jak Microsoft Teams i Azure DevOps.

Microsoft Teams

W przypadku mniejszych lub prostszych projektów twórcy zawartości mogą współpracować przy użyciu usługi Microsoft Teams.

Diagram przedstawia podejście 1, które dotyczy współpracy przy użyciu usługi Microsoft Teams. Elementy pokazane na diagramie są opisane w dalszej części.

Za pomocą usługi Microsoft Teams twórcy zawartości strukturyją komunikację, planowanie i pracę w zespołach i kanałach. Usługa Microsoft Teams jest często dobrym wyborem w przypadku prostszych scenariuszy współpracy. Na przykład zdecentralizowane zespoły, które generują zawartość dla ograniczonej grupy odbiorców, mogą używać bibliotek dokumentów do przechowywania plików i kontroli wersji. Mogą również korzystać z innych zintegrowanych narzędzi i usług.

Napiwek

Zalecamy korzystanie z usługi Microsoft Teams w celu ułatwienia efektywnego zarządzania cyklem życia zawartości w scenariuszach samoobsługowych z zdecentralizowanym dostarczaniem zawartości.

Aby współpracować i komunikować się w usłudze Microsoft Teams, używasz usług pomocniczych w całym cyklu życia zawartości usługi Power BI.

  • Planner: właściciele zawartości mogą używać narzędzia Planner do tworzenia planów, których używają do śledzenia zadań i pracy w zakresie zawartości. Zadania mogą opisywać problemy, błędy lub funkcje w rozwiązaniu oraz odpowiednie osoby biorące udział w projekcie.
  • SharePoint: twórcy zawartości mogą przechowywać pliki i zarządzać nimi w bibliotece dokumentów usługi Microsoft Teams lub połączonej witrynie dla każdego kanału. Pliki zawartości przechowywane w programie SharePoint mogą używać kontroli wersji, aby ułatwić śledzenie zmian zawartości i zarządzanie nimi. Aby uzyskać więcej informacji na temat śledzenia zmian i zarządzania nimi przy użyciu programu SharePoint, zobacz Etap 2. Tworzenie zawartości i zarządzanie zmianami.
  • Zatwierdzenia: Twórcy zawartości i właściciele mogą konfigurować przepływy pracy i używać ich do zatwierdzania zmian zawartości lub wydań po przejrzeniu.
  • Sieć szkieletowa i usługa Power BI: twórcy zawartości i właściciele mogą uzyskiwać dostęp do portalu sieci szkieletowej z poziomu usługi Microsoft Teams. Z tego miejsca mogą zarządzać zawartością lub omawiać je oraz dodawać przydatne raporty do kart w kanałach usługi Teams.
  • Inne integracje: Twórcy zawartości mogą korzystać z innych usług firmy Microsoft lub innych firm, które integrują się z usługą Microsoft Teams, aby najlepiej dopasować ich preferowany przepływ pracy i potrzeby.

Zalecamy zdefiniowanie procesu ustrukturyzowanego sposobu współpracy twórców zawartości przy użyciu usługi Microsoft Teams. Upewnij się, że określono:

  • Jak zarządzać dostępem do zespołów i kanałów.
  • KtoTo odpowiada za zarządzanie zespołami i kanałami.
  • Jak praca jest ograniczona i zorganizowana w odrębne zespoły, kanały i plany.
  • Jak twórcy zawartości powinni używać biblioteki dokumentów do organizowania plików i śledzenia zmian i zarządzania nimi. Na przykład sposób organizowania biblioteki dokumentów i sprawdzania, czy twórcy zawartości powinni zaewidencjonować i wyewidencjonować pliki.
  • Czy twórcy zawartości powinni używać funkcji Odświeżanie w usłudze OneDrive do automatycznego publikowania plików programu Power BI Desktop (pbix).
  • Jak są rozwiązywane konflikty synchronizacji plików.
  • Kiedy należy archiwizować i usuwać pliki z biblioteki dokumentów, które nie są już istotne.

Azure DevOps

Twórcy zawartości i właściciele mogą również komunikować się i współpracować w centralnym, zorganizowanym centrum przy użyciu usługi Azure DevOps.

Diagram przedstawia podejście 2, które dotyczy współpracy przy użyciu usługi Azure DevOps. Elementy pokazane na diagramie są opisane w dalszej części.

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.

Korzystając z usługi Azure DevOps, twórcy zawartości używają projektów do tworzenia struktury komunikacji, planowania i pracy. Ponadto twórcy zawartości mogą organizować zarządzanie cyklem życia zawartości z poziomu usługi Azure DevOps, wykonując kontrolę źródła, walidację i wdrażanie. Kontrola źródła to proces zarządzania bardziej szczegółowymi zmianami w kodzie zawartości i metadanych.

Usługa Azure DevOps jest często dobrym wyborem w przypadku bardziej zaawansowanych scenariuszy współpracy, ponieważ istnieją usługi pomocnicze i opcje organizowania tworzenia i wdrażania zawartości.

Napiwek

Zalecamy użycie usługi Azure DevOps do efektywnego zarządzania cyklem życia zawartości w scenariuszach przedsiębiorstwa ze scentralizowanym dostarczaniem zawartości. Współpraca przy użyciu usługi Azure DevOps lub podobnych narzędzi jest preferowana w większych lub bardziej złożonych scenariuszach dotyczących współpracy przy użyciu usługi Microsoft Teams lub SharePoint. Dzieje się tak, ponieważ dostępnych jest więcej narzędzi i opcji ułatwiających bardziej niezawodną współpracę i automatyzację.

Zalecamy zdefiniowanie strukturalnego procesu współpracy twórców zawartości przy użyciu usługi Azure DevOps. Upewnij się, że określono:

  • Jak działa zakres i jak gałęzie zawartości są tworzone, nazwane i używane.
  • Jak autorzy grupują i zatwierdzają zmiany i opisują je za pomocą komunikatów zatwierdzenia.
  • KtoTo odpowiedzialny za przeglądanie i zatwierdzanie zmian przy użyciu żądań ściągnięcia.
  • Sposób rozwiązywania konfliktów scalania żądań ściągnięcia i ich rozwiązywania.
  • 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 można wycofać.

Uwaga

Usługę Microsoft Teams można również używać razem z usługą Azure DevOps, ponieważ istnieją różne sposoby integrowania tych usług. Można na przykład wyświetlać usługi Azure Boards i monitorować zdarzenia w usłudze Azure Pipelines oraz zarządzać nimi z poziomu usługi Microsoft Teams.

Najważniejsze jest to, że używasz narzędzi i usług, które ułatwiają współpracę dla Ciebie, oraz najlepiej pasujące do potrzeb twojego zespołu i sposobu ich działania.

Po podjęciu decyzji o tym, czy i jak twórcy zawartości powinni współpracować, należy zdecydować, gdzie będą przechowywane pliki. Wiele z tych plików będzie przechowywanych w miejscu, w którym zdecydujesz się współpracować.

Decydowanie o tym, gdzie mają być przechowywane pliki

Podczas tworzenia zawartości zazwyczaj są tworzone różne typy plików. Ważne jest, aby zdecydować, gdzie mają być przechowywane te pliki, aby efektywnie zarządzać nimi.

Napiwek

Przechowuj pliki, do których można uzyskiwać dostęp wielu członków zespołu i gdzie można łatwo śledzić zmiany (nazywane kontrolą wersji). Takie podejście zapewnia, że odejście członka zespołu lub utrata pliku nie prowadzi do zakłóceń.

Typy plików, które należy przechowywać, często obejmują:

  • Pliki zawartości: pliki zawierające dane lub metadane zawartości. Pliki zawartości zawierające dane, takie jak pliki pbix i Power BI Project (pbip), zawierają informacje poufne. Przechowuj pliki zawartości w bezpiecznej lokalizacji dostępnej tylko dla tych, którzy potrzebują do nich dostępu. Ponadto należy przechowywać pliki zawartości w lokalizacji obsługującej kontrolę wersji, taką jak biblioteka dokumentów w usłudze Microsoft Teams lub repozytorium Git w usłudze Azure DevOps. Przykłady plików zawartości to:
    • Pliki programu Power BI Desktop (pbix)
    • Pliki programu Power BI Project (pbip)
    • Pliki raportu podzielonego na strony usługi Power BI (rdl)
    • Pliki metadanych modelu (.bim lub TMDL)
    • Pliki metadanych przepływu danych (.json)
  • Pliki źródła danych: pliki używane przez elementy danych, takie jak modele semantyczne lub przepływy danych. Zawartość jest bezpośrednio zależna od plików źródła danych, dlatego należy dokładnie rozważyć miejsce ich przechowywania, ponieważ usunięcie ich spowoduje niepowodzenie odświeżania danych. Ponadto te pliki mogą zawierać poufne informacje. Dlatego przechowuj pliki źródeł danych w bezpiecznym, niezawodnym i godnym zaufania środowisku, które ma ograniczony dostęp przez inne osoby. Przykłady plików źródeł danych mogą obejmować:
    • Źródła danych ze strukturą, takie jak skoroszyty programu Excel, pliki Parquet lub CSV.
    • Częściowo ustrukturyzowane źródła danych, takie jak pliki JSON lub XML.
    • Źródła danych bez struktury, takie jak obrazy importowane do raportów.
  • Pliki pomocnicze: pliki obsługujące tworzenie lub zarządzanie zawartością, ale nie są wymagane do jej działania. Pliki pomocnicze powinny być przechowywane w lokalizacji, która obsługuje kontrolę wersji i gdzie inne narzędzia i twórcy zawartości mogą uzyskiwać do nich dostęp. Przykłady plików pomocniczych mogą obejmować:
    • Pliki reguł analizatora najlepszych rozwiązań (.json).
    • Pliki motywu usługi Power BI (.json).
    • Pliki kodu źródłowego dla zawartości i zapytań.
    • Pliki wizualizacji niestandardowej (pbiviz).
  • Szablony i dokumentacja: pliki, które ułatwiają tworzenie zawartości samoobsługowej lub opisują istniejącą zawartość. Szablony i dokumentacja powinny być łatwo dostępne dla osób, które muszą z nich korzystać. Przykłady szablonów i dokumentacji mogą obejmować:
    • Pliki szablonu usługi Power BI (pbit).
    • Szablony wizualizacji i przykładowe raporty.
    • Projekty rozwiązań i dokumentacja.
    • Planowanie rozwiązań i harmonogramy działania.
    • Żądania użytkowników i problemy z rozwiązaniem.

Uwaga

Niektóre pliki zawartości, takie jak pliki pbix i pbip, mogą zawierać poufne dane importowane ze źródeł danych. Ponadto pliki metadanych, takie jak pliki TMDL lub pbit, mogą również zawierać poufne informacje. Upewnij się, że podejmujesz niezbędne środki ostrożności w celu przechowywania tych plików w bezpiecznych lokalizacjach i że ćwiczysz skuteczne zapobieganie utracie danych.

Istnieją różne opcje przechowywania plików. Upewnij się, że wybrano odpowiednią lokalizację, w zależności od typu pliku, jego zawartości i sposobu jego użycia.

SharePoint Online lub OneDrive

Typowym rozwiązaniem do przechowywania plików jest użycie witryn programu SharePoint . Program SharePoint jest powszechnie dostępny dla większości użytkowników i wysoce zintegrowany zarówno z usługą Power BI, jak i innymi aplikacjami platformy Microsoft 365, takimi jak Microsoft Teams. Ponadto ma wbudowaną kontrolę wersji, co ułatwia przechowywanie większości typów plików. Kontrola wersji umożliwia wyświetlanie zapisanych wersji pliku i zarządzanie nimi.

Podczas przechowywania plików w programie SharePoint należy wziąć pod uwagę następujące kwestie.

  • Organizacja: Upewnij się, że zachowasz spójną i logiczną strukturę, aby łatwo znaleźć określone pliki. Należy używać dobrych konwencji nazewnictwa, organizować pliki w folderach i archiwizować pliki, które nie są już istotne dla bieżących projektów.
  • Odświeżanie w usłudze OneDrive: możesz połączyć opublikowany model semantyczny lub raport z plikiem pbix przechowywanym w witrynie programu SharePoint lub OneDrive dla Firm (nazywanej również usługą OneDrive dla miejsca pracy lub nauki). Dzięki temu podejściu nie trzeba już publikować modelu semantycznego w celu wprowadzenia zmian. Zamiast tego zmiany są widoczne po automatycznym odświeżeniu usługi OneDrive, które odbywa się co godzinę. Chociaż wygodne, należy pamiętać, że takie podejście wiąże się z pewnymi zastrzeżeniami i wyzwaniami. Gdy wszystko pójdzie, nie można go łatwo odwrócić.
  • Raporty w wersji zapoznawczej: w programie SharePoint można wyświetlać raporty usługi Power BI bez konieczności instalowania programu Power BI Desktop lub pobierania pliku pbix lokalnie. Po otwarciu raportów w ten sposób są one wyświetlane w przeglądarce. Ta funkcja może być wygodną alternatywą dla wyświetlania raportów z portalu sieci szkieletowej. Jest ona domyślnie włączona w ustawieniach dzierżawy sieci szkieletowej.

Napiwek

Podczas współpracy przy użyciu usługi Microsoft Teams rozważ przechowywanie plików w bibliotece dokumentów kanału. Takie podejście ułatwia scentralizowanie plików i ułatwia współpracę.

Rozważ zapisanie następujących typów plików w programie SharePoint.

  • Szablony i dokumentacja: Przechowuj szablony i dokumentację w programie SharePoint, gdy nie masz istniejącego rozwiązania magazynu. Program SharePoint jest idealny dla tych plików, ponieważ można udzielić dostępu innym osobom i zarządzać plikami bez złożonej konfiguracji lub procesów.
  • Pliki pomocnicze: przechowuj pliki pomocnicze w programie SharePoint, gdy nie masz istniejącego rozwiązania magazynu. Jednak niektóre pliki pomocnicze (takie jak motyw usługi Power BI .json plików dla raportów) mogą być lepiej przechowywane w systemie kontroli wersji, który umożliwia wyświetlanie zapisanych zmian i zarządzanie nimi.
  • Pliki zawartości: przechowuj zawartość w programie SharePoint, gdy nie ma to krytycznego dla firmy lub gdy nie masz dostępu do repozytorium zdalnego, takiego jak Azure Repos.
  • Źródła danych: przechowuj źródła danych w programie SharePoint tylko wtedy, gdy mają niewielki rozmiar i złożoność. Ćwiczenie dyscypliny podczas korzystania z programu SharePoint do przechowywania plików źródłowych danych. Rozważ inne możliwe alternatywy, takie jak OneLake.

Uwaga

Nie używaj programu SharePoint jako alternatywy dla odpowiedniej architektury danych. Przechowywanie plików źródeł danych w programie SharePoint może być wygodne w niektórych ograniczonych scenariuszach, jednak takie podejście nie jest skalowane w przypadku większych, bardziej złożonych źródeł danych ani mniejszego opóźnienia danych.

Ostrzeżenie

Nie używaj osobistych systemów plików ani osobistych kont usługi OneDrive do przechowywania plików. Jeśli właściciel opuści organizację, te pliki nie będą już dostępne.

OneLake

Jeśli masz pojemność sieci szkieletowej, usługa OneLake może być dobrym wyborem do przechowywania plików źródłowych danych. Pliki można przekazywać lub synchronizowaćz usługą OneLake przy użyciu usługi OneLake Eksplorator plików, gdzie można je przekształcić w tabele do użycia w obciążeniach podrzędnych, takich jak usługa Power BI. W przypadku większych lub regularnie aktualizowanych źródeł danych można automatycznie ładować pliki do usługi OneLake przy użyciu usługi Fabric Data Factory lub innych aplikacji korzystających z interfejsu API usługi Azure Data Lake Storage (ADLS) Gen2 lub zestawu SDK języka Python usługi Azure Storage.

Uwaga

Akcje, takie jak przekazywanie lub pobieranie plików z usługi OneLake , zużywają jednostki pojemności sieci szkieletowej. Należy monitorować metryki pojemności i podejmować kroki, aby uniknąć obciążenia pojemności spowodowanego niepotrzebnym przenoszeniem dużych plików.

Ponadto pliki dostępne przez użytkowników z Eksplorator plików OneLake są narażone na przypadkowe zmiany lub utratę. Zalecamy unikanie używania Eksplorator plików OneLake dla rozwiązań o znaczeniu krytycznym dla działania firmy.

Ostrzeżenie

OneLake Eksplorator plików ma kilka ważnych ograniczeń i zagadnień. Na przykład usługa OneLake nie obsługuje kontroli wersji plików, takich jak SharePoint lub OneDrive. Podczas decydowania o tym, gdzie mają być przechowywane pliki, należy wziąć pod uwagę te zagadnienia i ograniczenia.

Napiwek

Podczas przechowywania danych w usłudze OneLake rozważ włączenie ciągłości działania i odzyskiwania po awarii (BCDR) w celu ograniczenia ryzyka utraty danych. Po włączeniu bcDR dane są duplikowane i przechowywane w dwóch różnych regionach geograficznych zgodnie ze standardowymi parami regionów platformy Azure.

Repozytorium zdalne

Twórcy zawartości mogą zatwierdzać i zapisywać pracę z komputera lokalnego w repozytorium zdalnym, takim jak repozytorium Git usługi Azure Repos , w regularnych odstępach czasu podczas opracowywania. Repozytorium zdalne zawiera najnowszą wersję rozwiązania i jest dostępne dla całego zespołu deweloperskiego. Zazwyczaj repozytorium zdalne ułatwia bardziej zaawansowane metody zarządzania cyklem życia niż korzystanie z usługi Teams, SharePoint lub OneDrive. Dzieje się tak dlatego, że za pomocą zdalnego repozytorium twórcy zawartości mogą korzystać z bardziej zaawansowanych opcji współpracy nad plikami lub śledzenia zmian plików i zarządzania nimi. Na przykład twórcy zawartości mogą pracować nad własną gałęzią repozytorium zdalnego, aby wprowadzić zmiany, i poprosić o scalenie tych zmian z gałęzią główną, gdy będą gotowe.

Rozważ przechowywanie następujących typów plików w repozytorium zdalnym.

  • Szablony i dokumentacja: przechowywanie szablonów i dokumentacji w repozytorium zdalnym podczas zarządzania projektem przy użyciu powiązanych usług, takich jak Azure DevOps.
  • Pliki pomocnicze: przechowuj pliki pomocnicze w repozytorium zdalnym, gdy jest dostępny do łatwego śledzenia zmian i zarządzania nimi.
  • Pliki zawartości: przechowuj zawartość w repozytorium zdalnym, gdy ma to kluczowe znaczenie dla firmy lub zamierzasz współpracować z innymi deweloperami nad tą samą zawartością. Repozytorium zdalne jest idealne do śledzenia zmian zawartości i ułatwiania współpracy.

Napiwek

W przypadku korzystania z repozytorium zdalnego rozważ przechowywanie raportów i modeli semantycznych usługi Power BI jako plików projektów programu Power BI Desktop (pbip) zamiast plików pbix. Dzieje się tak, ponieważ zapisanych zmian nie można zidentyfikować w pliku pbix.

Brak plików: zawartość utworzona w portalu sieci szkieletowej

Twórcy zawartości mogą tworzyć zawartość bezpośrednio w portalu sieci szkieletowej. W tym scenariuszu zwykle nie działają bezpośrednio z plikami zawartości. Zawartość powinna być zwykle tworzona w portalu sieci szkieletowej tylko wtedy, gdy nie można tworzyć typów elementów w innym miejscu (takich jak przepływy danych, pulpity nawigacyjne lub karty wyników). Możesz również tworzyć raporty i modele semantyczne w portalu sieci szkieletowej, gdy nie masz dostępu do maszyny z systemem Windows i dlatego nie można używać programu Power BI Desktop. Aby uzyskać więcej informacji, zobacz Narzędzia użytkownika i urządzenia.

Uwaga

Nie można pobrać jako pliku zawartości utworzonej w portalu sieci szkieletowej. Na przykład raporty utworzone w portalu sieci szkieletowej nie mogą być pobierane jako pliki pbix.

Podczas tworzenia zawartości w portalu sieci szkieletowej należy użyć interfejsów API sieci szkieletowej lub integracji usługi Git, aby utworzyć kopię zapasową definicji zawartości. Podczas tworzenia kopii zapasowych definicji zawartości można ograniczyć zakłócenia, jeśli ta zawartość zostanie przypadkowo usunięta lub przypadkowo zmieniona. Jeśli zawartość zostanie przypadkowo usunięta lub zmieniona, możesz ją zamienić przy użyciu kopii zapasowej.

Lista kontrolna — podczas planowania i projektowania zawartości kluczowe decyzje i akcje obejmują:

  • Planowanie rozwiązań: Zbierz wymagania biznesowe i wymagania techniczne, aby wystarczająco zrozumieć problem, który będzie rozwiązywać zawartość, oraz jak ta zawartość rozwiąże problem.
  • Określ, kto utworzy zawartość: w zależności od przepływu pracy, umiejętności i potrzeb poszczególnych twórców zawartości mogą być potrzebne różne podejścia do zarządzania cyklem życia.
  • Określ, czy wielu twórców zawartości musi współpracować: upewnij się, że współpracując twórcy zawartości używają typów plików obsługujących kontrolę wersji, takich jak pliki pbip.
  • Zdecyduj, jak twórcy zawartości będą współpracować: zdecyduj, jak zaawansowana będzie współpraca. Ponadto zdecyduj, w jaki sposób ułatwisz tę współpracę, na przykład przy użyciu usługi Microsoft Teams lub Usługi Azure DevOps.
  • Konfigurowanie narzędzi do współpracy: upewnij się, że wykonasz niezbędną konfigurację po raz pierwszy dla rozwiązania lub projektu. Podejmij kluczowe decyzje dotyczące sposobu zarządzania współpracą przy użyciu tych narzędzi.
  • Przechowuj pliki źródeł danych w programie SharePoint lub OneLake: przechowuj małe, proste pliki źródła danych w programie SharePoint. W przeciwnym razie zamiast tego użyj usługi OneLake lub ADLSGen2 (jeśli są dostępne).
  • Przechowywanie zawartości i plików pomocniczych w programie SharePoint lub repozytorium zdalnym: w przypadku prostszych, mniejszych projektów należy używać programu SharePoint dla większości plików, jeśli jest ona zorganizowana i dobrze praktykujesz zarządzanie dostępem. W przypadku większych środowisk lub gdy wymagana jest współpraca równoległa, rozważ użycie repozytorium zdalnego, które zapewni szczegółową widoczność zmian zawartości.
  • Przechowywanie szablonów i dokumentacji w programie SharePoint: upewnij się, że szablony i dokumentacja są łatwe dla innych osób do znajdowania, używania i zrozumienia.
  • Planowanie programowania i wdrażania: Aby zakończyć ten pierwszy etap, wykonaj konkretne planowanie, aby rozwiązać kluczowe obszary i przeprowadzić wstępną konfigurację. Na przykład ustanów narzędzia i przetestuj połączenia ze źródłem danych.

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