Integracja git do tworzenia magazynów Fabric

Dotyczy: ✅ Magazynu w platformie Microsoft Fabric

Ten artykuł wyjaśnia zalety tworzenia i wdrażania Fabric Data Warehouse z wbudowaną integracją Git w Fabric.

Important

Ta funkcja jest dostępna w wersji zapoznawczej.

Dzięki integracji z Gitem w Fabric zespoły mogą stosować nowoczesne praktyki kontroli wersji do rozwoju magazynowego. Programiści mogą izolować zmiany w gałęziach, śledzić ewolucję schematu poprzez commity, współpracować poprzez pull requesty oraz synchronizować aktualizacje między repozytoriami Git a przestrzeniami roboczymi Fabric.

Typowe scenariusze obejmują:

  • Bezpieczne tworzenie zmian schematu w gałęziach i przestrzeniach roboczych
  • Wersjonowanie obiektów magazynowych w Git
  • Współpraca w wielu oddziałach i przestrzeniach roboczych
  • Promowanie zweryfikowanych zmian między gałęziami
  • Utrzymanie zgodności elementów w przestrzeni roboczej (magazyn i inne) ze źródłem prawdy w Git

Aby zachować spójność, możliwość śledzenia i niezawodność w cyklu rozwoju magazynu, musisz rozumieć te procesy pracy.

Schemat cyklu rozwoju integracji integracji z Gitem w Fabric Warehouse.

Gdy podłączasz Fabric Data Warehouse workspace do Gita, zatwierdzasz definicje magazynu jako projekt bazy danych. Projekt ten staje się autorytatywnym odzwierciedleniem schematu magazynu w kontroli źródeł i stanowi podstawę dla bieżących działań rozwojowych. W eksploratorze kontroli wersji schemat pojawia się jako pojedyncze .sql pliki.

Zrzut ekranu schematu magazynu w eksploratorze kontroli wersji.

Korzystając z integracji i Fabric Data Warehouse Fabric Git, możesz:

Porównanie

Podczas tego procesu synchronizacji Fabric wykorzystuje inkrementalne wdrożenie schematu opartego na DacFx do wprowadzania zmian. To podejście stosuje tylko istotne różnice schematu do magazynu, zamiast aktualizować całą definicję magazynu.

Ekstrakcja inkrementalna pomaga ograniczyć niepotrzebne zmiany w kontroli źródeł, utrzymać czystsze różnice w schematach między gałęziami oraz wspierać efektywne procesy rozgałęziania i fuzji. Ponieważ proces ekstrakcji jest świadomy schematu, umożliwia również niezawodne porównanie i walidację między stanem przestrzeni roboczej a definicjami śledzonymi przez Git.

Standaryzacja sposobu wyodrębniania i przechowywania schematów magazynowych poprawia spójność w różnych środowiskach programistycznych. Definicje schematów pozostają stabilne w różnych gałęziach, różnice lepiej odzwierciedlają celowe zmiany w rozwoju, a kontrola wersji źródłowej staje się niezawodnym punktem odniesienia dla wdrożeń, współpracy i zarządzania cyklem życia.

Sam XMLA.json plik jest wyłączany podczas procesów integracji z Gitem. Fabric wyklucza ten plik z commitów i aktualizacji, więc domyślne metadane semantyczne model nie są przypadkowo przechowywane w Gicie. Podczas synchronizacji przestrzeni roboczej z Gitem jest to XMLA.json ignorowane, co pomaga uniknąć konfliktów, niezamierzonych nadpisów i szumów podczas przełączania gałęzi lub aktualizacji z Gita.

Ograniczenia kontroli źródła

Funkcje bezpieczeństwa SQL, takie jak uprawnienia, wymagają oddzielnego podejścia eksportu i migracji.

  • Zależności między elementami między magazynami a endpointami analityki SQL nie są obecnie wspierane w procesach programistycznych. W rezultacie scenariusze oparte na skoordynowanych zmianach w tych elementach mogą nie działać wiarygodnie.

  • Selektywne commity na poziomie magazynu nie są obecnie wspierane. Zmiany są dokonywane na poziomie przedmiotów magazynowych, a nie na bardziej szczegółowych poziomach obiektów.

  • Wsparcie dla kontroli wersji dla punktów końcowych analityki SQL nie jest obecnie dostępne. To ograniczenie może ograniczać zarządzanie cyklem życia od początku do końca, gdy rozwiązania obejmują zarówno magazyny, jak i punkty końcowe analityki SQL.

Ograniczenia integracji z usługą Git

  • Gdy dwa lub więcej elementów magazynowych odnosi się do siebie, tworzą one cykliczne zależności. System wykrywa to odniesienie kołowe podczas operacji synchronizacji między rozgałęzieniem lub Git-to-workspace, co powoduje ich niepowodzenie. Unikaj cyklicznych zależności między elementami.
  • Obecnie nie twórz przepływu danych Gen2 z miejscem docelowym danych wyjściowych w magazynie. Nowy element o nazwie DataflowsStagingWarehouse pojawia się w repozytorium i blokuje zatwierdzanie i aktualizowanie z usługi Git.
  • Zależności między elementami, sekwencjonowanie elementów i przerwy synchronizacji między punktem końcowym analizy SQL i magazynem wpływają na "rozgałęzianie do nowego lub istniejącego obszaru roboczego" i "przełączanie się do innej gałęzi" przepływów pracy podczas opracowywania i ciągłej integracji.
  • Jeśli obiekt odwołuje się do innego obiektu w tym samym magazynie za pomocą trzyczęściowego nazewnictwa (database.schema.object), zatwierdzenie lub aktualizacja z Gita może zakończyć się niepowodzeniem. Więcej informacji i obejście znajdziesz w artykule Odniesienia do obiektów magazynu z użyciem trzyczęściowej nazwy.
  • Jeśli zmienisz kolumnę, która została IDENTITY zdefiniowana, zatwierdzenie lub aktualizacja z Gita może zawiódć, dopóki IDENTITY_INSERT nie zostanie włączone dla tabeli.
  • Jeśli repozytorium zawiera plik, .sqlproj który przypina starszą Microsoft.Build.Sql wersję SDK, zatwierdzenie lub aktualizacja z Gita może zawiódć, ponieważ starsze SDK nie rozpoznaje nowszej składni magazynowej, takiej jak IDENTITY kolumny i CLUSTER BY. Więcej informacji i obejście znajdziesz w Out-of-date .sqlproj w repozytorium Gita.
  • Jeśli obiekt odwołuje się do dwóch lub więcej tabel w innym magazynie, nie kwalifikując każdej kolumny aliasem, zatwierdzenie lub aktualizacja z Gita może się nie powieść. Więcej informacji i obejście można znaleźć w artykule Kolumny niekwalifikowane w obiektach, które odnoszą się do dwóch lub więcej tabel w innym magazynie.
  • Jeśli twoje skrypty odwołują się do dwóch lub więcej różnych obiektów w tym samym schemacie innego magazynu i zapisują nazwę schematu z niespójną wielką literą, zatwierdzenie lub aktualizacja z Gita może się nie powieść. Więcej informacji i obejście można znaleźć w artykule Niespójna wielka litera nazw schematów.
  • Niejednoznaczne błędy kolumn, których lista kandydatów zawiera separator, :: mogą wystąpić podczas zatwierdzania lub aktualizacji z Gita, nawet gdy nie ma rzeczywistej niejednoznaczności. Więcej informacji i obejść zobacz: Niejednoznaczne błędy kolumn z duplikatami obiektów kandydatów.

Niewspierane scenariusze

Następujące przepływy pracy ciągłej integracji/ciągłego wdrażania nie są oficjalnie obsługiwane, gdy magazyny w różnych obszarach roboczych mają różne sortowania. Mimo że te operacje mogą zakończyć się powodzeniem bez błędów, mogą powodować błędy metadanych.

We wszystkich tych scenariuszach, jeśli wystąpi niezgodność sortowania, użyj skryptu Python scripts/dw-collation-error-update-tmsl/pbi_interactive.py z repozytorium GitHub w przyborniku Fabric, aby zaktualizować sortowanie zestawu danych (TMSL), aby pasowało do sortowania hurtowni.

Scenario Description Ryzyko
Pipeline do wdrożenia Promowanie zawartości magazynu przez etapy potoku (na przykład Dev → Test → Prod), w których docelowy magazyn został utworzony z innym porządkowaniem niż magazyn źródłowy, nie jest obsługiwane. Wdrożenie może zakończyć się pomyślnie, ale porządkowanie zbioru danych nie będzie zaktualizowane tak, aby pasowało do porządkowania docelowego magazynu.
Rozgałęzianie do nowego lub istniejącego obszaru roboczego Używanie integracji z usługą Git do rozgałęziania z istniejącego obszaru roboczego do nowego lub istniejącego obszaru roboczego, w którym magazyn ma inne sortowanie, nie jest obsługiwane. Zawartość magazynu jest synchronizowana, ale metadane sortowania nie są uzgadniane.
Przełączanie gałęzi w obszarze roboczym Przełączanie się do gałęzi powiązanej z magazynem o innym porządku sortowania w obszarze roboczym połączonym z Git nie jest obsługiwane. Zsynchronizowana zawartość może zachowywać założenia dotyczące sortowania, które nie są zgodne z bieżącym magazynem.
Scalanie zmian między obszarami roboczymi za pomocą gałęzi Scalanie gałęzi Git między obszarami roboczymi, gdzie repozytoria mają różne porządkowanie, nie jest obsługiwane. Scalanie może zakończyć się powodzeniem na poziomie usługi Git, ale wynikowe sortowanie zestawu danych nie odzwierciedla sortowania magazynu docelowego.

Następny krok

Korzystaj z integracji z Git do tworzenia i wdrażania magazynu

Treści powiązane

  • Last updated on