Najlepsze rozwiązania dotyczące zarządzania cyklem życia
Ten artykuł zawiera wskazówki dla twórców danych i analiz, którzy zarządzają zawartością w całym cyklu życia w usłudze Microsoft Fabric. Artykuł koncentruje się na korzystaniu z integracji z usługą Git na potrzeby potoków kontroli źródła i wdrażania jako narzędzia do wydawania. Aby uzyskać ogólne wskazówki dotyczące publikowania zawartości przedsiębiorstwa, publikowanie zawartości w przedsiębiorstwie.
Ważne
Ta funkcja jest dostępna w wersji zapoznawczej.
Artykuł jest podzielony na cztery sekcje:
Przygotowywanie zawartości — przygotowanie zawartości do zarządzania cyklem życia.
Programowanie — poznaj najlepsze sposoby tworzenia zawartości na etapie programowania potoków wdrażania.
Test — dowiedz się, jak testować środowisko przy użyciu etapu testowania potoków wdrażania.
Produkcja — użyj etapu produkcyjnego potoków wdrażania, aby udostępnić zawartość do użycia.
Przygotowywanie zawartości
Aby jak najlepiej przygotować zawartość do bieżącego zarządzania w całym cyklu życia, przed rozpoczęciem pracy zapoznaj się z informacjami w tej sekcji:
Zwolnij zawartość do środowiska produkcyjnego.
Rozpocznij korzystanie z potoku wdrażania dla określonego obszaru roboczego.
Oddzielanie programowania między zespołami
Różne zespoły w organizacji zwykle mają różne doświadczenie, własność i metody pracy, nawet podczas pracy nad tym samym projektem. Ważne jest, aby ustawić granice, jednocześnie dając każdemu zespołowi niezależność do pracy tak, jak lubią. Rozważ posiadanie oddzielnych obszarów roboczych dla różnych zespołów. W przypadku oddzielnych obszarów roboczych każdy zespół może mieć różne uprawnienia, pracować z różnymi repozytoriami kontroli źródła i dostarczać zawartość do środowiska produkcyjnego w innym środowisku. Większość elementów może łączyć się z danymi w obszarach roboczych i używać ich, więc nie blokuje współpracy na tych samych danych i projektach.
Planowanie modelu uprawnień
Zarówno integracja z usługą Git, jak i potoki wdrażania wymagają różnych uprawnień niż tylko uprawnienia obszaru roboczego. Przeczytaj o wymaganiach dotyczących uprawnień dla potoków integracji i wdrażania usługi Git.
Aby zaimplementować bezpieczny i łatwy przepływ pracy, zaplanuj, kto uzyskuje dostęp do każdej używanej części środowisk, zarówno repozytorium Git, jak i etapy tworzenia i testowania/produ w potoku. Oto niektóre zagadnienia, które należy wziąć pod uwagę:
KtoTo powinien mieć dostęp do kodu źródłowego w repozytorium Git?
Które operacje powinny być wykonywane przez użytkowników z dostępem do potoku na każdym etapie?
KtoTo przeglądanie zawartości na etapie testowania?
Czy recenzenci etapu testowego powinni mieć dostęp do potoku?
KtoTo należy nadzorować wdrażanie na etapie produkcyjnym?
Który obszar roboczy jest przypisywany do potoku lub łączysz się z usługą Git?
Z którą gałęzią łączysz obszar roboczy? Jakie są zasady zdefiniowane dla tej gałęzi?
Czy obszar roboczy jest współużytkowany przez wielu członków zespołu? Czy powinny one wprowadzać zmiany bezpośrednio w obszarze roboczym, czy tylko za pośrednictwem żądań ściągnięcia?
Do którego etapu przypisujesz obszar roboczy?
Czy musisz wprowadzić zmiany w uprawnieniach obszaru roboczego, który przypisujesz?
Połączenie różnych etapów do różnych baz danych
Produkcyjna baza danych powinna zawsze być stabilna i dostępna. Najlepiej nie przeciążać go zapytaniami generowanymi przez twórców analizy biznesowej dla ich modeli programistycznych lub semantycznych testów. Twórz oddzielne bazy danych na potrzeby programowania i testowania w celu ochrony danych produkcyjnych i nie przeciążaj bazy danych deweloperskich całą ilością danych produkcyjnych.
Użyj parametrów dla konfiguracji, które zmienią się między etapami
Jeśli to możliwe, dodaj parametry do dowolnej definicji, która może ulec zmianie między etapami tworzenia i testowania/prod. Użycie parametrów ułatwia zmianę definicji podczas przenoszenia zmian do środowiska produkcyjnego. Mimo że nadal nie ma ujednoliconego sposobu zarządzania parametrami w usłudze Fabric, zalecamy użycie jej w elementach obsługujących dowolny typ parametryzacji.
Parametry mają różne zastosowania, takie jak definiowanie połączeń ze źródłami danych lub elementów wewnętrznych w sieci szkieletowej. Mogą one również służyć do wprowadzania zmian w zapytaniach, filtrach i tekście wyświetlanym użytkownikom.
W potokach wdrażania można skonfigurować reguły parametrów, aby ustawić różne wartości dla każdego etapu wdrażania.
Opracowywanie zawartości
Ta sekcja zawiera wskazówki dotyczące pracy z potokami wdrażania i używania ich do etapu programowania.
Tworzenie kopii zapasowej pracy w repozytorium Git
Dzięki integracji z usługą Git każdy deweloper może wykonać kopię zapasową swojej pracy, zatwierdzając ją w usłudze Git. Aby wykonać kopię zapasową prawidłowo w usłudze Fabric, poniżej przedstawiono kilka podstawowych reguł:
Upewnij się, że masz izolowane środowisko do pracy, aby inne osoby nie przesłaniały pracy przed jej zatwierdzeniu. Oznacza to pracę w narzędziu klasycznym (takim jak VS Code, Power BI Desktop lub inne) lub w osobnym obszarze roboczym, do którego inni użytkownicy nie mogą uzyskać dostępu.
Zatwierdź utworzoną gałąź, a żaden inny deweloper nie używa. Jeśli używasz obszaru roboczego jako środowiska tworzenia, przeczytaj o pracy z gałęziami.
Zatwierdź razem zmiany, które należy wdrożyć razem. Ta porada dotyczy pojedynczego elementu lub wielu elementów powiązanych z tą samą zmianą. Zatwierdzenie wszystkich powiązanych zmian może pomóc później podczas wdrażania na innych etapach, tworzenia żądań ściągnięcia lub przywracania zmian.
Duże zatwierdzenia mogą osiągnąć maksymalny limit rozmiaru zatwierdzenia. Należy pamiętać o liczbie elementów zatwierdzonych razem lub o ogólnym rozmiarze elementu. Na przykład raporty mogą rosnąć duże podczas dodawania dużych obrazów. Dobrym rozwiązaniem jest przechowywanie dużych elementów w systemach kontroli źródła, nawet jeśli działa. Rozważ sposoby zmniejszenia rozmiaru elementów, jeśli mają one wiele zasobów statycznych, takich jak obrazy.
Wycofywanie zmian
Po utworzeniu kopii zapasowej pracy mogą wystąpić przypadki, w których chcesz przywrócić poprzednią wersję i przywrócić ją w obszarze roboczym. Istnieje kilka sposobów przywracania poprzedniej wersji:
Przycisk Cofnij: Operacja Cofnij jest łatwym i szybkim sposobem na przywrócenie wprowadzonych natychmiastowych zmian, o ile nie zostały jeszcze zatwierdzone. Można również cofnąć każdy element oddzielnie. Przeczytaj więcej na temat operacji cofania.
Przywracanie do starszych zatwierdzeń: nie ma bezpośredniego sposobu powrotu do poprzedniego zatwierdzenia w interfejsie użytkownika. Najlepszą opcją jest podwyższenie poziomu starszego zatwierdzenia jako head przy użyciu funkcji przywracania lub resetowania git. Spowoduje to wyświetlenie aktualizacji w okienku kontroli źródła i zaktualizowanie obszaru roboczego przy użyciu tego nowego zatwierdzenia.
Ponieważ dane nie są przechowywane w usłudze Git, należy pamiętać, że przywrócenie elementu danych do starszej wersji może spowodować przerwanie istniejących danych i może być konieczne usunięcie danych lub operacja może zakończyć się niepowodzeniem. Przed przywróceniem zmian sprawdź to z wyprzedzeniem.
Praca z obszarem roboczym "prywatnym"
Jeśli chcesz pracować w izolacji, użyj oddzielnego obszaru roboczego jako izolowanego środowiska. Przeczytaj więcej na temat izolowania środowiska roboczego w pracy z gałęziami. Aby uzyskać optymalny przepływ pracy dla Ciebie i zespołu, należy wziąć pod uwagę następujące kwestie:
Konfigurowanie obszaru roboczego: Przed rozpoczęciem upewnij się, że możesz utworzyć nowy obszar roboczy (jeśli jeszcze go nie masz), możesz przypisać go do pojemności sieci szkieletowej i że masz dostęp do danych do pracy w obszarze roboczym.
Tworzenie nowej gałęzi: utwórz nową gałąź z gałęzi głównej , aby mieć najbardziej aktualną wersję zawartości. Upewnij się również, że łączysz się z prawidłowym folderem w gałęzi, aby można było ściągnąć odpowiednią zawartość do obszaru roboczego.
Małe, częste zmiany: najlepszym rozwiązaniem jest wprowadzenie małych zmian przyrostowych, które są łatwe do scalenia i mniej prawdopodobne, aby wyjść w konflikty. Jeśli to nie jest możliwe, pamiętaj o zaktualizowaniu gałęzi z gałęzi głównej, aby można było rozwiązać konflikty na własną rękę.
Zmiany konfiguracji: w razie potrzeby zmień konfiguracje w obszarze roboczym, aby ułatwić wydajniejszą pracę. Niektóre zmiany mogą obejmować połączenie między elementami lub różnymi źródłami danych lub zmianami parametrów w danym elemencie. Pamiętaj tylko, że wszystkie zatwierdzenia stają się częścią zatwierdzenia i mogą zostać przypadkowo scalone z gałęzią główną.
Edytowanie pracy przy użyciu narzędzi klienckich
W przypadku elementów i narzędzi, które go obsługują, może być łatwiej pracować z narzędziami klienckimi do tworzenia, takimi jak program Power BI Desktop dla semantycznych modeli i raportów, program VSCode dla notesów itp. Te narzędzia mogą być lokalnym środowiskiem projektowym. Po zakończeniu pracy wypchnij zmiany do repozytorium zdalnego i zsynchronizuj obszar roboczy, aby przekazać zmiany. Upewnij się, że pracujesz z obsługiwaną strukturą elementu, który tworzysz. Jeśli nie masz pewności, najpierw sklonuj repozytorium z zawartością już zsynchronizowaną z obszarem roboczym, a następnie rozpocznij tworzenie z tego miejsca, gdzie struktura jest już w miejscu.
Zarządzanie obszarami roboczymi i gałęziami
Ponieważ obszar roboczy można połączyć tylko z pojedynczą gałęzią w danym momencie, zaleca się traktowanie tego jako mapowania 1:1. Jednak aby zmniejszyć ilość obszaru roboczego, który obejmuje, należy wziąć pod uwagę następujące opcje:
Jeśli deweloper skonfiguruje prywatny obszar roboczy ze wszystkimi wymaganymi konfiguracjami, będzie mógł nadal używać tego obszaru roboczego dla każdej utworzonej gałęzi w przyszłości. Gdy przebieg zakończy się, zmiany zostaną scalone i rozpoczniesz nowe zadanie, po prostu przełącz połączenie z nową gałęzią w tym samym obszarze roboczym. Można to również zrobić, jeśli nagle trzeba naprawić usterkę w środku przebiegu. Pomyśl o nim jako katalogu roboczego w Internecie.
Deweloperzy korzystający z narzędzia klienckiego (takiego jak VS Code, Power BI Desktop lub inni) nie muszą potrzebować obszaru roboczego. Mogą tworzyć gałęzie i zatwierdzać zmiany w tej gałęzi lokalnie, wypychać je do repozytorium zdalnego i tworzyć żądanie ściągnięcia do gałęzi głównej, a wszystko to bez obszaru roboczego. Obszar roboczy jest potrzebny tylko jako środowisko testowe, aby sprawdzić, czy wszystko działa w rzeczywistym scenariuszu. To ty decydujesz, kiedy to powinno się zdarzyć.
Duplikowanie elementu w repozytorium Git
Aby zduplikować element w repozytorium Git:
- Skopiuj cały katalog elementów.
- Zmień wartość logicalId na coś unikatowego dla tego połączonego obszaru roboczego.
- Zmień nazwę wyświetlaną, aby odróżnić ją od oryginalnego elementu i uniknąć zduplikowanego błędu nazwy wyświetlanej.
- W razie potrzeby zaktualizuj nazwy logiczne i/lub wyświetlane w dowolnych zależnościach.
Test
Ta sekcja zawiera wskazówki dotyczące pracy z etapem testowania potoków wdrażania.
Symulowanie środowiska produkcyjnego
Ważne jest, aby zobaczyć, jak proponowana zmiana wpłynie na etap produkcji. Etap testowania potoków wdrażania umożliwia symulowanie rzeczywistego środowiska produkcyjnego na potrzeby testowania. Alternatywnie możesz to symulować, łącząc usługę Git z innym obszarem roboczym.
Upewnij się, że te trzy czynniki zostały uwzględnione w środowisku testowym:
Ilość danych
Użycie
Podobna pojemność jak w środowisku produkcyjnym
Podczas testowania można użyć tej samej pojemności co etap produkcyjny. Jednak użycie tej samej pojemności może sprawić, że produkcja będzie niestabilna podczas testowania obciążenia. Aby uniknąć niestabilnej produkcji, przetestuj użycie innej pojemności podobnej w zasobach do pojemności produkcyjnej. Aby uniknąć dodatkowych kosztów, użyj pojemności, w której możesz płacić tylko za czas testowania.
Używanie reguł wdrażania z rzeczywistym źródłem danych
Jeśli używasz etapu testowania do symulowania rzeczywistego użycia danych, najlepiej oddzielić źródła danych programowania i testowania. Baza danych deweloperskich powinna być stosunkowo mała, a testowa baza danych powinna być jak najbardziej podobna do produkcyjnej bazy danych. Użyj reguł źródła danych, aby przełączyć źródła danych na etapie testu lub parametryzować połączenie, jeśli nie działa przez potoki wdrażania.
Sprawdzanie elementów pokrewnych
Wprowadzone zmiany mogą również mieć wpływ na elementy zależne. Podczas testowania sprawdź, czy zmiany nie wpływają na wydajność istniejących elementów, które mogą być zależne od zaktualizowanych elementów.
Powiązane elementy można łatwo znaleźć przy użyciu analizy wpływu.
Aktualizowanie elementów danych
Elementy danych to elementy, które przechowują dane. Definicja elementu w usłudze Git definiuje sposób przechowywania danych. Podczas aktualizowania elementu w obszarze roboczym importujemy jego definicję do obszaru roboczego i stosujemy ją do istniejących danych. Operacja aktualizowania elementów danych jest taka sama w przypadku potoków git i wdrażania.
Ponieważ różne elementy mają różne możliwości, jeśli chodzi o przechowywanie danych podczas stosowania zmian w definicji, należy pamiętać o zastosowaniu zmian. Niektóre rozwiązania, które mogą pomóc w zastosowaniu zmian w najbezpieczniejszy sposób:
Dowiedz się z wyprzedzeniem, jakie są zmiany i jaki może mieć ich wpływ na istniejące dane. Użyj komunikatów zatwierdzenia, aby opisać wprowadzone zmiany.
Aby zobaczyć, jak ten element obsługuje zmianę przy użyciu danych testowych, przekaż zmiany najpierw do środowiska deweloperskiego lub testowego.
Jeśli wszystko pójdzie dobrze, zaleca się również sprawdzenie go w środowisku przejściowym z danymi rzeczywistymi (lub jak najbardziej zbliżonymi do niego), aby zminimalizować nieoczekiwane zachowania w środowisku produkcyjnym.
Rozważ najlepszy czas podczas aktualizowania środowiska Prod, aby zminimalizować szkody, które mogą spowodować wszelkie błędy dla użytkowników biznesowych korzystających z danych.
Po wdrożeniu testy po wdrożeniu w usłudze Prod w celu sprawdzenia, czy wszystko działa zgodnie z oczekiwaniami.
Niektóre zmiany będą zawsze traktowane jako zmiany powodujące niezgodność. Mam nadzieję, że powyższe kroki pomogą Ci śledzić je przed produkcją. Utwórz plan, aby dowiedzieć się, jak zastosować zmiany w usłudze Prod i odzyskać dane, aby wrócić do normalnego stanu i zminimalizować przestoje dla użytkowników biznesowych.
Przetestuj aplikację
Jeśli dystrybuujesz zawartość do klientów za pośrednictwem aplikacji, przejrzyj nową wersję aplikacji, zanim będzie ona w środowisku produkcyjnym. Ponieważ każdy etap potoku wdrażania ma własny obszar roboczy, można łatwo publikować i aktualizować aplikacje na potrzeby etapów programowania i testowania. Publikowanie i aktualizowanie aplikacji umożliwia przetestowanie aplikacji z punktu widzenia użytkownika końcowego.
Ważne
Proces wdrażania nie obejmuje aktualizowania zawartości ani ustawień aplikacji. Aby zastosować zmiany w zawartości lub ustawieniach, ręcznie zaktualizuj aplikację na wymaganym etapie potoku.
Produkcyjne
Ta sekcja zawiera wskazówki dotyczące etapu produkcyjnego potoków wdrażania.
Zarządzanie tym, kto może wdrażać w środowisku produkcyjnym
Ze względu na to, że wdrażanie w środowisku produkcyjnym powinno być starannie obsługiwane, dobrym rozwiązaniem jest pozwolić tylko określonym osobom zarządzać tą wrażliwą operacją. Prawdopodobnie jednak chcesz, aby wszyscy twórcy analizy biznesowej dla określonego obszaru roboczego mieli dostęp do potoku. Użyj uprawnień obszaru roboczego w środowisku produkcyjnym, aby zarządzać uprawnieniami dostępu. Inni użytkownicy mogą mieć rolę podglądu obszaru roboczego w środowisku produkcyjnym, aby wyświetlić zawartość w obszarze roboczym, ale nie wprowadzać zmian z potoków usługi Git lub wdrażania.
Ponadto ogranicz dostęp do repozytorium lub potoku, włączając tylko uprawnienia do użytkowników, którzy są częścią procesu tworzenia zawartości.
Ustawianie reguł w celu zapewnienia dostępności etapu produkcyjnego
Reguły wdrażania to zaawansowany sposób zapewnienia, że dane w środowisku produkcyjnym są zawsze połączone i dostępne dla użytkowników. Po zastosowaniu reguł wdrażania wdrożenia wdrożenia można uruchamiać wdrożenia, zapewniając, że klienci mogą zobaczyć odpowiednie informacje bez zakłóceń.
Upewnij się, że ustawiono reguły wdrażania produkcyjnego dla źródeł danych i parametrów zdefiniowanych w modelu semantycznym.
Aktualizowanie aplikacji produkcyjnej
Wdrożenie w potoku za pośrednictwem interfejsu użytkownika aktualizuje zawartość obszaru roboczego. Aby zaktualizować skojarzoną aplikację, użyj interfejsu API potoków wdrażania. Nie można zaktualizować aplikacji za pomocą interfejsu użytkownika. Jeśli używasz aplikacji do dystrybucji zawartości, nie zapomnij zaktualizować aplikacji po wdrożeniu w środowisku produkcyjnym, aby użytkownicy końcowi mogli natychmiast korzystać z najnowszej wersji.
Wdrażanie w środowisku produkcyjnym przy użyciu gałęzi usługi Git
Ponieważ repozytorium służy jako "jedno źródło prawdy", niektóre zespoły mogą chcieć wdrażać aktualizacje na różnych etapach bezpośrednio z usługi Git. Jest to możliwe w przypadku integracji z usługą Git z kilkoma zagadnieniami:
Zalecamy używanie gałęzi wydań. Przed każdym wdrożeniem należy stale zmieniać połączenie obszaru roboczego z nowymi gałęziami wydania.
Jeśli potok kompilacji lub wydania wymaga zmiany kodu źródłowego lub uruchomienia skryptów w środowisku kompilacji przed wdrożeniem w obszarze roboczym, połączenie obszaru roboczego z usługą Git nie pomoże.
Po wdrożeniu na każdym etapie pamiętaj, aby zmienić całą konfigurację specyficzną dla tego etapu.
Szybkie poprawki zawartości
Czasami występują problemy w środowisku produkcyjnym, które wymagają szybkiego rozwiązania. Wdrażanie poprawki bez testowania jest złym rozwiązaniem. Dlatego zawsze zaimplementuj poprawkę na etapie programowania i wypchnij ją do pozostałych etapów potoku wdrażania. Wdrożenie na etapie programowania umożliwia sprawdzenie, czy poprawka działa przed wdrożeniem go w środowisku produkcyjnym. Wdrażanie w potoku trwa tylko kilka minut.
Jeśli używasz wdrożenia z usługi Git, zalecamy stosowanie rozwiązań opisanych w temacie Wdrażanie strategii rozgałęziania git.
Powiązana zawartość
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla