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

  • Artykuł

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, skąd można je spakować do nowego, identycznego pliku 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. Dzięki temu użytkownik będzie mógł wyewidencjonować z kontroli źródła minimalny zestaw zmienionych plików. 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.

Wspólny dewelopment

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 wyszukiwania kontaktów”.

  5. Obaj deweloperzy mogą wyeksportować i wyodrębnić plik ZIP rozwiązania niezarządzanego.

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

    2. Deweloper B będzie musiał wyewidencjonować jeden plik dla głównego formularza konta i 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. Kontynuując pracę z powyższym przykładem, rozważmy sytuację, w której deweloper B dostosował widok „Kontakty aktywne” w czasie, gdy dostosowywał go również deweloper A. 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. 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 „Kontakty aktywne”.

  5. Obaj deweloperzy eksportują rozwiązanie niezarządzane do pliku ZIP i je wyodrębniają.

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

    2. Deweloper B będzie musiał wyewidencjonować jeden plik dla głównego formularza konta i jeden plik dla widoku „Kontakty aktywne”.

  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, aby deweloper A mógł przesłać swoją pracę.

  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, gdy deweloper B ostatni raz pobrał źródła.

    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ę. Deweloperzy mogą komunikować się bezpośrednio w celu omówienia każdej zmiany. 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, który powoduje konflikt.

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

Niezależnie od tego, czy praca jest przeprowadzana w ramach udostępnionej organizacji, czy niezależnych organizacji, zespołowe projektowanie rozwiązań usługi Dataverse wymaga, aby osoby aktywnie pracujące nad wspólnym rozwiązaniem miały wiedzę na temat pracy innych użytkowników. 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 SolutionPackager 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 podstawowej organizacji utwórz rozwiązanie na serwerze usługi Dataverse, a następnie dodaj lub utwórz składniki w zależności od potrzeb.

  2. Gdy wszystko będzie gotowe do zaewidencjowania, wykonaj następujące czynności.

    1. Wyeksportuj rozwiązanie niezarządzane.

    2. Przy użyciu narzędzia SolutionPackager wyodrębnij rozwiązanie do plików 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 SolutionPackager, spakuj pliki składników do pliku ZIP rozwiązania niezarządzanego.

  3. Zaimportuj plik rozwiązania niezarządzanego do organizacji.

  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 SolutionPackager wyodrębnij wyeksportowane rozwiązanie do plików składników.

    3. Zsynchronizuj lub pobierz najnowsze źródła z kontroli źródła.

    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