Trend branży „rozwijającej się” zanika


82

Zauważyłem ostatnio, że patrząc na niektóre popularne projekty na GitHub, nie ma żadnego developoddziału. W rzeczywistości przewodnik GitHub Flow też o tym nie wspomina. Z mojego zrozumienia, masterzawsze powinna być całkowicie stabilna i odzwierciedlać produkcję. Jeśli programiści pracują nad gałęziami funkcji, a następnie scalają je ze sobą masterpo zakończeniu, oznacza to, że okres, w którym funkcje / poprawki są scalane, mastera mastergałąź jest w rzeczywistości nowsza niż produkcyjna.

Czy nie ma większego sensu, aby zespół tworzył gałęzie funkcji / naprawiania develop, łączył się z nimi ponownie, a następnie, gdy następna wersja jest całkowicie gotowa do wydania, developłączy się masteri tworzy tag? Wyobraź sobie, że ludzie łączą się od razu master, a podczas produkcji zgłaszany jest błąd, który staje się trudny do naprawienia, ponieważ masterbaza kodów gałęzi zmieniła się znacząco. Następnie twórcy muszą po prostu powiedzieć użytkownikowi, aby poczekał do następnej wersji, aby zobaczyć, że problem został rozwiązany.

EDYCJA: To pytanie jest inne niż „rozgałęziać się czy nie rozgałęziać”. W szczególności odnosi się do osób, które odchodzą od korzystania z gałęzi developerskiej, oraz powodów, które ją otaczają, ponieważ od dawna jest to reklamowana najlepsza praktyka.


11
Istnieje wiele możliwych przepływów pracy, które umożliwia git. Nie należy oczekiwać, że gitflow lub github flow będą używane we wszystkich projektach.

Bardzo interesujące pytanie. Pracowałem wiele lat w nvie.com/posts/a-successful-git-branching-model i muszę powiedzieć, że mi się podoba. Najbardziej podoba mi się to, że a) master jest tym, co jest w produkcji, i dotyczy to również wersji oraz b) istnieje wyraźna różnica między poprawką a funkcją, są one inicjowane i łączone odpowiednio w master i rozwijają się. Jednak po tej dyskusji zaczynam mieć wątpliwości, czy to nadmiernie komplikuje sytuację. Jakieś opinie na ten temat?
Aspasia

1
Nienawidzę koncepcji, że mistrz jest zapisem tego, co jest w produkcji. Jeśli musimy wiedzieć, co jest w produkcji, powinniśmy po prostu zapytać o produkcję, a nie polegać na wzorcu dokładnie odzwierciedlającym to, co jest w produkcji.
Jim V

Odpowiedzi:


52

Wywodzi się z myślenia CI, gdzie integracja odbywa się kilka razy dziennie.

Są wady i zalety obu.

W naszym zespole zrezygnowaliśmy również z działu rozwoju, ponieważ uważaliśmy, że nie zapewnia on żadnych dodatkowych korzyści, ale kilka wad. Skonfigurowaliśmy nasze oprogramowanie CI (Teamcity), aby zrekompensować wady:

  1. Włącz wdrożenie konkretnego zatwierdzenia. Innymi słowy: nie wdrażamy oddziału. Wdrażamy zatwierdzenie.
  2. Możemy wdrożyć zarówno master, jak i oddziały, zaczynając od poprawki / prefiksu.

Powodem tego jest fakt, że wszystkie żądania ściągania zawierają potencjalnie możliwy do zwolnienia kod, ale to nie znaczy, że wdrażamy wszystkie zatwierdzenia w master.

Głównym powodem, dla którego porzuciliśmy gałąź rozwoju, jest to, że zwykle robi się ona zbyt duża i zbyt czasochłonna, aby zobaczyć, co faktycznie zawiera. Jeśli wdrożyliśmy coś nieco przedwcześnie, po prostu rozgałęziamy gałąź poprawki i wdrażamy to bezpośrednio.


10
Pracując z gałęzią rozwoju przez rok lub dwa, tylko po to, aby od czasu do czasu połączyć ją w mistrza, mogę po prostu powiedzieć: amen, porzuć tę rzecz:]
stijn

Ciekawy. Zakładam więc, że kiedy wypuszczasz wersję 1.3, na przykład oznaczasz określone zatwierdzenie master, więc jeśli błąd pojawi się później, gdy masterjest w stanie ciągłego przepływu, możesz łatwo rozgałęzić poprawkę znacznika 1.3?
ffxsam,

5
Powiedziałbym, że korzyść z „rozwoju” zależy w dużej mierze od rodzaju tworzonego oprogramowania, sposobu jego wdrażania oraz tego, czy potrzebujesz obsługiwać wiele wersji na żywo, czy nie.
axl

1
@ffxsam nie potrzebujemy nawet tagowania, ponieważ śledzimy, który git id jest obecnie wdrażany. Jest to zalogowane zarówno w TeamCity, jak i rozgałęzione we wdrożonych bibliotekach DLL oraz w portalu zarządzania lazurami. Dlatego nie odczuliśmy potrzeby dalszego tagowania poza automatycznym tagowaniem przez TeamCity. Jeśli czujesz, że tagi pasują, lepiej pracujesz, to również by to rozwiązało. Ale tak, w zasadzie odejdź bezpośrednio od obecnie wdrażanej zmiany, aby utworzyć gałąź poprawki.
Esben Skov Pedersen

25

Oddział rozwoju ma większe znaczenie, jeśli proces wydawania jest złożony i potrzebujesz poważnych kandydatów do wydania.

Wyobraź sobie na przykład, że piszesz oprogramowanie, które jest oprogramowaniem układowym w samochodach. Jest to ... nietrywialne do naprawienia i jest prawdopodobne, że każda wersja miałaby kompleksowy zestaw testów innych niż integracja / testy uruchomione na prawdziwym sprzęcie.

W takim przypadku bardziej sensowne może być odizolowanie „kandydata do wydania” w gałęzi innej niż master (takiej jak „develop”). Dzięki temu Twój zespół przeprowadzający te testy ma oddział, w którym można scalać funkcje.

Aplikacje internetowe lub inne łatwo aktualizowane oprogramowanie nie mają tego ograniczenia.

Należy jednak pamiętać, że:

  • Wiele (większość?) Projektów na githubie nie ma tego rodzaju ograniczeń
  • Główny „mistrz” służy temu samemu celowi
  • Przepływ pracy „make PR vs. master” jest o wiele bardziej uniwersalny niż „tworzenie PR przeciwko gałęzi, której nie znasz od razu w tym repozytorium”

18

Są dwie filozofie, które widziałem w projektach i myślę, że wybór jest kwestią gustu:

  1. Wyznacz „master” jako wydanie produkcyjne i rozwijaj w gałęzi „develop”.

  2. Rozwijaj w 'master' i miej inną gałąź dla stabilnych wydań produkcyjnych. Ma to jeszcze większy sens, jeśli twój projekt ma wiele gałęzi wydania jednocześnie (np. Obecnie preferowana jest wersja 1.8, ale nadal utrzymujesz wersję 1.7).

Oba są powszechnymi podejściami i mają swoje zalety i wady.


Zgadzam się z Tobą. Wolimy mieć gałęzie wydania i utrzymywać je do następnego wydania do produkcji. Jeśli musimy wprowadzić jakieś poprawki, sprawdzamy ostatnią gałąź wydania i pracujemy nad tym, a następnie łączymy te poprawki z gałęzią master / develop
Johnny

Dokładnie. To, co powinien zrobić mistrz, to głównie semantyka. Podstawową rzeczą, aby się dobrze postarać, jest unikanie konieczności utrzymywania synchronizacji dwukierunkowej wielu wiecznie żyjących gałęzi, chyba że masz naprawdę dobry powód. Oddział „master” w Git Flow jest tylko opóźnioną repliką „develop”, więc tak naprawdę się nie liczy. Anty-wzorzec umożliwia głównej gałęzi programistycznej przechowywanie zmian, które nigdy nie wchodzą w skład wydania, co jest szokująco powszechną praktyką, którą widziałem. Oba wspomniane powyżej modele zapobiegają temu, dlatego działają.
John Michelau

7

Wydania do produkcji można oznaczać, więc sytuację, która została wydana, można zawsze odtworzyć bez poświęcania na to całej gałęzi.

Jeśli krytyczny błąd zostanie wykryty w produkcji w momencie, gdy nie można wydać mastera, łatwo jest sprawdzić znacznik i uruchomić z niego nową gałąź „hotfixes-for-release-1.2.0”. Ale to powinno być raczej rzadkie.

Przez większość czasu w naszych aplikacjach internetowych master zmienił się od czasu ostatniego wydania, ale nie bardzo, więc możemy po prostu zrobić nowe wydanie od master, które ma poprawkę. W każdym razie pomaga to robić bardzo częste wydania.


5

Jeśli programiści pracują nad gałęziami funkcji, a następnie po ich scaleniu w master, oznacza to, że jest czas, w którym funkcje / poprawki są scalane, mastera mastergałąź jest w rzeczywistości nowsza niż produkcyjna.

...

Wyobraź sobie, że ludzie łączą się bezpośrednio w master, a podczas produkcji zgłaszany jest błąd, który staje się trudny do naprawienia, ponieważ baza kodów gałęzi master uległa znacznej zmianie.

To nie jest Github Flow.

Oto proces wdrażania / scalania Github Flow, zgodnie z linkiem:

Rozmieścić

Po sprawdzeniu żądania ściągnięcia i przejściu testów przez oddział można wdrożyć zmiany, aby zweryfikować je w środowisku produkcyjnym. Jeśli twoja gałąź powoduje problemy, możesz ją wycofać, wdrażając istniejący wzorzec do produkcji.

Łączyć

Teraz, gdy zmiany zostały zweryfikowane podczas produkcji, czas scalić kod z gałęzią master.

(Moje podkreślenie)

Innymi słowy, masternigdy nie wyprzedzi produkcji. Podobnie, masterzawsze będzie w stabilnym, możliwym do zwolnienia stanie (oprócz nieodkrytych błędów), ponieważ wszystko jest sprawdzane, testowane i wdrażane do produkcji przed połączeniem master.


Miły! Ma to intuicyjny sens - masterzawsze jest to pozycja wycofania, jeśli gałąź funkcji, którą wprowadzasz do produkcji, zawiedzie. Jeśli nie, łączy się masteri staje się nowym awarią. Lubię to.
Bill Horvath,

1

Widzę problem polegający na tym, że wdrażanie / scalanie przepływu Git / Hub zakłada, że ​​jedna funkcja jest rozwijana / testowana / łączona / wdrażana jednocześnie - i często z mojego doświadczenia wynika, że ​​tak nie jest. Jeśli połączyliśmy funkcję na raz, istnieje większa szansa na problemy z regresją - stwierdzone dopiero po scaleniu funkcji w master i prawdopodobnie w produkcji.

Musi istnieć sposób przetestowania wielu funkcji, scalenia wielu funkcji i wdrożenia ich. Korzystałem z „gałęzi pakietu” (gałęzi utworzonej z systemu głównego z połączonymi z nią gałęziami funkcji gotowych do testowania), która jest wdrażana do qa / uat. Korekty podczas uat mają miejsce tylko w gałęzi funkcji, a te zostają ponownie scalone z gałęzią pakietu. Po zatwierdzeniu podsekcji gałęzi pakietu, tylko te zatwierdzone funkcje w pakiecie zostaną poproszone o opanowanie - a cykl jest ciągły.

Używam tego z Gitflow, ale zastanawiam się, czy użyć go do przepływu GitHub. Wydaje się, że wiele cech QA / UAT przy danym problemie czasowym ma znaczenie. Innym problemem związanym z przepływem GitHub jest to, że zakłada on wszystkich programistów sr i nie zawsze tak jest.

Wolę używać przepływu GitHub ze względu na jego uproszczenie. Wydaje mi się, że dzięki funkcji podobnej do pakietu byłoby lepiej przygotowane. Możliwe, że pakiet jest podobny do wydania; wciąż jednak zastanawiam się nad tym.

Inną kwestią jest to, że proces żądania ściągania odbywa się na końcu przed scaleniem z master; Czasami jednak chcesz napisać recenzję kodu przed testowaniem qa firmy - a więc na długo przed scaleniem

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.