W wersji opartej na gałęziach musimy omówić poniższy diagram, który doskonale ilustruje panoramę procesu zarządzania konfiguracją. Przede wszystkim ten diagram jest napisany na podstawie modelu Git, ale w rzeczywistości Git i Subversion odkryły koncepcję zarządzania kontrolą wersji, jednak Git robi jednak jakościowy krok naprzód względem Subversion w zarządzaniu gałęziami i wydajności rozproszonej (choć nie jest to główny temat tego artykułu).
Zanim przedstawimy zasadę tego grafu, porozmawiajmy o dwóch różnych strategiach ogólnej kontroli wersji: jednej jest "kręgosłup pionierski, gałąź stabilna", a drugiej "stabilny kręgosłup, gałąź pionierska". Jak sama nazwa wskazuje, jest to wersja stabilna (wersja produkcyjna), na pniu lub na gałęzi. W przypadku tradycyjnych zespołów projektowych korzystających z VSS trudno jest określić, do którego trybu należy VSS, głównie dlatego, że sam VSS nie posiada strategii zarządzania gałęziami, więc wiele zespołów projektowych tworzy odpowiednio dwie (lub trzy) biblioteki wersji, odpowiadające środowisku produkcyjnemu i rozwojowemu, co oczywiście jest także rodzajem zarządzania gałęziami w przebraniu. Jednak jeśli przełączysz się na Subversion lub Git jako narzędzie do kontroli wersji, większość zespołów korzysta z trybu stable trunk, czyli trunk (truck lub master) odpowiada stabilnemu środowisku produkcyjnemu i taguje różne wersje, aby wskazać wersję produkcyjną. Osobiście uważam, że stabilny wzorzec kodu szkieletowego powinien być obecnie absolutnym rozwiązaniem do zarządzania wersjami kodu. Powyższe zdjęcie przedstawia standardowy model zarządzania "stabilnym kręgosłupem".
mistrz: Odpowiedni Subversion to ciężarówka。 Odpowiadając wersji produkcyjnej, jest oznaczany raz na każde wydanie.
Gałęzia Release (znana również jako Integration Branch): Dopóki produkcja jest aktualizowana, musi zostać najpierw połączona z gałęzią release (integracyjną). Jest to nieco podobne do tego, co obecnie zespół projektowy nazywa koncepcją "preprodukcji" i "symulowanego środowiska".
Rozwijaj gałąź (gałąź deweloperska lub gałąź deweloperska): Środowisko, z którym mierzy się środowisko rozwojowe.
Gałąź charakterystyczna (gałąź cech): Niektóre funkcje niezależne można oddzielić od osobnej gałęzi rozwojowej. Chodzi głównie o to, by poradzić sobie z faktem, że niektóre funkcje mogą wymagać stosunkowo dużo czasu na aktualizację, aby nie spowalniać wersji i oddzielnych gałęzi.
Gałąź hotfixes (gałąź naprawy błędów): Błąd tutaj to głównie błąd produkcyjny.
Po wprowadzeniu pnia i gałęzi muszę wskazać kierunek generowania i łączenia tych gałęzi.
Master to wersja produkcyjna, a trunk akceptuje tylko dwie gałęzie do scalania: jedna to gałąź release (integracja), a druga to gałąź hotfixes. Żadna inna gałąź nie może zostać włączona do oddziału produkcyjnego.
Gąź wydania jest początkowo tworzona w tym samym czasie co produkcja, co dokładnie to samo, co produkcja. Akceptuje tylko gałąź deweloperską do połączenia. Innymi słowy, nie akceptuje łączenia bezpośrednio z gałęzią cech ani z gałęzią naprawy błędów.
Dział deweloperski, dział deweloperski, podobnie jak integracyjny, jest taki sam jak środowisko produkcyjne w danym momencie. Jednak w miarę postępu rozwoju nowe funkcje będą nadal tworzone w dziale deweloperskim. Teoria deweloperska akceptuje łączenie tylko dwóch gałęzi, jednej to hotfixy, a drugiej gałęzi cech.
Branch feature Branch zaczynając od określonego punktu (wersji) z gałęzią deweloperską, gałąź cech ostatecznie połączy się z gałęzią deweloperską.
Przedstawmy krótko metodę kontroli wersji w formie scenariusza
Załóżmy, że wersja produkcyjna jest podzielona na gałęzie (dev, hotfixes, release), a w tym momencie dev zaczyna rozwijać łącznie dziesięć funkcji. Gdy 8 z 10 funkcji zostało opracowanych, zespół testowy zaczął interweniować w zakresie testów wewnętrznych, a administrator konfiguracji wdrożył gałąź deweloperską do środowiska deweloperskiego do testowania za pomocą narzędzi do ciągłej integracji (osobny temat tutaj). Gdy weryfikacja testowa wykazała, że dwie funkcje są całkowicie nie do przyjęcia i wymagają ponownego wdrożenia, takich jak proste ubezpieczenie ubezpieczeniowe i zwrot roszczeń, dwie gałęzie funkcji zostały oddzielone od programowania, odpowiadające prostemu ubezpieczeniu i zwrotowi roszczeń, a w gałęzi deweloperskiej odpowiadający im kod również musiał zostać cofnięty (tutaj obsługa ręczna). Gdy zespół testowy stwierdzi, że nie ma problemów z testem gałęzi deweloperskiej, spełnia on warunki UAT, więc administrator konfiguracji łączy gałąź deweloperską z gałęzią release, a następnie używa narzędzi do ciągłej integracji, aby publikować tę gałąź w środowisku przedprodukcyjnym i przekazać użytkownikowi do testów. Gdy weryfikacja użytkownika wykryje problem, deweloper modyfikuje gałąź deweloperską, a następnie łączy ją z gałęzią release (tutaj, na oryginalnym zdjęciu, jest bezpośrednio modyfikowana w gałęzi release, co uważam, że to nie jest dobre, zalecam, aby deweloper zwracał się tylko do gałęzi deweloperskiej), gdy proces weryfikacji release nagłe odkrywa, że w środowisku budowania jest poważny błąd, który wymaga natychmiastowej naprawy, jest on pilnie modyfikowany w gałęzi hotfixes i uruchamiany po potwierdzeniu poprawności. Jednocześnie gałąź hotfixes jest łączona z programowaniem (tutaj jest to głównie ręczne, ponieważ wersja produkcyjna jest już bardzo różna od wersji deweloperskiej i często nie da się ukończyć automatycznego scalania), a następnie program jest włączany do wydania. Po pewnym czasie funkcja zwrotu roszczeń może przestać być potrzebna i musi zostać anulowana, więc gałąź funkcji zwrotu roszczeń zostanie usunięta. Inna funkcja jest łatwa do ubezpieczenia i została opracowana oraz ponownie połączona z gałęzią deweloperską, aby uruchomić ją wraz z kolejną wersją online.
Powyższy scenariusz obejmuje zasadniczo rutynowe rozwiązywanie, rozpakowywanie się, aktualizacje awaryjne i inne scenariusze w codziennym procesie tworzenia.
|
Opublikowano 08.04.2018 10:25:39
|
|
|
|
