Niedawno mieliśmy problem polegający na tym, że funkcja naszej aplikacji internetowej (automatyczna rejestracja) została przełożona przez kierownictwo, ponieważ uważali, że początek był zbyt „zimny”, ale chcieli, aby wszystkie inne funkcje, nad którymi pracowaliśmy, były dostępne.
Problem polega na tym, że ta funkcjonalność została włączona do rozwoju, gdy została ukończona wraz ze wszystkimi innymi funkcjami, które spodziewaliśmy się opublikować w następnym wydaniu, więc nie mogliśmy po prostu połączyć dev -> test -> master, jak to zwykle robimy.
Jak mogliśmy uniknąć tego problemu?
project-management
git
gitflow
Steve
źródło
źródło
Odpowiedzi:
Jednym z podejść jest oznaczanie go przez funkcję. Może żyć w bazie kodu, ale może zostać wyłączony przez konfigurację.
Inną opcją jest zatwierdzenie przywracania, które przywraca scalanie funkcji, aby nie było już rozwijane. Można utworzyć nową gałąź, która cofnie cofanie, i pozostawić do czasu scalenia. Jeśli używasz żądań ściągania Github, możesz to zrobić z łatwością za pomocą przycisku „przywróć scalanie” w połączonym żądaniu ściągnięcia.
źródło
Feature Toggling, jak to nazywał Doc Brown. Pozwala nam to również przetestować tę funkcję (lub jej brak) w środowiskach nieprodukcyjnych. Czasami te funkcje uzupełniają istniejące funkcje, w takim przypadku powinniśmy przeprowadzić testy jednostkowe zarówno dla starego, jak i nowego zestawu funkcji. Każdy test jednostkowy ustawiałby flagę na wszystko, czego potrzebuje do wykonania bieżącego testu.Z perspektywy procesu wymyśl:
Bardziej niż prawdopodobne były po drodze przerwy w komunikacji. Jest to ważne, ponieważ gdy nie działa, proces (y) programowania będą oparte na fałszywym i błędnym zrozumieniu wymagań biznesowych.
źródło
Zapomnij na chwilę o problemie z zarządzaniem i wyobraź sobie, że masz już „funkcję automatycznej rejestracji” w najnowszej wersji produkcyjnej, głęboko zintegrowaną z bazą kodu. Teraz otrzymujesz nowy wymóg dodania „wyłączania” dla „automatycznej rejestracji”. Jak poradziłbyś sobie z tym w przepływie pracy Git?
Sądzę, że zadeklarujesz „wyłączenie automatycznego rejestrowania przez konfigurację” po prostu jako dodatkową funkcję (jest to po prostu forma przełączania funkcji ), więc powinna ona płynnie integrować się z twoim przepływem pracy. Możesz oszacować wysiłek, jeśli chcesz, możesz użyć do tego gałęzi funkcji (lub nie, jeśli nie używasz gałęzi funkcji do takich problemów). I na pewno możesz użyć opisanego przez nas zwyczajowego „scalenia dev -> test -> master”.
I tak właśnie można sobie z tym poradzić w obecnej sytuacji. Z punktu widzenia przepływu pracy git nie powinno mieć znaczenia, czy żądanie zmiany pochodzi z zarządzania dla wersji 1.0, czy też żądanie zmiany jest nowym życzeniem klienta dotyczącym wersji 2.0.
źródło
To jest dokładnie ten problem, który mam z przepływami gitflow i GitHub, i wydaje się, że w aplikacjach internetowych zdarza się to często - lub bardziej jak norma. Wygląda na to, że rozwiązałeś ten problem z mocą wsteczną (wspomnianą powyżej) lub proaktywnie (przykład poniżej).
Oprócz standardowych gałęzi gitflow stworzyłem „gałęzie pakietów”. Pakiet składa się ze wszystkich funkcji gotowych na uat / qa. Zostanie utworzona lista funkcji uat / qa. Są one łączone w pakiet tymczasowy, a pakiet ten jest wdrażany do uat / qa. Wszelkie naprawy błędów mają miejsce w pierwotnej gałęzi funkcji, która jest ponownie umieszczana w pakiecie i wdrażana. Oddziela to nadchodzące wydanie, a także pozwala testować te funkcje razem, zanim znajdą drogę do gałęzi deweloperskiej. Zatwierdzone gałęzie otrzymują żądanie ściągnięcia w fazie rozwoju - zgodnie z procesem gitflow. Funkcje gotowe do testowania można dodawać lub usuwać z gałęzi tymczasowego pakietu i ponownie wdrażać.
Wady obejmują zarządzanie listą pakietów i dodanie innego rodzaju oddziału; jednak oprócz poprawki retro, która moim zdaniem jest za późna, wydaje się to bardziej realnym rozwiązaniem.
W przypadku dodatku GUI optymalne może być zaznaczenie gałęzi funkcji dla każdego wdrożenia pakietu - z myślą o automatyzacji.
źródło