Omówienie integracji z usługą Git w systemie Power Platform

Integracja kontroli źródła umożliwia zespołom programistycznym synchronizację rozwiązań i obiektów rozwiązań w jednym lub kilku środowiskach Microsoft Dataverse przy użyciu repozytorium Azure DevOps Git. Funkcjonalność integracji kontroli źródła jest dostępna natywnie w środowiskach rozwiązań, zapewniając programistom obywatelskim, programistom kodu i administratorom możliwość korzystania z kontroli wersji, śledzenia zmian i płynnej współpracy zespołowej w różnych narzędziach i środowiskach. Integracja z usługą Git jest przeznaczona do użytku ze środowiskami deweloperskimi, a nie w środowiskach testowych lub produkcyjnych, w których wdrożenia można wykonywać przy użyciu kompilacji w celu tworzenia artefaktów rozwiązania i potoków do Power Platform wdrożenia.

W tym artykule znajdziesz niektóre z kluczowych pojęć i korzyści płynących z używania kontroli źródła z włączoną obsługą Git w środowiskach i rozwiązaniach Dataverse. Aby uzyskać informacje na temat Git w Azure DevOps, przejdź do Repozytorium Git w Azure DevOps.

ALM w Power Platform i 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 kontroli źródła, można szybko i łatwo nawodnić środowiska programistyczne z kontroli źródła 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 kontroli źródła pochodzą z niezarządzanych rozwiązań w środowisku twórcy. 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.

Tworzenie kodu w oparciu o Git

Tworzenie kodu w Power Platform jest możliwe przy użyciu narzędzi programistycznych, takich jak Power Platform CLI, Visual Studio i rozszerzenia Visual Studio Code. Angażowanie deweloperów kodujących najpierw w proces tworzenia rozwiązania jest trudne bez integracji kontroli źródła, ponieważ obiekty, takie jak Power Apps kontrolki struktury składników i Dataverse wtyczki, są wdrażane w rozwiązaniach jako spakowane zasoby utworzone 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.

Włączając integrację Git w Dataverse, możesz spotkać się z programistami code-first tam, gdzie pracują i zapewnić płynne środowisko zarówno dla programistów 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 programowania oparte na kodzie skojarzone z Dataverse integracją z usługą Git oraz przedstawiono wskazówki dotyczące zarządzania obiektami opartymi na kodzie i z małą ilością kodu w jednym środowisku. Obiekty, takie jak Power Apps kontrolki struktury składników, Dataverse wtyczki i niestandardowe działania przepływu pracy, są przykładami obiektów opartych na kodzie, którymi można zarządzać w kontroli źródła.

Obiekty z dużą ilością kodu i z małą ilością kodu 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 wziąć pod uwagę proces kompilacji.

Jeśli wdrażasz obiekty oparte na kodzie bezpośrednio w rozwiązaniu niezarządzanym w środowisku twórcy, gdy te obiekty są zatwierdzone do kontroli źródła, tylko ich skompilowana (skompilowana) wersja jest przechowywana w kontroli źródła. Na przykład binarna biblioteka DLL, jeśli wtyczka lub transpilowany i zoptymalizowany pakiet JavaScript dla kontrolki Power Apps component framework. 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.

Następne kroki

Konfigurowanie integracji GIT usługi Dataverse