Co się stanie, jeśli funkcja scalona w programowanie zostanie przełożona przez kierownictwo?

53

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

W zależności od twojego punktu widzenia, w jaki sposób chcesz to rozwiązać, to pytanie lepiej pasuje do miejsca pracy, jeśli nie szukasz rozwiązania technicznego.

— Malavos,

74

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.

— Daenyth
źródło

9

Czy flagowanie konfiguracji nie oznacza podwojenia wysiłków związanych z testowaniem tego kodu? Musisz przetestować obie ścieżki.

16

W takim przypadku, ponieważ nie będziesz włączać tej flagi w produkcji, możesz przetestować wyłączoną obudowę dla wydania, a następnie przetestować włączoną obudowę, gdy będzie gotowa do rozpoczęcia produkcji. Powinno to być w przybliżeniu taka sama praca jak testowanie przywracania i ponownego uruchamiania.

— Alan Shutko

4

Powszechnym terminem jest funkcja przełączania . Jeśli istnieje mały „punkt wejścia funkcji”, prawdopodobnie można to zrobić po decyzji zarządu. Jeśli nie, pojawią się problemy zarówno z tą metodą, jak i z dowolną inną.

— Doc Brown

3

Mamy funkcje, które są opracowywane od ponad 6 miesięcy, które są ukryte 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.

— ps2goat

25

Jak mogliśmy uniknąć tego problemu?

Z perspektywy procesu wymyśl:

Kto był decydentem, aby rozpocząć tę pracę?
Dlaczego zmieniła się decyzja o wydaniu tej funkcji?
- Nieodebrane oczekiwania?
- Niezrozumienie?
- Niewystarczające wsparcie biznesowe?
- Brak zaangażowania klienta?

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.

— kraina krańca
źródło

9

+10. Gdy tylko zarząd zaczął wątpić w wydanie tej funkcji, powinien był poinformować deweloperów, aby możliwe usunięcie mogło zostać wzięte pod uwagę przy podejmowaniu decyzji o scaleniu funkcji w celu opracowania.

— Bart van Ingen Schenau

14

To nie jest bardzo konstruktywna odpowiedź - czasami wszystko idzie na boki z różnych powodów. Oczywiście, ważne jest, aby dowiedzieć się, że nie należy go scalać wcześniej niż później, ale to nie znaczy, że w końcu funkcja zostanie uruchomiona w ostatniej chwili. Może zmiany w umowie, może twój klient nie zapłaci, może pojawią się problemy prawne. Nadal musisz poradzić sobie z problemem, zamiast wskazywać winę

— gbjbaanb

11

Jeśli w twojej organizacji są ludzie, którzy są wystarczająco silni, aby odmówić przyznania się do winy, a także wystarczająco dziecinny, aby nie chcieć unikać błędów, to powinieneś nadal pośmiertnie mieć problemy z własnymi informacjami. Po prostu nie chcesz im mówić (lub zapisywać to zbyt otwarcie). To powiedziawszy, kraina krainy nie używa słowa „wina”, a jeśli organizacja interpretuje tę radę jako „dowiedzieć się, kto jest winny”, to sama w sobie stanowi problem dla organizacji. Wszystko to mówi „zrozumieć, dlaczego wystąpił problem”, co jest niezbędne, aby go uniknąć w przyszłości.

— Steve Jessop,

2

Całkowicie się zgadzam, to jest błąd w zarządzaniu, a nie programista.

— durron597

3

@enderland chodzi mi o to, że nie da się uniknąć pewnych problemów, więc musisz zastanowić się, jak naprawić sytuację. Miejmy nadzieję, że nie za często dojdziesz tak daleko, ale to się stanie wcześniej czy później, więc odpowiednio zaplanuj.

— gbjbaanb

19

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.

— Doktor Brown
źródło

Fowler ma naprawdę dobre wyniki, ale nie mogę obsługiwać tej metody wprowadzania funkcji. Skoordynowany wysiłek na rzecz takich zmian wydaje się niepotrzebnym obciążeniem. I może obsługiwać dodanie funkcji przełącza usunąć funkcje po scaleniu, ale budynek w przełączniku jako część wymagań sprawia, że niewygodne.

— Gusdor,

@Gusdor: zobacz moją edycję.

— Dok. Brown

1

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ć.

Dzięki temu mistrz zawsze odzwierciedla stan gotowości do produkcji (może zautomatyzować za pomocą haka)
Programowanie zawsze odzwierciedla ostatni dostarczony (i przetestowany) następny kandydat do wydania

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.

— David Latty
źródło