Zarządzanie gałęziami w obszarach roboczych usługi Microsoft Fabric
Celem tego artykułu jest przedstawienie deweloperom sieci szkieletowej różnych opcji tworzenia procesów ciągłej integracji/ciągłego wdrażania w sieci szkieletowej w oparciu o typowe scenariusze klientów. Ten artykuł koncentruje się bardziej na ciągłej integracji (CI) części procesu ciągłej integracji/ciągłego wdrażania. Aby zapoznać się z omówieniem części ciągłego dostarczania (CD), zobacz Zarządzanie potokami wdrażania.
W tym artykule opisano kilka odrębnych opcji integracji, ale wiele organizacji używa ich kombinacji.
Wymagania wstępne
Aby zintegrować usługę Git z obszarem roboczym usługi Microsoft Fabric, należy skonfigurować następujące wymagania wstępne dla usługi Fabric i Git.
Wymagania wstępne dotyczące sieci szkieletowej
Aby uzyskać dostęp do funkcji integracji z Git, musisz mieć pojemność Fabric. Pojemność sieci szkieletowej jest wymagana do korzystania ze wszystkich obsługiwanych elementów sieci szkieletowej. Jeśli jeszcze go nie masz, utwórz konto bezpłatnej wersji próbnej. Klienci, którzy mają już pojemność usługi Power BI Premium, mogą z niej korzystać, ale pamiętaj, że niektóre jednostki SKU usługi Power BI obsługują wyłącznie elementy usługi Power BI.
Ponadto następujące przełączniki dzierżawy muszą być włączone w portalu administracyjnym:
- Użytkownicy mogą tworzyć elementy sieci szkieletowej
- Użytkownicy mogą synchronizować elementy obszaru roboczego z repozytoriami Git
- Tylko dla użytkowników usługi GitHub: użytkownicy mogą synchronizować elementy obszaru roboczego z repozytoriami GitHub
Te przełączniki mogą być włączone przez administratora dzierżawy, administratora pojemności lub administratora obszaru roboczego, w zależności od ustawień organizacji.
Wymagania wstępne usługi Git
Integracja z usługą Git jest obecnie obsługiwana w przypadku usług Azure DevOps i GitHub. Do korzystania z integracji usługi Git z obszarem roboczym usługi Fabric potrzebne są następujące elementy w usłudze Azure DevOps lub GitHub:
- Aktywne konto platformy Azure zarejestrowane dla tego samego użytkownika, który korzysta z obszaru roboczego Sieć szkieletowa. Utwórz bezpłatne konto.
- Dostęp do istniejącego repozytorium.
Proces programowania
Obszar roboczy Sieć szkieletowa to środowisko udostępnione, które uzyskuje dostęp do elementów na żywo. Wszelkie zmiany wprowadzone bezpośrednio w obszarze roboczym zastępują i wpływają na wszystkich innych użytkowników obszaru roboczego. W związku z tym najlepszym rozwiązaniem usługi Git jest praca deweloperów w izolacji poza udostępnionymi obszarami roboczymi. Istnieją dwa sposoby pracy dewelopera we własnym chronionym obszarze roboczym.
- Programowanie przy użyciu narzędzi klienckich, takich jak program Power BI Desktop na potrzeby raportów i modeli semantycznych, lub programu VS Code for Notebooks.
- Programowanie w osobnym obszarze roboczym sieci szkieletowej. Każdy deweloper ma własny obszar roboczy, w którym łączy własną oddzielną gałąź, synchronizuje zawartość z tym obszarem roboczym, a następnie zatwierdza z powrotem do gałęzi.
Aby pracować z gałęziami przy użyciu integracji z usługą Git, najpierw połącz obszar roboczy udostępnionego zespołu deweloperów z pojedynczą udostępnioną gałęzią. Jeśli na przykład zespół korzysta z jednego udostępnionego obszaru roboczego, połącz go z gałęzią główną w repozytorium zespołu i zsynchronizuj między obszarem roboczym a repozytorium. Jeśli przepływ pracy twojego zespołu ma wiele współużytkowanych gałęzi, takich jak tworzenie/testowanie/prod , każda gałąź może być połączona z innym obszarem roboczym.
Następnie każdy deweloper może wybrać izolowane środowisko, w którym ma działać.
Scenariusz 1 — programowanie przy użyciu narzędzi klienckich
Jeśli opracowywane elementy są dostępne w innych narzędziach, możesz pracować nad tymi elementami bezpośrednio w narzędziu klienckim. Nie wszystkie elementy są dostępne w każdym narzędziu. Elementy, które są dostępne tylko w sieci szkieletowej, muszą być opracowywane w sieci szkieletowej.
Przepływ pracy dla deweloperów korzystających z narzędzia klienckiego, takiego jak program Power BI Desktop, powinien wyglądać mniej więcej tak:
Sklonuj repozytorium do komputera lokalnego. (Ten krok należy wykonać tylko raz).
Otwórz projekt w programie Power BI Desktop przy użyciu lokalnej kopii pliku PBIProj.
Wprowadź zmiany i zapisz zaktualizowane pliki lokalnie. Zatwierdź repozytorium lokalne.
Gdy wszystko będzie gotowe, wypchnij gałąź i zatwierdzeń do repozytorium zdalnego.
Przetestuj zmiany względem innych elementów lub większej liczby danych, łącząc nową gałąź z oddzielnym obszarem roboczym, a następnie przekazując semantyczny model i raporty przy użyciu przycisku aktualizuj wszystkie w panelu sterowania źródła. Przed scaleniem z gałęzią główną wykonaj wszystkie testy lub zmiany konfiguracji.
Jeśli w obszarze roboczym nie są wymagane żadne testy, deweloper może scalić zmiany bezpośrednio z gałęzią główną bez konieczności korzystania z innego obszaru roboczego.
Po scaleniu zmian zostanie wyświetlony monit o zaakceptowanie nowego zatwierdzenia przez udostępniony zespół. Zmiany są aktualizowane w udostępnionym obszarze roboczym, a wszyscy mogą zobaczyć zmiany w tych semantycznych modelach i raportach.
Aby uzyskać szczegółowe wskazówki dotyczące używania nowego formatu pliku programu Power BI Desktop w usłudze Git, zobacz Format kodu źródłowego.
Scenariusz 2 . Programowanie przy użyciu innego obszaru roboczego
W przypadku dewelopera, który pracuje w Internecie, przepływ będzie następujący:
Na karcie Gałęzie menu Kontrolka źródła wybierz pozycję Rozgałęź do nowego obszaru roboczego.
Określ nazwy gałęzi i obszaru roboczego. Nowa gałąź utworzona na podstawie gałęzi połączonej z bieżącym obszarem roboczym.
Wybierz pozycję Rozgałęzij.
Sieć szkieletowa tworzy nowy obszar roboczy i gałąź. Zostanie automatycznie przeniesiony do nowego obszaru roboczego.
Obszar roboczy jest synchronizowany z gałęzią funkcji i staje się izolowanym środowiskiem do pracy, jak pokazano na ilustracji. Teraz możesz pracować w tym nowym izolowanym środowisku. Synchronizacja może potrwać kilka minut. Zobacz porady dotyczące rozwiązywania problemów, aby uzyskać więcej informacji na temat rozgałęziania.
Zapisz zmiany i zatwierdź je w gałęzi funkcji.
Gdy wszystko będzie gotowe, utwórz żądanie ściągnięcia do gałęzi głównej. Procesy przeglądu i scalania są wykonywane za pośrednictwem usługi Azure Repos na podstawie konfiguracji zdefiniowanej przez zespół dla tego repozytorium.
Po zakończeniu przeglądu i scalania zostanie utworzone nowe zatwierdzenie w gałęzi głównej. To zatwierdzenie monituje użytkownika o zaktualizowanie zawartości w obszarze roboczym zespołu deweloperów za pomocą scalonych zmian.
Aby uzyskać więcej informacji, zobacz rozgałęzianie ograniczeń .
Proces wydawania
Proces wydania rozpoczyna się, gdy nowe aktualizacje zakończą proces żądania ściągnięcia i scalą je z udostępnioną gałęzią zespołu (na przykład Main, Dev itp.). Od tego momentu przedstawimy różne opcje tworzenia procesu wydania w sieci szkieletowej. Różne zagadnienia dotyczące procesu wydania można znaleźć w temacie Zarządzanie potokami wdrażania.
Przełączanie gałęzi
Jeśli obszar roboczy jest połączony z gałęzią Git i chcesz przełączyć się do innej gałęzi, możesz to zrobić szybko w okienku kontroli źródła bez odłączania i ponownego łączenia.
Podczas przełączania gałęzi obszar roboczy jest synchronizowany z nową gałęzią, a wszystkie elementy w obszarze roboczym są zastępowane. Jeśli w każdej gałęzi istnieją różne wersje tego samego elementu, element zostanie zastąpiony. Jeśli element znajduje się w starej gałęzi, ale nie w nowej gałęzi, zostanie usunięty.
Aby przełączyć się między gałęziami, wykonaj następujące kroki:
Na karcie Gałęzie w menu Kontrolkaźródła wybierz pozycję Przełącz gałąź.
Określ gałąź, z którą chcesz nawiązać połączenie, lub utwórz nową gałąź. Ta gałąź musi zawierać ten sam katalog co gałąź bieżąca.
Wybierz pozycję Przełącz gałąź.
Nie można przełączać gałęzi, jeśli masz jakiekolwiek niezatwierdzone zmiany w obszarze roboczym. Wybierz pozycję Anuluj , aby wrócić i zatwierdzić zmiany przed przełączeniem gałęzi.
Aby połączyć bieżący obszar roboczy z nową gałęzią przy zachowaniu stanu istniejącego obszaru roboczego, wybierz pozycję Wyewidencjonuj nową gałąź. Dowiedz się więcej o wyewidencjonowaniu nowej gałęzi w temacie Rozwiązywanie konfliktów w usłudze Git.