Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule wyjaśniono deweloperom, jak zintegrować kontrolę wersji usługi Git z narzędziem do zarządzania cyklem życia aplikacji (ALM) usługi Microsoft Fabric.
Uwaga
Niektóre elementy integracji z usługą Git są dostępne w wersji zapoznawczej. Aby uzyskać więcej informacji, zobacz listę obsługiwanych elementów.
Integracja z usługą Git w usłudze Microsoft Fabric umożliwia deweloperom integrowanie procesów programowania, narzędzi i najlepszych rozwiązań bezpośrednio z platformą Fabric. Umożliwia to deweloperom, którzy opracowują aplikacje w usłudze Fabric:
- Tworzenie kopii zapasowych i wersjonowanie ich pracy
- Przywróć poprzednie etapy zgodnie z potrzebami
- Współpraca z innymi osobami lub praca samodzielnie przy użyciu gałęzi usługi Git
- Zastosuj możliwości znanych narzędzi kontroli wersji do zarządzania elementami Fabric.
Integracja z kontrolą źródła jest na poziomie obszaru roboczego. Deweloperzy mogą wersjonować elementy opracowywane w obszarze roboczym w jednym procesie, z pełną widocznością wszystkich swoich elementów. Struktura obszaru roboczego, w tym podfoldery , jest zachowywana w repozytorium Git.
Zobacz listę elementów obsługiwanych .
Zapoznaj się z podstawowymi pojęciami dotyczącymi kontroli wersji i usługi Git.
Przeczytaj więcej na temat procesu integracji z usługą Git.
Przeczytaj o najlepszym sposobie zarządzania gałęziami usługi Git.
Informacje o ochronie prywatności
Przed włączeniem integracji z usługą Git zapoznaj się z następującymi zasadami zachowania poufności informacji:
- Zasady zachowania poufności informacji firmy Microsoft
- Omówienie ochrony danych usług Azure DevOps Services
- Umowa dotycząca ochrony danych w usłudze GitHub
Obsługiwani dostawcy usługi Git
Obsługiwane są następujące dostawcy usługi Git:
- Usługa Azure DevOps z tą samą dzierżawcą co dzierżawa usługi Fabric
- GitHub (tylko wersje w chmurze)
- GitHub Enterprise (tylko wersje w chmurze)
Obsługiwane elementy
Następujące elementy obsługują obecnie integrację z usługą Git:
Elementy inżynierii danych:
- Środowisko
- GraphQL(wersja zapoznawcza)
- Lakehouse(wersja zapoznawcza)
- Notatniki
- Definicje zadań platformy Spark(wersja zapoznawcza)
- Funkcje danych użytkownika (wersja zapoznawcza)
Elementy usługi Data Factory:
- Zadanie kopiowania(wersja zapoznawcza)
- Przepływ danych generacja 2
- Potok danych
- Dublowana baza danych
- Instalowanie usługi ADF (wersja zapoznawcza)
- Biblioteka zmiennych(wersja zapoznawcza)
Elementy analizy w czasie rzeczywistym:
Elementy magazynu danych:
- Warehouse(wersja zapoznawcza)
Elementy usługi Power BI:
- Zestaw metryk (wersja zapoznawcza)
- Aplikacja organizacji(wersja zapoznawcza)
- Raport podzielony na strony(wersja zapoznawcza)
- Raport (z wyjątkiem raportów połączonych z modelami semantycznymi hostowanymi w usługach Azure Analysis Services, SQL Server Analysis Services lub raportach eksportowanych przez program Power BI Desktop, które są zależne od modeli semantycznych hostowanych w usłudze MyWorkspace) (wersja zapoznawcza)
- Model semantyczny (z wyjątkiem zestawów danych typu push, połączenia na żywo z usługami Analysis Services, model v1) (wersja zapoznawcza)
Elementy bazy danych:
- Sql Database(wersja zapoznawcza)
Rozwiązania branżowe:
- Opiekazdrowotna (wersja zapoznawcza)
- Cohorta Opieki Zdrowotnej (wersja zapoznawcza)
Jeśli obszar roboczy lub katalog Git ma nieobsługiwane elementy, nadal można je połączyć, ale nieobsługiwane elementy są ignorowane. Nie są one zapisywane ani synchronizowane, ale nie są usuwane. Są one wyświetlane w panelu sterowania źródła, ale nie można ich zatwierdzić ani zaktualizować.
Rozważania i ograniczenia
Ogólne ograniczenia integracji z usługą Git
- Metoda uwierzytelniania w usłudze Fabric musi być co najmniej tak silna, jak metoda uwierzytelniania dla usługi Git. Jeśli na przykład usługa Git wymaga uwierzytelniania wieloskładnikowego, platforma Fabric musi również wymagać uwierzytelniania wieloskładnikowego.
- Zestawy danych usługi Power BI połączone z usługami Analysis Services nie są obecnie obsługiwane.
- Jeśli używasz tożsamości obszaru roboczego w jednym artefaktie i zatwierdzasz ją w usłudze Git, można ją zaktualizować (z powrotem do obszaru roboczego sieci szkieletowej) tylko w obszarze roboczym połączonym z tą samą tożsamością. Należy zachować ostrożność, ponieważ ma to również wpływ na funkcje, takie jak "branch out".
- Moduły podrzędne nie są obsługiwane.
- Suwerenne chmury nie są obsługiwane.
- Konto usługi Azure DevOps musi być zarejestrowane dla tego samego użytkownika, który korzysta z obszaru roboczego Fabric.
- Usługa Azure DevOps nie jest obsługiwana, jeśli włączono walidację zasad dostępu warunkowego IP.
- Administrator dzierżawy musi włączyć eksporty międzyregionowe, jeśli obszar roboczy i repozytorium Git znajdują się w dwóch różnych regionach.
- Jeśli twoja organizacja skonfigurowała dostęp warunkowy, upewnij się, że usługa Power BI ma te same warunki ustawione na potrzeby uwierzytelniania, które będą działać zgodnie z oczekiwaniami.
- Rozmiar zapisu jest ograniczony do 125 MB.
Ograniczenia usługi GitHub Enterprise
Niektóre wersje i ustawienia usługi GitHub Enterprise nie są obsługiwane. Na przykład:
- Usługa GitHub Enterprise Cloud z miejscem przechowywania danych (ghe.com)
- GitHub Enterprise Server z niestandardową domeną nie jest obsługiwany, nawet jeśli instancja jest publicznie dostępna
- Github Enterprise Server hostowany w sieci prywatnej
- Lista dozwolonych adresów IP
Ograniczenia obszaru roboczego
- Tylko administrator obszaru roboczego może zarządzać połączeniami z repozytorium Git , takimi jak łączenie, rozłączanie lub dodawanie gałęzi.
Po nawiązaniu połączenia każda osoba z uprawnieniami może pracować w obszarze roboczym. - Obszary robocze z zainstalowanymi aplikacjami szablonu nie mogą być połączone z usługą Git.
- Usługa MyWorkspace nie może nawiązać połączenia z dostawcą usługi Git.
Ograniczenia gałęzi i folderów
- Maksymalna długość nazwy gałęzi to 244 znaki.
- Maksymalna długość pełnej ścieżki dla nazw plików to 250 znaków. Dłuższe nazwy zawodzą.
- Maksymalny rozmiar pliku to 25 MB.
- Struktura folderów jest utrzymywana do 10 poziomów głębokości.
- Pobieranie raportu/zestawu danych jako pliku pbix z usługi po wdrożeniu ich przy użyciu integracji z usługą Git nie jest zalecane, ponieważ wyniki są zawodne. Zalecamy używanie programu PowerBI Desktop do pobierania raportów/zestawów danych jako pliku pbix.
- Jeśli nazwa wyświetlana elementu posiada którąkolwiek z tych cech, nazwa folderu Git jest zmieniana na ID logiczne (Guid) i typ.
- Zawiera więcej niż 256 znaków
- Kończy się . lub spacją
- Zawiera wszelkie niedozwolone znaki zgodnie z opisem w ograniczeniach nazw katalogów
- Po połączeniu obszaru roboczego z folderami z usługą Git należy zatwierdzić zmiany w repozytorium Git, jeśli struktura tego folderu jest inna.
Ograniczenia nazw katalogów
Nazwa katalogu, który nawiązuje połączenie z repozytorium Git, ma następujące ograniczenia dotyczące nazewnictwa:
- Nazwa katalogu nie może zaczynać się ani kończyć spacją ani kartą.
- Nazwa katalogu nie może zawierać żadnego z następujących znaków: "/:<>\*|
Folder elementu (folder zawierający pliki elementów) nie może zawierać żadnego z następujących znaków: ":<>\*?|. Jeśli zmienisz nazwę folderu na coś, co zawiera jeden z tych znaków, usługa Git nie może nawiązać połączenia ani zsynchronizować z obszarem roboczym i wystąpi błąd.
Rozgałęzianie ograniczeń
- Rozgałęzienie wymaga uprawnień wymienionych w tabeli uprawnień.
- Dla tej akcji musi istnieć dostępna pojemność.
- Wszystkie ograniczenia dotyczące nazewnictwa obszarów roboczych i gałęzi mają zastosowanie podczas rozgałęziania się do nowego obszaru roboczego.
- W nowym obszarze roboczym dostępne są tylko obsługiwane elementy usługi Git.
- Lista powiązanych gałęzi zawiera tylko gałęzie i obszary robocze, do których masz uprawnienia do wyświetlania.
- Integracja z usługą Git musi być włączona.
- Podczas rozgałęziania zostanie utworzona nowa gałąź, a ustawienia z oryginalnej gałęzi nie są kopiowane. Dostosuj ustawienia lub definicje, aby upewnić się, że nowe zasady organizacji są zgodne.
- Podczas rozgałęziania do istniejącego obszaru roboczego:
- Docelowy obszar roboczy musi obsługiwać połączenie z Git.
- Użytkownik musi być administratorem docelowego obszaru roboczego.
- Docelowy obszar roboczy musi mieć pojemność.
- Obszar roboczy nie może mieć aplikacji wzorcowych.
- Pamiętaj, że przenosząc się do innego obszaru roboczego, wszystkie elementy, które nie są zapisane w usłudze Git, mogą być utracone. Zalecamy zatwierdzenie wszystkich elementów, które chcesz zachować przed rozgałęzianiem.
Ograniczenia synchronizacji i zatwierdzania
- Możesz synchronizować tylko w jednym kierunku naraz. Nie można jednocześnie zatwierdzać i aktualizować.
- Etykiety poufności nie są obsługiwane, a eksportowanie elementów z etykietami poufności może być wyłączone. Aby zatwierdzić elementy z etykietami poufności bez etykiety poufności, poproś administratora o pomoc.
- Działa z ograniczonymi elementami. Nieobsługiwane elementy w folderze są ignorowane.
- Duplikowanie nazw nie jest dozwolone. Nawet jeśli usługa Power BI zezwala na duplikowanie nazw, aktualizacja, zatwierdzanie lub cofanie akcji kończy się niepowodzeniem.
- B2B nie jest obsługiwany.
- Rozwiązywanie konfliktów jest częściowo wykonywane w usłudze Git.
- Podczas procesu Zatwierdzania w usłudze Git usługa szkieletowa usuwa pliki w folderze elementu , które nie są częścią definicji elementu. Niepowiązane pliki, które nie są w folderze elementu, nie są usuwane.
- Po zatwierdzeniu zmian możesz zauważyć nieoczekiwane zmiany w elemencie, którego nie wprowadzono. Te zmiany są semantycznie nieistotne i mogą wystąpić z kilku powodów. Na przykład:
- Ręczne zmienianie pliku definicji elementu. Te zmiany są prawidłowe, ale mogą być inne niż w przypadku wykonania w edytorach. Jeśli na przykład zmienisz nazwę kolumny modelu semantycznego w usłudze Git i zaimportujesz tę zmianę do obszaru roboczego, przy następnym zatwierdzeniu zmian w modelu semantycznym plik bim zarejestruje się zgodnie ze zmianą, a zmodyfikowana kolumna zostanie wypchnięta z tyłu
columns
tablicy. Dzieje się tak, ponieważ aparat AS, który generuje pliki bim, przesuwa zmienione kolumny na koniec tablicy. Ta zmiana nie ma wpływu na sposób działania elementu. - Zatwierdzanie pliku, który używa podziałów wierszy CRLF . Usługa używa podziałów wierszy LF (line feed). Jeśli w repozytorium Git były pliki z elementami z podziałami wierszy CRLF, po zatwierdzeniu przez usługę te pliki zostaną zmienione na LF. Jeśli na przykład otworzysz raport na pulpicie, zapisz plik projektu (pbip) i przekaż go do usługi Git przy użyciu crLF.
- Ręczne zmienianie pliku definicji elementu. Te zmiany są prawidłowe, ale mogą być inne niż w przypadku wykonania w edytorach. Jeśli na przykład zmienisz nazwę kolumny modelu semantycznego w usłudze Git i zaimportujesz tę zmianę do obszaru roboczego, przy następnym zatwierdzeniu zmian w modelu semantycznym plik bim zarejestruje się zgodnie ze zmianą, a zmodyfikowana kolumna zostanie wypchnięta z tyłu
- Odświeżanie modelu semantycznego przy użyciu interfejsu API odświeżania rozszerzonego powoduje różnice w usłudze Git po każdym odświeżeniu.