Kontrola źródła za pomocą plików rozwiązania

Narzędzia SolutionPackager można używać z dowolnym systemem kontroli źródła. Po wyodrębnieniu pliku ZIP rozwiązania do folderu wystarczy dodać i przesłać pliki do systemu kontroli źródła. Pliki te mogą być synchronizowane na innym komputerze, gdzie można je następnie spakować w nowy, identyczny plik ZIP rozwiązania.

Ważny aspekt w przypadku używania wyodrębnionych plików składników w kontroli źródła polega na tym, że dodanie wszystkich plików do kontroli źródła może powodować niepotrzebne duplikaty. Zobacz dokumentację dotyczącą plików składników rozwiązania, aby sprawdzić, które pliki są generowane dla poszczególnych typów składników oraz jakie pliki są zalecane do użycia w kontroli źródła.

Ponieważ dalsze dostosowywania i zmiany są konieczne w rozwiązaniu, deweloperzy muszą edytować lub dostosowywać składniki, korzystając z istniejących środków, eksportować je ponownie w celu utworzenia pliku ZIP i wyodrębniać skompresowany plik rozwiązania do tego samego folderu.

Ważne

Z wyjątkiem sekcji opisanych w artykule Kiedy edytować plik dostosowań ręczna edycja wyodrębnionych plików składników i plików ZIP nie jest obsługiwana.

Kiedy narzędzie SolutionPackager wyodrębnia pliki składników, nie zastępuje istniejących plików składników o tej samej nazwie, jeśli zawartość pliku jest taka sama. Oprócz tego narzędzie uwzględnia w plikach składników atrybut tylko do odczytu, który zawiera ostrzeżenie w oknie konsoli, że określone pliki nie zostały zapisane. To zabezpieczenie umożliwia użytkownikowi wyciągnąć z systemu kontroli wersji minimalny zbiór plików, które ulegają zmianom. Parametr /clobber może służyć do zastępowania i usuwania plików tylko do odczytu. Parametr /allowWrite może służyć do oceny skutków operacji wyodrębnienia bez zapisywania lub usuwania plików. Skuteczne jest użycie parametru /allowWrite z pełnym rejestrowaniem.

Po wykonaniu operacji wyodrębnienia z minimalnym zestawem plików wyewidencjonowanych z kontroli źródła deweloper może przesłać zmienione pliki do kontroli źródła, tak jak w przypadku każdego innego typu pliku źródłowego.

Formaty plików kontroli źródła

Narzędzie do pakowania rozwiązań obsługuje dwa formaty plików dla wyodrębnionych plików komponentów. Wybranie odpowiedniego formatu z góry pozwala uniknąć konieczności późniejszej migracji struktury repozytorium.

Format XML (starsza wersja) Format kontroli źródła YAML
Manifest rozwiązania Other\Solution.xml + Other\Customizations.xml solutions/<name>/solution.yml i obsługa plików YAML
Czytelność Pełne informacje XML Kompaktowanie kodu YAML — łatwiejsze do odczytania i przejrzenia
Różnica jakości w usłudze Git Duże różnice XML Minimalne, ukierunkowane różnice
Repozytorium z wieloma rozwiązaniami Niewspierane Obsługiwane — wiele rozwiązań współużytkuje jeden folder
Canvas apps (msapp) Niewspierane Wsparte
Nowoczesne przepływy Niewspierane Wsparte
Natywna integracja z usługą Git Nie używane Zawsze używane — integracja z usługą Git zawsze zapisuje kod YAML

Kiedy należy użyć formatu YAML: W przypadku wszystkich nowych projektów i za każdym razem, gdy używasz natywnej integracji usługi Dataverse z usługą Git. Format YAML jest przyszłościowo zgodny i tworzy czystszą historię zmian.

Kiedy należy użyć formatu XML: Tylko podczas pracy z istniejącymi repozytoriami, które już używają formatu XML, lub w przypadku korzystania ze starszych narzędzi, które nie obsługują języka YAML.

Uwaga / Notatka

W przypadku zatwierdzania rozwiązań przy użyciu natywnej integracji git w Power Apps są one zawsze przechowywane w formacie kontroli źródła YAML. Aby ręcznie spakować lub rozpakować to źródło przy użyciu pakietu SolutionPackager lub pac solution pack, folder musi być zgodny ze strukturą folderów YAML. Więcej informacji: SolutionPackager tool — Formaty plików kontroli źródła

Rozwój zespołu

W przypadku wielu deweloperów pracujących nad tym samym składnikiem rozwiązania konflikt może powstać w sytuacji, gdy zmiany wprowadzone przez dwóch deweloperów powodują wprowadzenie zmian w pojedynczym pliku. To wystąpienie jest zminimalizowane przez rozłożenie poszczególnych składników lub składników podrzędnych, które można edytować, do odrębnych plików. Rozpatrzmy następujący przykład.

  1. Deweloperzy A i B pracują nad tym samym rozwiązaniem.

  2. Na niezależnych komputerach pobierają najnowsze źródła rozwiązania z kontroli źródła, pakują i importują plik ZIP rozwiązania niezarządzanego do niezależnych organizacji usługi Microsoft Dataverse.

  3. Deweloper A dostosowuje widok systemowy „Kontakty aktywne” i główny formularz encji Kontakt.

  4. Deweloper B dostosowuje formularz główny encji Konto i zmienia „Widok odnośników do kontaktu”.

  5. Obaj deweloperzy wyeksportowali plik ZIP z rozwiązaniem niezarządzanym i a następnie go wyodrębnili.

    1. Deweloper A musi pobrać jeden plik dla formularza głównego kontaktu i jeden plik dla widoku „Aktywne kontakty”.

    2. Deweloper B będzie musiał pobrać jeden plik dla głównego formularza konta oraz jeden plik dla widoku wyszukiwania kontaktów.

  6. Obaj deweloperzy mogą przesyłać w dowolnej kolejności, ponieważ ich zmiany dotyczą osobnych plików.

  7. Po zakończeniu obu operacji przesyłania mogą oni powtórzyć krok 2, a następnie kontynuować wprowadzanie zmian w niezależnych organizacjach. Każdy z nich ma oba zestawy zmian, a ich własna praca nie zostaje zastąpiona.

Powyższy przykład działa tylko wtedy, gdy istnieją zmiany w oddzielnych plikach. Nieuniknione jest, że niezależne dostosowywania będą wymagać zmian w pojedynczym pliku. Na podstawie przedstawionego wcześniej przykładu należy wziąć pod uwagę, że deweloper B dostosowywał widok "Aktywne kontakty", podczas gdy deweloper A również go dostosowywał. W tym nowym przykładzie kolejność zdarzeń staje się ważna. Poprawny proces rozwiązania i całkowitego pozbycia się tego problemu został opisany poniżej.

  1. Deweloperzy A i B pracują nad tym samym rozwiązaniem.

  2. Na niezależnych komputerach pobierają najnowsze źródła rozwiązania z kontroli źródła, pakują i importują plik ZIP rozwiązania niezarządzanego do niezależnych organizacji.

  3. Developer A dostosowuje widok systemu "Aktywne kontakty" i formularz główny dla tabeli Contact.

  4. Deweloper B dostosowuje formularz główny dla tabeli Konto i zmienia „Aktywne kontakty”.

  5. Obaj deweloperzy wyeksportują plik ZIP rozwiązania niezarządzanego i wyodrębnią go.

    1. Deweloper A będzie musiał wyewidencjonować jeden plik dla głównego formularza kontaktu i jeden plik dla widoku „Kontakty aktywne”.

    2. Deweloper B musi pobrać jeden plik dla formularza głównego konta i jeden plik dla widoku 'Aktywne kontakty'.

  6. Deweloper A jest gotowy jako pierwszy.

    1. Przed przesłaniem do kontroli źródła deweloper A musi pobrać najnowsze źródła, aby poprzednie operacje zaewidencjonowania nie powodowały konfliktu z jego zmianami.

    2. Nie ma żadnych konfliktów, więc programista A może przesłać.

  7. Deweloper B jest gotowy po deweloperze A.

    1. Przed przesłaniem deweloper B musi pobrać najnowsze źródła, aby poprzednie operacje zaewidencjonowania nie powodowały konfliktu z jego zmianami.

    2. Wystąpił konflikt, ponieważ plik dla widoku „Kontakty aktywne” został zmodyfikowany od czasu ostatniego pobrania najnowszych źródeł przez dewelopera B.

    3. Deweloper B musi rozwiązać ten konflikt. Być może pomogą mu funkcje systemu kontroli źródła, ale jeśli nie, wszystkie poniższe opcje są również dobrym rozwiązaniem.

      1. Deweloper B za pośrednictwem historii kontroli źródła, jeśli jest dostępna, może stwierdzić, że deweloper A wprowadził poprzednią zmianę. Mogą komunikować się bezpośrednio, aby omówić każdą zmianę. Następnie deweloper B musi tylko zaktualizować organizację za pomocą uzgodnionego rozwiązania. Następnie deweloper B eksportuje, wyodrębnia i zastępuje plik, który powoduje konflikt, i przesyła go.

      2. Zezwala on, aby kontrola źródła zastąpiła plik lokalny. Deweloper B pakuje rozwiązanie i importuje je do swojej organizacji, a następnie ocenia stan widoku i w razie potrzeby dostosowuje go ponownie. Następnie deweloper B może wyeksportować, wyodrębnić i zastąpić plik powodujący konflikt.

      3. Jeśli poprzednia zmiana nie jest niezbędna, deweloper B pozwala kopii pliku na zastąpienie wersji w kontroli źródła i przesyła plik.

Niezależnie od tego, czy praca jest przeprowadzana w ramach udostępnionego środowiska, czy niezależnego środowiska, zespołowe projektowanie rozwiązań Dataverse wymaga, aby osoby aktywnie pracujące nad wspólnym rozwiązaniem miały wiedzę na temat pracy innych osób. Narzędzie SolutionPackager nie zaspokaja tej potrzeby w całości, ale umożliwia szybkie scalanie zmian niepowodujących konfliktów na poziomie kontroli źródła oraz proaktywnie i precyzyjnie wyróżnia składniki, w których powstały konflikty.

Następne sekcje opisują ogólne procesy ułatwiające efektywne korzystanie z narzędzia Solution Packager w kontroli źródła podczas programowania zespołowego. Te działania są takie same w przypadku niezależnych lub udostępnionych organizacji projektowych, mimo że w organizacjach udostępnionych eksportowanie i wyodrębnianie będzie naturalnie obejmować wszystkie zmiany zawarte w rozwiązaniu, a nie tylko te, które zostały dokonane przez dewelopera wykonującego eksport. Podobnie podczas importowania pliku ZIP rozwiązania naturalnym zachowaniem będzie zastąpienie wszystkich składników.

Tworzenie rozwiązania

Poniższa procedura identyfikuje typowe kroki używane podczas pierwszego tworzenia rozwiązania.

  1. W czystym środowisku z Dataverse utwórz rozwiązanie, a następnie dodaj lub utwórz składniki w zależności od potrzeb.

  2. Gdy będziesz gotowy do zameldowania, wykonaj następujące czynności.

    1. Wyeksportuj rozwiązanie niezarządzane.

    2. Przy użyciu narzędzia Solution Packager wyodrębnij rozwiązanie jako pliki składników.

    3. Z wyodrębnionych plików składników dodaj wymagane pliki do kontroli źródła.

    4. Prześlij te zmiany do kontroli źródła.

Modyfikowanie rozwiązania

Poniższa procedura identyfikuje typowe kroki używane podczas modyfikowania istniejącego rozwiązania.

  1. Zsynchronizuj lub pobierz najnowsze źródła plików składników rozwiązania.

  2. Korzystając z narzędzia Solution Packager, spakuj pliki składników do pliku ZIP rozwiązania niezarządzanego.

  3. Zaimportuj plik rozwiązania niezarządzanego do środowiska.

  4. W razie potrzeby dostosuj i edytuj rozwiązanie.

  5. Aby zaewidencjonować zmiany do kontroli źródła, wykonaj następujące czynności.

    1. Wyeksportuj rozwiązanie niezarządzane.

    2. Przy użyciu narzędzia Solution Packager wyodrębnij wyeksportowane rozwiązanie do plików składników.

    3. Zsynchronizuj lub uzyskaj najnowsze źródła z systemu kontroli wersji.

    4. Rozwiąż ewentualne konflikty.

    5. Prześlij zmiany do kontroli źródła.

    Kroki 2 i 3 muszą zostać wykonane przed dalszymi dostosowaniami w organizacji projektowej. W kroku 5 krok b musi zostać wykonany przed krokiem c.

Zobacz także

Dokumentacja pliku składnika rozwiązania (SolutionPackager)
Narzędzie SolutionPackager
Formaty plików kontroli źródła

  • Last updated on