Kontrola wersji, CI/CD i ALM dla agenta danych Fabric (wersja zapoznawcza)

W tym artykule opisano sposób zarządzania agentami danych Fabric przy użyciu integracji z Git i potoków wdrażania jako część możliwości zarządzania cyklem życia aplikacji (ALM) usługi Microsoft Fabric. Dowiesz się, jak połączyć obszar roboczy z repozytorium Git. Dowiesz się również, jak śledzić oraz wersjonować konfiguracje agenta danych. Na koniec dowiesz się, jak promować aktualizacje w środowiskach deweloperskich, testowych i produkcyjnych. Potoki Git do integracji i wdrażania umożliwiają ciągłą integrację i ciągłe wdrażanie (CI/CD) zmian agenta danych, co umożliwia testowanie i automatyczne promowanie aktualizacji w ramach przepływu pracy ALM. Kontrola źródła dla agentów danych Fabric jest obecnie dostępna w wersji zapoznawczej.

Możesz użyć dwóch uzupełniających podejść do wsparcia ALM dla agentów danych platformy Fabric.

• Integracja z usługą Git: zsynchronizuj cały obszar roboczy z repozytorium Git (azure DevOps lub GitHub jako dostawca usługi Git), aby umożliwić kontrolę wersji, współpracę za pośrednictwem gałęzi i śledzenie historii dla poszczególnych elementów, w tym agentów danych sieci szkieletowej.
• Potoki wdrażania: podwyższanie poziomu zawartości między oddzielnymi obszarami roboczymi reprezentującymi etapy programowania, testowania i produkcji przy użyciu wbudowanych potoków.

Te możliwości razem zapewniają kompleksową obsługę ALM dla agentów danych Fabric.

Ważne

Ta funkcja jest dostępna w wersji zapoznawczej.

Wymagania wstępne

• Płatna pojemność Fabric F2 lub wyższa albo usługa Power BI Premium w trybie per capacity (P1 lub wyższa) z włączoną usługą Microsoft Fabric
• Ustawienia dzierżawcy agenta danych fabric są włączone.
• Włączono przetwarzanie międzygeograficzne dla sztucznej inteligencji.
• włączono przechowywanie międzyregionalne dla sztucznej inteligencji.
• Co najmniej jeden z nich, z danymi: magazynem, usługą lakehouse, co najmniej jednym semantycznym modelem usługi Power BI, bazą danych KQL lub ontologią.
• Modele semantyczne Power BI za pośrednictwem przełącznika dzierżawy punktów końcowych XMLA są włączone dla źródeł danych semantycznego modelu Power BI.

Integracja z Git

Integracja z usługą Microsoft Fabric Git synchronizuje obszar roboczy usługi Fabric z repozytorium Git, umożliwiając korzystanie z istniejących procesów programowania, narzędzi i najlepszych rozwiązań bezpośrednio na platformie Fabric. Obsługuje ona usługi Azure DevOps i GitHub i jest dostępna na poziomie obszaru roboczego. Gdy zatwierdzasz zmiany z Fabric, w tym aktualizację konfiguracji agenta danych, te zmiany są zapisywane jako pliki w połączonym repozytorium Git. Jego kluczowe możliwości obejmują:

• Pełna kopia zapasowa i kontrola wersji elementów obszaru roboczego
• Struktura folderów w usłudze Git odzwierciedla strukturę obszaru roboczego
• Konfiguracje agenta danych (wybór schematu, instrukcje dotyczące sztucznej inteligencji, instrukcje dotyczące źródła danych, przykładowe zapytania) są przechowywane w plikach strukturalnych w dedykowanych folderach
• Możliwość wyświetlania różnic, przeglądania historii i przywracania poprzednich stanów za pośrednictwem historii dla różnych elementów obszaru roboczego, w tym agentów danych
• Współpraca oparta na gałęziach (gałęzie funkcjonalne, główna)

Aby uzyskać więcej informacji na temat procesu integracji z usługą Git, zapoznaj się z następującymi zasobami.

• Co to jest integracja z usługą Microsoft Fabric Git?
• Podstawowe pojęcia dotyczące integracji z usługą Git
• Wprowadzenie do integracji z usługą Git

Konfigurowanie połączenia z kontrolą źródła

Obszar roboczy usługi Fabric można połączyć z repozytorium Git na stronie Ustawienia obszaru roboczego . To połączenie umożliwia zatwierdzanie i synchronizowanie zmian bezpośrednio z Fabric.

1. Aby uzyskać szczegółowe instrukcje dotyczące nawiązywania połączenia z repozytorium Git w usłudze Azure DevOps lub GitHub, zobacz Wprowadzenie do integracji z usługą Git .

2. Po nawiązaniu połączenia z repozytorium Git, elementy obszaru roboczego, w tym agenci danych Fabric, są wyświetlane w panelu kontroli źródła. Na pasku stanu w lewym dolnym rogu widać nazwę połączonej gałęzi, czas ostatniej synchronizacji i identyfikator zatwierdzenia usługi Git.

3. Połączone repozytorium Git wyświetla strukturę folderów, które reprezentują elementy obszaru roboczego, w tym agenty danych Fabric i ich pliki konfiguracyjne. Każdy agent danych jest przechowywany we własnym folderze, co umożliwia przeglądanie zmian, śledzenie historii zmian oraz korzystanie z przepływów pracy Git, takich jak tworzenie pull requestów, aby scalić aktualizacje z gałęzią główną.

4. Po wprowadzeniu modyfikacji do agenta danych Fabric w obszarze roboczym połączonym z usługą Git, zmiany są wykrywane, a stan agenta danych w panelu kontroli wersji zmienia się na Niezatwierdzone zmiany. Te modyfikacje mogą obejmować:

   • Zmiana wyboru schematu.
   • Aktualizowanie instrukcji dotyczących sztucznej inteligencji lub instrukcji dotyczących źródła danych.
   • Edytowanie przykładowych zapytań.
   • Publikowanie agenta danych lub aktualizowanie jego opisu wydawniczego.

Każda zmiana — niezależnie od tego, czy funkcjonalna, czy opisowa — powoduje, że agent danych nie jest zsynchronizowany z połączonym repozytorium Git. Elementy obszaru roboczego ze zmianami zostaną wyświetlone na karcie Zmiany w okienku kontrola źródła. Możesz przejrzeć te zmiany, porównać je z zatwierdzoną wersją i zatwierdzić je z powrotem do repozytorium Git w celu zsynchronizowania.

5. Gdy aktualizacje są wprowadzane bezpośrednio w połączonym repozytorium Git (Azure DevOps lub GitHub), mogą zawierać akcje, takie jak modyfikowanie instrukcji sztucznej inteligencji, zmienianie przykładowych zapytań lub edytowanie opisów publikowania. Następnie możesz zatwierdzić i wypchnąć te zmiany do repozytorium. Po wypchnięciu i udostępnieniu aktualizacji w repozytorium, obszar roboczy Fabric wykryje je i wyświetli powiadomienie Aktualizacje dostępne w okienku Kontrola wersji. Zaktualizowane elementy, takie jak agent danych, są wyświetlane na karcie Aktualizacje, gdzie można je przejrzeć i zaakceptować. Zaakceptowanie tych aktualizacji stosuje zmiany repozytorium do elementów obszaru roboczego, zapewniając, że obszar roboczy odzwierciedla najnowszą wersję zatwierdzoną w Git.

Struktura folderów i plików w repozytorium Git

Poniżej przedstawiono strukturę sposobu przechowywania konfiguracji agenta danych w repozytorium Git. Zrozumienie tej struktury jest ważne w przypadku zarządzania zmianami i przestrzegania najlepszych rozwiązań.

Struktura główna

W katalogu głównym zawartość agenta danych jest przechowywana w folderze files . W plikach znajduje się folder konfiguracji, który zawiera data_agent.json, publish_info.json, folder roboczy i folder opublikowany.

W folderze config, plik publish_info.json zawiera opis publikowania agenta danych. Ten plik można zaktualizować, aby zmienić opis wyświetlany podczas publikowania agenta danych.

Folder roboczy zawiera pliki konfiguracji odpowiadające wersji roboczej agenta danych, a opublikowany folder zawiera pliki konfiguracji opublikowanej wersji agenta danych. Folder roboczy zawiera:

• Foldery źródła danych , w których istnieje jeden folder dla każdego źródła danych używanego przez agenta danych.
  • Źródła danych dotyczące lakehouse lub warehouse: nazwy folderów zaczynają się od lakehouse-tables- lub warehouse-tables-, a następnie nazwą lakehouse lub warehouse.
  • Semantyczne źródła danych modelu: nazwy folderów zaczynają się od semantic-model-, a następnie nazwę modelu semantycznego.
  • Źródła danych bazy danych KQL: nazwy folderów zaczynają się od kusto-, a następnie nazwę bazy danych KQL.
  • Źródła danych ontologii: nazwy folderów zaczynają się od ontology-, a następnie nazwę ontologii.

• stage_config.json zawiera aiInstructions, który odwołuje się do instrukcji agenta.

Każdy folder źródła danych zawiera datasource.json i fewshots.json. Jeśli jednak źródło danych jest modelem semantycznym, nie obsługuje przykładowych zapytań, więc jego folder zawiera tylko datasource.json.

datasource.jsondefiniuje konfigurację dla tego źródła danych, w tym:

• dataSourceInstructions, który reprezentuje instrukcje podane dla tego źródła danych.

• displayName, który pokazuje nazwę źródła danych.

• elements, który odwołuje się do mapy schematu i zawiera pełną listę tabel i kolumn ze źródła danych.

  • Każda tabela ma is_selected właściwość . Jeśli true, tabela jest uwzględniona, a jeśli false, oznacza to, że tabela nie jest zaznaczona i nie będzie używana przez agenta danych.
  • Wpisy kolumn również pokazują is_selected, ale wybór w obrębie kolumny nie jest obecnie obsługiwany. Jeśli wybrano tabelę, wszystkie jej kolumny są uwzględniane niezależnie od wartości kolumny is_selected . Jeśli tabela nie jest zaznaczona (is_selected: false na poziomie tabeli), to żadna z kolumn nie jest brana pod uwagę, mimo że is_selected jest ustawione na true na poziomie kolumny.

• Konwencje typów:

  • Jeśli typ jest źródłem danych, jest to po prostu typ źródła danych (na przykład: "type": "lakehouse_tables").
  • Jeśli typ jest tabelą, kończy się .table (na przykład:"type": "lakehouse_tables.table").
  • Jeśli typ jest kolumną, kończy się .column (na przykład: "type": "lakehouse_tables.column").

W fewshots.json są przechowywane przykładowe zapytania dotyczące źródła danych. Każdy wpis obejmuje:

• id jako unikatowy identyfikator przykładowego zapytania.
• question, który odnosi się do pytania języka naturalnego.
• query Wyświetla tekst zapytania, który może być SQL lub KQL w zależności od typu źródła danych.

Folder opublikowany odzwierciedla strukturę folderu roboczego, ale reprezentuje opublikowaną wersję agenta danych. Najlepszym rozwiązaniem jest brak bezpośredniego modyfikowania plików w opublikowanym folderze. Zmiany powinny zostać wprowadzone w folderze roboczym. Po opublikowaniu agenta danych te zmiany zostaną odzwierciedlone w opublikowanym folderze. Gwarantuje to, że opublikowana wersja jest zawsze generowana na podstawie kontrolowanego stanu wersji roboczej.

Potoki wdrażania dla agentów danych

Ścieżki wdrażania zapewniają kontrolowany sposób przenoszenia agentów danych między obszarami roboczymi, mapowanych na różne etapy cyklu życia. Przykład:

1. Utwórz nowego agenta danych lub zaktualizuj istniejący w obszarze roboczym programowania.
2. Podwyższ poziom zmian w obszarze roboczym testowym na potrzeby walidacji.
3. Wdrożenie przetestowanych zmian do środowiska produkcyjnego, aby były dostępne dla użytkowników końcowych.

Przed wdrożeniem należy przypisać obszar roboczy do każdego etapu w potoku wdrażania: programowanie, testowanie i produkcja. Jeśli nie przypiszesz obszaru roboczego do etapu testowego lub produkcyjnego, obszary robocze zostaną utworzone automatycznie. Automatycznie utworzone obszary robocze mają nazwę po obszarze roboczym programowania z dołączonym ciągiem [test] lub [prod].

Aby wdrożyć zmiany:

• W pipeline przejdź do etapu, z którego chcesz wdrożyć (na przykład rozwój).
• Wybierz elementy w obszarze roboczym, który chcesz wdrożyć.
• Wybierz pozycję Wdróż, aby podwyższyć poziom ich do następnego etapu.

Przed zastosowaniem zmian można przejrzeć plan wdrożenia, upewniając się, że promowane są tylko zamierzone aktualizacje. Aby uzyskać więcej informacji, zobacz Rozpocznij pracę z potokami wdrażania.

Uwaga / Notatka

Jednostki usługi są obsługiwane w agencie danych Fabric tylko w ramach scenariuszy ALM. Ta obsługa jest ograniczona do włączania operacji ALM (takich jak integracja z Git i potoki wdrażania) i nie jest rozszerzana na inne funkcje agenta danych Fabric. Jeśli musisz wchodzić w interakcje z agentem danych poza przepływami pracy ALM, jednostka usługi nie jest obsługiwana.

Publikowanie agenta danych Fabric dla potoków wdrożeniowych

Publikowanie agenta danych Fabric udostępnia go do użycia we wszystkich różnych kanałach dystrybucji, w tym Copilot dla Power BI, Microsoft Copilot Studio i Azure AI Foundry Services. Aby ocenić i korzystać z agenta danych w tych kanałach, należy opublikować agenta danych; nieopublikowani agenci danych nie są dostępni do użycia, nawet jeśli znajdują się w obszarze roboczym produkcyjnym. Aby postępować zgodnie z najlepszymi rozwiązaniami zgodnie z potokiem wdrażania, należy pamiętać, że:

• Publikowanie z obszaru roboczego programowania powinno być ograniczone tylko do autoryzowanych użytkowników, którzy pracują nad opracowywaniem agenta danych i chcą ocenić jego wydajność w różnych kanałach zużycia. Dostęp do tego obszaru roboczego musi być ograniczony, aby niedokończoni lub eksperymentalni agenci danych nie są narażeni na szersze grupy odbiorców.
• Użytkownicy końcowi powinni uzyskiwać dostęp do agentów danych publikowanych tylko z obszaru roboczego produkcyjnego, zapewniając interakcję ze stabilnymi, zatwierdzonymi wersjami agenta danych.

Takie podejście spełnia zarówno funkcjonalne wymagania umożliwienia korzystania i oceny wydajności, jak i zapewnia właściwą kontrolę dostępu poprzez oddzielenie środowisk programistycznych i produkcyjnych.

Najlepsze rozwiązania

• Użyj dedykowanej gałęzi do prac programistycznych dotyczących agentów danych i scal je z gałęzią główną po przejrzeniu kodu.
• Zachowaj powiązane zasoby (źródła danych, agenci danych, notesy, potoki) w tym samym obszarze roboczym, aby ułatwić łatwiejszą promocję.
• Przetestuj zmiany agenta danych w środowisku testowym przed wdrożeniem do środowiska produkcyjnego.
• Użyj opisowych komunikatów zatwierdzeń, aby ułatwić zrozumienie historii.
• Nie wprowadzaj bezpośrednio zmian w opublikowanym folderze w repozytorium Git.

Ograniczenia i zagadnienia

• Tylko obszary robocze połączone z repozytorium Git mogą korzystać z funkcji ALM opartych na usłudze Git.
• Podmioty usługi są obsługiwane w agencie danych Fabric tylko w ramach scenariuszy ALM. Jeśli musisz wchodzić w interakcje z agentem danych poza przepływami pracy ALM, jednostka usługi nie jest obsługiwana.
• Potoki wdrażania wymagają, aby źródłowe i docelowe obszary robocze znajdują się w tej samej dzierżawie.
• Duża liczba częstych zatwierdzeń może mieć wpływ na rozmiar i wydajność repozytorium.

Treści powiązane

• Wprowadzenie do integracji z usługą Git
• Podstawowe pojęcia dotyczące integracji z usługą Git
• Co to jest zarządzanie cyklem życia w usłudze Microsoft Fabric?