Integracja z Git na potrzeby tworzenia magazynu 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 usługą Git w środowisku Fabric zespoły mogą stosować nowoczesne praktyki kontroli wersji podczas tworzenia magazynu danych. 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 życia tworzenia integracji z Git 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 źródła schemat jest wyświetlany jako oddzielne pliki .sql.

Zrzut ekranu schematu magazynu w eksploratorze kontroli wersji.

Korzystając z funkcji Fabric Git Integration oraz Fabric Data Warehouse, 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 obszaru roboczego z usługi Git element XMLA.json jest ignorowany, co pomaga uniknąć konfliktów, niezamierzonego nadpisywania i zbędnych zmian podczas przełączania gałęzi lub aktualizacji z usługi Git.

Ograniczenia kontroli źródła

  • Funkcje bezpieczeństwa SQL, takie jak uprawnienia, wymagają podejścia skryptowego do eksportu i migracji. Rozważ użycie skryptu po wdrożeniu w projekcie bazy danych SQL. Możesz skonfigurować skrypt po wdrożeniu w projekcie za pomocą rozszerzenia SQL Database Projects dostępnego w Visual Studio Code.

  • Zależności między elementami w magazynach danych i punktach końcowych analizy SQL nie są obecnie obsługiwane w przepływach pracy deweloperskiej. W rezultacie scenariusze oparte na skoordynowanych zmianach w tych elementach mogą nie działać wiarygodnie.

  • Skrypty przed wdrożeniem lub po wdrożeniu oraz dodatkowe konfiguracje publikowania dodawane bezpośrednio do projektu bazy danych za pośrednictwem Gita nie są zachowywane jako część workflow deweloperskich. Możesz potrzebować zarządzać tymi konfiguracjami osobno poza przestrzenią roboczą Fabric.

  • Selektywne zatwierdzenia na poziomie magazynu nie są obecnie obsługiwane. 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 odwołanie cykliczne podczas operacji wyodrębniania gałęzi lub synchronizacji z repozytorium Git do obszaru roboczego, co powoduje, że operacje te kończą się niepowodzeniem. 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. Aby uzyskać więcej informacji i poznać obejście problemu, zobacz Nieaktualny plik .sqlproj w repozytorium Git.
  • 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 skrypty odwołują się do co najmniej dwóch różnych obiektów w tym samym schemacie innego magazynu danych, a nazwa schematu jest w nich zapisywana z niespójnym użyciem wielkich i małych liter, zatwierdzanie zmian lub aktualizowanie z repozytorium Git może się nie powieść. Więcej informacji i obejście można znaleźć w artykule Niespójna wielka litera nazw schematów.
  • Błędy dotyczące niejednoznacznych kolumn, których lista kandydatów zawiera separator ::, mogą występować podczas zatwierdzania zmian lub aktualizowania z repozytorium Git, nawet jeśli w rzeczywistości nie ma żadnej niejednoznaczności. Więcej informacji i obejścia problemu można znaleźć w artykule Błędy niejednoznaczności kolumn związane ze zduplikowanymi obiektami kandydującymi.

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

  • Ostatnia aktualizacja o