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

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.

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.

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”

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.

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.

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.

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