Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Integracja kontroli źródła umożliwia zespołom deweloperów synchronizowanie rozwiązań i obiektów rozwiązań w co najmniej jednym środowisku Microsoft Dataverse przy użyciu obsługiwanego dostawcy Git, takiego jak Azure DevOps lub GitHub. Środowiska rozwiązań mają natywnie wbudowaną funkcję integracji z systemem kontroli źródła, dzięki czemu programiści obywatelscy, programiści preferujący kod oraz administratorzy mogą korzystać z kontroli wersji, śledzenia zmian i bezproblemowej współpracy zespołowej w różnych narzędziach i środowiskach. Użyj integracji usługi Git ze środowiskami deweloperskimi, a nie w środowiskach testowych ani produkcyjnych. Tworzenie artefaktów i potoków rozwiązania na platformie Power Platform w celu wdrożenia za pomocą kompilacji.
W tym artykule wyjaśniono niektóre z kluczowych pojęć i korzyści związanych z używaniem kontroli źródła z obsługą usługi Git w środowiskach i rozwiązaniach usługi Dataverse. Aby uzyskać informacje o systemie Git w usłudze Azure DevOps, zobacz Repozytorium Git w usłudze Azure DevOps. Aby uzyskać informacje o repozytoriach GitHub, zobacz Informacje o repozytoriach.
ALM na platformie Power Platform i w usłudze Dataverse
Power Platform zapewnia wiele gotowych funkcji, które umożliwiają organizacjom zarządzanie cyklem życia aplikacji (ALM) dla ich rozwiązań. Obejmuje to możliwość pakowania rozwiązań jako kontenerów dla wielu różnych typów obiektów na platformie, zarządzania środowiskami zaangażowanymi w cykl życia aplikacji oraz wdrażania rozwiązań przy użyciu potoków Power Platform. Istnieje również kilka sposobów integracji repozytoriów Git z Power Platform przy użyciu narzędzi deweloperskich. Dzięki natywnej integracji Git w Dataverse, proces jest uproszczony i usprawniony, aby twórcy mogli pracować ze swoimi rozwiązaniami w znany sobie sposób i wchodzić w interakcje z kontrolą źródła za pomocą uproszczonych interfejsów w Power Apps (make.powerapps.com).
Świadczenia
- Kontrola źródła jako źródło prawdy: W niektórych organizacjach źródłem prawdy dla wdrożeń w Dataverse są środowiska twórców, w których budowane są rozwiązania. Głównym powodem takiego zachowania jest fakt, że nienatywna integracja Git wykorzystuje zaawansowane techniki i narzędzia, które wymagają profesjonalnej wiedzy informatycznej, aby rozpocząć pracę. Dzięki natywnej integracji Git w Dataverse, kontrola źródła może być włączona w zaledwie kilku krokach i zapewnia znajomy interfejs dla twórców do pracy z ich rozwiązaniami.
- Bezpieczeństwo, audyt i zgodność z najlepszymi praktykami SDLC: Najlepsze praktyki cyklu życia oprogramowania (SDLC) to zestaw wytycznych i procesów, które pomagają efektywnie zarządzać projektami tworzenia oprogramowania. Korzystając z integracji Git w Dataverse, stosujesz praktyki SDLC, takie jak kontrola wersji, sprawdzenie kodu i statyczna analiza kodu źródłowego, aby zapewnić jakość, niezawodność i bezpieczeństwo swoich rozwiązań. Integracja Git w Dataverse zapewnia również funkcje takie jak audyt, zgodność i identyfikowalność, które pomagają śledzić zmiany w rozwiązaniach i efektywnie współpracować z innymi członkami zespołu.
- Krótkotrwałe środowiska deweloperskie: Przechowując kopię dostosowań i konfiguracji środowisk w systemie kontroli wersji, można szybko i łatwo odtworzyć środowiska deweloperskie z systemu kontroli wersji w Dataverse. Pozwala to na tworzenie krótkotrwałych środowisk do celów programistycznych i testowych. Krótkotrwałe środowiska pozwalają zwolnić przestrzeń dyskową, eksperymentować z nowymi funkcjami, testować i iterować rozwiązania bez polegania na stałych środowiskach.
- Zespoły programistyczne Fusion: Zespoły programistyczne Fusion to zespoły składające się zarówno z programistów, jak i twórców, którzy współpracują przy tworzeniu rozwiązań. Korzystając z integracji Git w Dataverse, użytkownicy ci mogą tworzyć niezależnie w oddzielnych środowiskach i współpracować z innymi poprzez synchronizację ze wspólnym repozytorium kontroli źródła. Integracja kontroli źródła pozwala wykorzystać umiejętności i wiedzę zarówno programistów, jak i twórców, aby tworzyć wysokiej jakości rozwiązania spełniające potrzeby organizacji.
- Ochrona: Korzystanie z kontroli źródła jako źródła prawdy dla rozwiązań pozwala szybko i łatwo odzyskać dane po niezamierzonych zmianach w rozwiązaniach. Przechowując rozwiązania w kontroli źródła, można przywrócić poprzedni stan lub wersję.
Najważniejsze pojęcia
Rozwiązania niezarządzane a zarządzane
Podczas korzystania z integracji Git z Dataverse rozwiązania przechowywane w systemie kontroli wersji pochodzą z rozwiązań niezarządzanych w środowisku autora. Rozwiązania niezarządzane umożliwiają twórcom dodawanie, usuwanie i aktualizowanie obiektów, które są synchronizowane z kontrolą źródła podczas zatwierdzania i wypychania zmian. Rozwiązania zarządzane są tworzone z poziomu kontroli źródła i wdrażane w środowiskach niższego szczebla, takich jak testowe lub produkcyjne, i nie można ich edytować w tych środowiskach. Rozwiązania zarządzane służą do zapewnienia, że źródłem prawdy dla Twoich rozwiązań jest zawsze kontrola źródła, a zmiany są wprowadzane tylko w środowisku twórcy, zanim zostaną dodane do kontroli źródła i wdrożone w innym miejscu.
Formatowanie plików dla obiektów rozwiązania
Wraz z wprowadzeniem integracji Dataverse z usługą Git wprowadzono zmiany w sposobie, w jaki rozwiązania i obiekty rozwiązań są reprezentowane w kontroli źródła. Podczas zatwierdzania i wypychania zmian do kontroli źródła obiekty rozwiązania są przechowywane w określonym formacie, który jest zgodny z usługą Git. Ten format służy do reprezentowania obiektów rozwiązania w sposób, który jest łatwy do odczytania i zrozumienia oraz może służyć do śledzenia zmian w obiektach rozwiązania w czasie. Format pliku dla obiektów rozwiązania jest zaprojektowany tak, aby był czytelny dla człowieka i może służyć do wyświetlania zmian w obiektach rozwiązania w kontroli źródła. Ponadto, aby umożliwić przechowywanie wielu rozwiązań w tym samym repozytorium i folderze, obiekty rozwiązania w kontroli źródła nie są już duplikowane dla każdego rozwiązania. Zamiast tego obiekty rozwiązania są przechowywane w jednej lokalizacji i mogą być współużytkowane przez wiele rozwiązań w tym samym repozytorium i folderze.
Programowanie z podejściem code-first przy użyciu Git
Programowanie z podejściem code-first w Power Platform jest realizowane przy użyciu narzędzi programistycznych, takich jak Power Platform CLI, Visual Studio oraz rozszerzeń do Visual Studio i Visual Studio Code. Zaangażowanie deweloperów pracujących w podejściu code-first w proces tworzenia rozwiązania jest trudne bez integracji z kontrolą źródła, ponieważ obiekty, takie jak kontrolki Power Apps Component Framework i wtyczki Dataverse, są wdrażane do rozwiązań jako spakowane zasoby zbudowane na podstawie kodu źródłowego i nie można ich bezpośrednio edytować w Power Apps (make.powerapps.com). Bez kontroli źródła w ramach procesu programowania zarówno dla obiektów z małą ilością kodu, jak i obiektów opartych na kodzie, trudno jest zarządzać zmianami w rozwiązaniu i zapewnić, że zmiany są śledzone i wdrażane w kontrolowany sposób.
Dzięki włączeniu integracji Git w Dataverse możesz dotrzeć do programistów code-first w ich środowisku pracy i zapewnić bezproblemową pracę zarówno programistom low-code, jak i code-first. Istnieją jednak pewne kwestie, o których należy pamiętać podczas zarządzania obiektami opartymi na kodzie w środowisku z małą ilością kodu.
Rozwój Fusion z integracją Dataverse Git
Power Platform zapewnia możliwości zarówno rozwoju niskokodowego, jak i opartego na kodzie. W tym artykule omówiono procesy programistyczne typu code-first związane z integracją z usługą Dataverse i systemem Git oraz przedstawiono wskazówki dotyczące zarządzania obiektami typu code-first i niskokodowymi w jednym środowisku. Obiekty takie jak kontrolki struktury składników Power Apps, wtyczki Dataverse i niestandardowe działania przepływu pracy są przykładami obiektów tworzonych w pierwszej kolejności w kodzie, którymi można zarządzać w systemie kontroli wersji.
Obiekty oparte na kodzie i niskokodowe w jednym środowisku
Obiekty oparte na kodzie mogą być dołączane do rozwiązań za pośrednictwem procesu kompilacji, który generuje rozwiązanie zarządzane lub niezarządzane, które można zaimportować do Dataverse środowiska. Jednak obiekty oparte na kodzie można również wdrażać bezpośrednio w rozwiązaniu niezarządzanym w środowisku twórcy po ich skompilowaniu bez konieczności korzystania z procesu kompilacji rozwiązania w celu ich wdrożenia. Biorąc pod uwagę tę elastyczność, należy też uwzględnić proces kompilacji.
Jeśli wdrażasz obiekty typu code-first bezpośrednio do rozwiązania niezarządzanego w środowisku autora, to gdy te obiekty zostaną zapisane w systemie kontroli źródła, w systemie kontroli źródła będzie przechowywana tylko ich wersja skompilowana (po zbudowaniu). Na przykład binarna biblioteka DLL w przypadku wtyczki lub transpilowany i zoptymalizowany pakiet JavaScript dla kontrolki struktury składników Power Apps. W związku z tym otrzymasz dwie kopie obiektu w kontroli źródła — jedną reprezentowaną przez skompilowaną wersję, a drugą reprezentowaną przez kod źródłowy. Przechowywanie plików binarnych w repozytorium może prowadzić do nieporozumień i potencjalnych konfliktów, jeśli kod źródłowy i skompilowana wersja nie są zsynchronizowane. Ta praktyka nie jest zalecana, ponieważ kod źródłowy powinien być jedynym źródłem prawdy dla obiektu i powinna być przechowywana tylko jedna kopia.
Zalecanym podejściem jest kompilowanie obiektów opartych na kodzie w ramach procesu kompilacji rozwiązania i importowanie wygenerowanego rozwiązania niezarządzanego do środowiska twórcy. Takie podejście gwarantuje, że kod źródłowy i skompilowana wersja są zsynchronizowane i że kod źródłowy jest jedynym źródłem prawdy dla obiektu. Jednak takie podejście wymaga procesu kompilacji w celu wygenerowania rozwiązania zarządzanego lub niezarządzanego do użycia w procesie importowania i wdrażania. Można na przykład tworzyć procesy Azure Pipelines lub GitHub, które tworzą artefakty dla potoków w Power Platform i procesów synchronizacji Git.