Co to jest przepływ pracy oparty na wydaniach?

Ukończone

Tutaj omówiono sposób tworzenia przepływu pracy opartego na wydaniach przy użyciu usługi GitHub.

Co to jest przepływ pracy oparty na wydaniach?

Przepływ pracy oparty na wydaniach to zestaw wzorców i zasad, które koncentrują się na wydawaniu oprogramowania. Chociaż to pojęcie może wydawać się oczywistym celem dla zespołu deweloperów, wartość tej perspektywy jest bardziej zniuansowana. W tej lekcji omówimy sposób, w jaki napędza on trzy różne części cyklu wydawania: zarządzanie projektem, wybieranie strategii rozgałęziania i wydawanie klientom.

Planowanie pracy z tablicami projektu w usłudze GitHub

Z perspektywy planowania skoncentrowanie się na wydawaniu oznacza, że problemy są dzielone na odrębne iteracje, które składają się na nową wersję. Te iteracji są często nazywane przebiegami i są w przybliżeniu takie same okresy, aby tworzyć zmiany przyrostowe. Inne zespoły wolą spakować całe wersje wydania w jedną iterację, która może trwać kilka miesięcy lub dłużej. W usłudze GitHub tymi iteracjami zarządza się jako projektami.

Dominującą funkcją projektu jest jego tablica. Tablica to centralny plan rejestrowania dla iteracji i zawiera wszystkie karty, które mają zostać rozstrzygnięte. Karta może odzwierciedlać problem, żądanie ściągnięcia, a nawet zwykłą notatkę.

Domyślnie każda karta rozpoczyna się w kolumnie Do wykonania i po rozpoczęciu prac przechodzi do kolumny W toku zanim trafi do kolumny Gotowe. Możesz dostosować te kolumny, dodać więcej kolumn lub zastosować automatyzację do przenoszenia tych kart i ich właściwości w celu dopasowania ich do procesu zespołu.

Dowiedz się więcej o zarządzaniu tablicami projektów.

Stan projektu na karcie jest zintegrowany w całym repozytorium. Na przykład przeciągnięcie karty z Do do pozycji W toku zmienia jego stan i aktualizuje wskaźnik wizualizacji obok tytułu projektu. Zielona sekcja wskazuje część kart oznaczonych jako Gotowe, natomiast purpurowa jest używana dla kart W toku. Pozostałe miejsce odzwierciedla liczbę kart, które jeszcze nie zostały rozpoczęte. Oprócz przeciągania kart wokół tablicy można je zaktualizować z widoku głównego.

Gdy używasz tablicy projektu, wszyscy uczestnicy projektu mają łatwy sposób zrozumienia stanu i szybkości projektu. Można również tworzyć tablice o zakresie ograniczonym do poszczególnych użytkowników lub kolekcji repozytoriów należących do organizacji.

Dowiedz się więcej o śledzeniu postępu prac za pomocą tablic projektów.

Śledzenie konkretnych punktów kontrolnych

W przypadku zespołów lub podzbiorów zespołów usługa GitHub oferuje śledzenie punktów kontrolnych.

Punkty kontrolne są podobne do śledzenia projektów, ponieważ kładzie się nacisk na priorytetowe uzupełnianie problemów i żądań ściągnięcia. Jednak w przypadku, gdy projekt może być skoncentrowany na procesie zespołu, kamień milowy koncentruje się na produkcie.

Dowiedz się więcej o śledzeniu postępu pracy za pomocą punktów kontrolnych.

Wybieranie strategii rozgałęziania

Repozytoria, które mają wielu deweloperów pracujących równolegle, muszą mieć dobrze zdefiniowaną strategię rozgałęziania. Osiedlenie się na ujednoliconym podejściu na wczesnym etapie projektu pozwala zaoszczędzić zamieszanie i frustrację w miarę skalowania zespołu i bazy kodu.

Przepływ w usłudze GitHub

Oprócz udostępniania platformy do współpracy nad tworzeniem oprogramowania usługa GitHub oferuje również wstępnie ustawiony przepływ pracy zaprojektowany w celu optymalizacji użycia jego różnych funkcji. Chociaż usługa GitHub może pracować z praktycznie dowolnym procesem tworzenia oprogramowania, zalecamy rozważenie przepływu usługi GitHub, jeśli twój zespół nie został jeszcze rozstrzygnięty w procesie.

Praca z gałęziami długoterminowymi

Gałąź długoterminowa to gałąź usługi Git, która nigdy nie jest usuwana. Niektóre zespoły wolą unikać ich całkowicie na rzecz krótkotrwałych funkcji i gałęzi naprawy błędów. Dla tych zespołów celem wszystkich podejmowanych działań jest utworzenie żądania ściągnięcia, które scala efekty ich pracy z gałęzią main. Takie podejście może być skuteczne w przypadku projektów, które nigdy nie muszą patrzeć wstecz, takie jak aplikacje internetowe pierwszej firmy, które nie obsługują poprzedniej wersji.

Istnieją jednak pewne scenariusze, w których gałęzie długoterminowe najlepiej zaspokajają potrzeby zespołu. Najbardziej typowym przypadkiem gałęzi długoterminowej jest sytuacja, gdy produkt ma wiele wersji, które muszą być obsługiwane przez dłuższy czas. Gdy zespół musi opracować plan dla tego zobowiązania, repozytorium powinno być zgodne ze standardową konwencją, taką jak release-v1.0, release-v2.0 i tak dalej. Te gałęzie powinny być również oznaczone jako chronione w usłudze GitHub, aby dostęp do zapisu był kontrolowany i nie można ich przypadkowo usunąć.

Zespoły powinny nadal zachować main jako gałąź główną i scalać zmiany w wydaniach gałęzi nadrzędnej, dopóki pasują one do przyszłości projektu. Gdy nadejdzie odpowiednia pora, gałąź release-v3.0 powinna opierać się na gałęzi main, aby prace nad obsługą gałęzi release-v2.0 nie komplikowały repozytorium.

Obsługa gałęzi długoterminowych

Załóżmy, że poprawka błędu została scalona z gałęzią release-v2.0, a następnie scalona ponownie nadrzędnie z gałęzią main. Następnie okazało się, że ta usterka również istniała w release-v1.0 gałęzi, a poprawka musiała zostać przywrócona dla klientów nadal korzystających z tej wersji. Jaki jest najlepszy sposób na przywrócenie tej poprawki?

Scalenie gałęzi w main dół release-v1.0 z nie byłoby wykonalną opcją, ponieważ będzie zawierać znaczną liczbę zatwierdzeń, które nie miały być częścią tej wersji. Z tego samego powodu ponowne łączenie release-v1.0 bieżącego main zatwierdzenia nie byłoby opcją.

Alternatywną opcją byłoby ręczne ponowne wdrożenie poprawki w gałęzi release-v1.0, ale takie podejście wymagałoby wiele dodatkowej pracy i nie skalowałoby się dobrze w wielu wersjach. Jednak usługa Git oferuje zautomatyzowane rozwiązanie tego problemu w postaci polecenia selekcjonowania cherry-pick.

Co to jest polecenie selekcjonowania w usłudze Git?

Polecenie selekcjonowania, git cherry-pick, umożliwia stosowanie konkretnych zatwierdzeń z jednej gałęzi w innej. Po prostu wykonuje iteracje wybranych zatwierdzeń i stosuje je do gałęzi docelowej jako nowe zatwierdzenia. W razie potrzeby deweloperzy mogą scalać wszelkie konflikty przed ukończeniem przeniesienia na starszą wersję.

Dowiedz się więcej o selekcjonowaniu w usłudze Git.

Wydawanie dla klientów

Gdy wersja produktu jest gotowa do wydania, usługa GitHub upraszcza proces jej pakowania i powiadamiania klientów.

Tworzenie wersji jest równie proste jak wypełnienie formularza:

• Wprowadź tag usługi Git do zastosowania, który powinien być zgodny z semantycznym przechowywaniem wersji, taki jak v1.0.2. Usługa GitHub zarządza procesem tworzenia określonego przez Ciebie tagu usługi Git.
• Wprowadź nazwę wydania. Oto niektóre typowe rozwiązania:
  • Używanie nazwy opisowej
  • Korzystanie z wersji usługi Git
  • Użyj zwięzłego podsumowania zmiany wydania od poprzedniego
  • Używanie nazwy kodu lub frazy losowej
• Podaj informacje o wersji. To zadanie można zautomatyzować za pomocą aplikacji Release Drafter, która analizuje zmiany od poprzedniej wersji i zawiera skojarzone tytuły żądań ściągnięcia.
• Jeśli chcesz udostępnić pliki w ramach wydania, takie jak wstępnie utworzone instalatory, możesz przeciągnąć i upuścić je na formularz. Nie musisz pakować źródła, ponieważ usługa GitHub obsłuży to za Ciebie automatycznie.
• Wskaż, czy wersja wstępna jest dostępna, zaznaczając to pole wyboru. To wskazanie pomaga klientom uniknąć wersji wstępnych, jeśli chcą.

Po opublikowaniu wydania wszyscy obserwujący repozytorium otrzymują powiadomienie.

Dowiedz się więcej o wydaniach usługi GitHub.