Serwer wersji oraz kontrola wersji (baza danych lub GIT)
Rozróżniamy 2 rodzaje serwera wersji: plikowy i bazodanowy.
O tym jaki to jest serwer wersji decydujesz w momencie tworzenia projektu. Przykładowo – dla nowo tworzonego projektu deweloperskiego: jeżeli w polu Version Server type wybierzesz File system, zostanie utworzony projekt z plikowym serwerem wersji, jeżeli SQL Server, wówczas serwer wersji będzie bazodanowy.
Część opcji, która jest dostępna w serwerze bazodanowym nie występuje w serwerze wersji plikowym, jak na przykład historia wersji, przejęcie edycji wersji czy przejście do listy wersji edytowanych.
Stosując plikowy serwer wersji możesz skorzystać z zewnętrznego narzędzia na przykład Git lub innego systemu kontroli wersji by zapewnić te funkcjonalności w swoim projekcie.
Serwer wersji bazodanowy (wbudowany mechanizm kontroli wersji)
Serwer wersji bazodanowy zapewnia kontrolę nad edycją danego pliku przez jedną osobę i przechowuje historię zmian. Rozwiązanie to jest proponowane dla osób, które nie mają potrzeby używania zewnętrznego systemu kontroli wersji (typu GIT, SVN etc.)
W celu stworzenia repozytorium, na którym będzie pracowała grupa osób należy podczas tworzenia projektu:
- Jako serwer bazodanowy wskazać instancję SQL Server, do której wszystkie osoby rozwijające projekt będą miały dostęp. Może to być np. SQL Express.
- Jako lokalizację projektu należy podać katalog udostępniony, do którego osoby rozwijające projekt będą miały dostęp.
- Jako lokalizację
RUNTIMEtworzonej aplikacji należy podać katalog na dysku lokalnym. Nazwa katalogu musi mieć postać:
[dowolny katalog][techniczna nazwa projektu]_RUNTIME, jak na poniższym zrzucie z przykładowym projektem.
Po utworzeniu projektu wszystkie osoby z zespołu mogą podłączyć się do tego projektu wybierając w głównym oknie VSoft archITekt Launcher opcję Attach i wskazując katalog projektu.
Runtime na komputerze lokalnym zostanie utworzony u każdego użytkownika w tej samej lokalizacji.
Serwer wersji plikowy (mechanizm kontroli wersji oparty o GIT)
Serwer wersji plikowy umożliwia wykorzystania zewnętrznego narzędzia kontroli wersji (GIT). Jest to rozwiązanie dedykowane dla osób mających doświadczenie techniczne. W tym rozwiązaniu archITekt nic nie wie o zewnętrznym narzędziu kontroli wersji – traktuje konfigurację serwera wersji, tak jakby znajdowała się z w zwykłym katalogu; wszystkie działania związane z zarządzaniem wersjami muszą być wykonywane przez użytkownika w wybranym zewnętrznym narzędziu.
Stworzenie repozytorium
W celu stworzenia repozytorium, na którym będzie pracowała grupa osób należy wykonać podczas tworzenia projektu następujące czynności:
- Pierwsza osoba inicjuje nowy projekt w VSoft archITekt Launcher i w polu Version Server type wybiera plikowy serwer wersji (File system).
- Kopiuje do katalogu projektu plik
.gitignorei dodaje ten folder do repozytorium GIT. Poniżej zawartość pliku .gitignore.
/*
!/_RUNTIME
/_RUNTIME/*
!/_RUNTIME/VersionServer
!/Files
!/SQL
!.gitignore
!/custom.project.json
Podłączenie do repozytorium
W celu podłączenia się do repozytorium, na którym będzie pracowała grupa osób należy:
- Pobrać z repozytorium GIT dane projektu do wybranego katalogu na dysku lokalnym.
- Stworzyć w VSoft archITekt Launcher nowy projekt, który będzie w katalogu, do którego zostały pobrane dane projektu z repozytorium. W tym wypadku katalog projektu (Project folder) to
C:\GIT\Projects\Application - Nazwa w polu Technical name musi być tożsama z nazwą folderu, do którego pobrane zostaną dane z repozytorium. W tym wypadku jest to Application.
- Pliki projektu będą przechowywane w ścieżce do Runtime folder. Nazwa katalogu musi mieć postać:
[dowolny katalog]_[techniczna nazwa projektu]_RUNTIME
- W polu Version Server type wybierz plikowy serwer wersji - File system, a następnie stwórz projekt - Create new project.
Po podłączeniu katalogu projektu do repozytorium zewnętrznego wszystkie operacje związane z wersjonowaniem należy wykonywać w narzędziu kontroli wersji GIT.
Postępowanie w przypadku wystąpienia konfliktów
W przypadku niektórych systemów kontroli wersji (np. GIT) może zdarzyć się sytuacja, w której dwie osoby zmodyfikują ten sam plik. Doprowadza to do konfliktu na etapie synchronizacji repozytorium i wymaga potwierdzenia zawartości spornego pliku przed umieszczeniem go w repozytorium.
- Konfiguracja wersji w platformie archITekt jest zapisywana w plikach XML. Porównywanie dwóch wersji tego samego pliku i łączenie zmian może w niektórych przypadkach być kłopotliwe na poziomie edycji zawartości pliku XML.
- W takim przypadku najwygodniej jest umieścić obie wersje pliku w serwerze wersji i dokonać operacji porównania zawartości za pomocą designera.
W celu umieszczenia kopii spornego pliku w serwerze wersji:
- Zlokalizuj sporny plik w katalogu.
- Przenieś do tego samego katalogu tak jak na poniższym zrzucie ekranu:
- Druga wersja pliku powinna mieć zmienioną nazwę – dodaną frazę „.conflict.”
- Druga wersja pliku powinna mieć zmieniony identyfikator w pliku metadanych: w powyższym przykładzie 3 ostatnie znaki identyfikatora zostały zmienione na „999”. (wymagane jest by identyfikatory wszystkich metadanych w systemie były unikalne).
- Wykonaj operację porównania i modyfikacji wersji w archITekt Studio modyfikując oryginalny plik.
- Usuń nowo dodane pliki, a oryginalny zmodyfikowany plik przenieś do repozytorium.
Uwaga!
- W przypadku dodania kopii niektórych plików (np. struktury danych) mogą być wyświetlane w archITekt Studio informacje o błędach wynikających z pojawienia się duplikatu (np. w przypadku struktury danych – dwóch struktur odwołujących się do tej samej tabeli).
- Należy mieć świadomość, że te błędy będą raportowane wyłącznie w trakcie operacji porównywania wersji (znikną po usunięciu kopii konfliktowego pliku z serwera wersji).
Usunięcie lokalnego projektu
W przypadku projektów podłączonych pod system wersjonowania kodu GIT (czyli projektów mających podkatalog „.git” w katalogu projektu) operacja usuwania projektu nie kasuje całego katalogu projektu, lecz tylko te katalogi, które VSoft archITekt tworzy w sposób automatyczny.
W rezultacie usunięcie projektu z listy nie skasuje lokalnej kopii repozytorium GIT. Użytkownik sam, świadomie powinien usunąć katalog projektu (razem z lokalną kopią repozytorium GIT).