Przepływ pracy GIT do tworzenia stron internetowych

Dawno temu mały zespół programistów internetowych, z którymi pracuję, zaczął używać git do tworzenia stron internetowych. Wtedy właśnie po prostu zobowiązaliśmy się bezpośrednio do inscenizacji lub masteringu, a następnie często się połączyliśmy. To było lepsze niż nic, ale był też bałagan.

Nie tak dawno temu przyjęliśmy przepływ pracy gitflow. Chociaż z pewnością jest lepszy niż chaos, który pojawił się wcześniej, wydaje się nieco niewygodny i nadmiernie zorientowany na wydanie / kamień milowy. Moi koledzy deweloperzy często proszą mnie o wyjaśnienie, jak to powinno działać, a co powinno się łączyć, a co nie. Zasadniczo wydaje się, że nie nadaje się do prac programistycznych, w których często wdrażamy kod i nie śledzimy konkretnych etapów wydania.

Na podstawie ostatniej sugestii znajomych zacząłem patrzeć na GitHub Flow . Czytanie tutaj postu Scotta Chakona doskonale uderza w ból:

Dlaczego więc nie używamy git-flow w GitHub? Głównym problemem jest to, że cały czas wdrażamy. Proces git-flow został zaprojektowany głównie wokół „wydania”. Tak naprawdę nie mamy „wydań”, ponieważ wdrażamy je do produkcji każdego dnia - często kilka razy dziennie.

FWIW, przyjrzałem się także temu fajnemu podsumowaniu przepływów pracy na stronie Atlassian: https://www.atlassian.com/git/workflows#!workflow-feature-branch

Jednak WSZYSTKIE wyglądają na kiepskie wybory do tworzenia stron internetowych w małym zespole i ponownie nastawione na główne wersje aplikacji, które nie są częste / codzienne.

Pytanie dotyczy SE, która chce porównać git-flow z github-flow /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -pływ

To ogólnie dobra odpowiedź, ale jak wspomniałem w moim komentarzu poniżej meta.programmers.SE wydaje się wskazywać, że pytania o ogólne najlepsze praktyki przepływu pracy należą tutaj i liczyłem na szerszą listę możliwych odpowiedzi niż tylko git-flow i github -flow, będąc specyficznym dla rozwoju sieci. Dlatego myślę, że uzasadnia to nowe pytanie.

Dzięki temu, jaki jest najlepszy / preferowany przepływ pracy oparty na git dla małego zespołu programistów pracującego nad projektami o dość ciągłym wdrażaniu? Czy to github-flow czy coś innego?

Najpierw chciałbym zrobić krótkie podsumowanie różnych przepływów pracy, które analizowałeś i uważasz, że nie są odpowiednie dla rodzaju rozwoju, nad którym pracujesz:

• Scentralizowane ( źródło ): prawie jak przepływ pracy SVN, ale teraz w środowisku rozproszonym. Każdy programista pracuje na osobistej kopii masteri przekazuje zmiany origin/masterbezpośrednio lub poprzez żądanie ściągnięcia.

• Gałąź funkcji ( źródło ): Cóż, to. Każdy programista pracujący nad konkretną funkcją powinien pracować w określonej gałęzi przeznaczonej tylko dla tej funkcji. Ta gałąź funkcji powinna zostać utworzona z masterlub z innej gałęzi funkcji. W końcu wszystko ponownie się łączy master.

• Gitflow ( Źródło ): Dwie główne gałęzie śledzą historię projektu developoraz master. Kolejne 3 oddziały nazywane hotfix, releasea featurezmiany dokonane bezpośrednio do ładowni masterdo mocowania krytycznych błędów produkcyjnych, zmiana numeru wersji i inne szczegóły przed uwolnieniem GMO lub pracy na określonej cechy, tak jak gałąź funkcji , odpowiednio.

• Przepływ GitHub ( źródło ): programiści tworzą featuregałąź od master. Zmiany są wypychane poprzez żądanie ściągnięcia. Zmiany zaakceptowane w master zostaną wdrożone natychmiast przez Gota Hub Bot.

W części dotyczącej pytania dotyczącej rozwoju odpowiedź zależy od pochodzenia zespołu. Czy pochodzą ze środowiska SVN? Następnie powinieneś zastosować podejście scentralizowane, ponieważ jest ono najbardziej podobne do SVN. Czy czują się komfortowo pracując z Git? Być może nie powinieneś próbować dostosowywać przepływu pracy swojego zespołu do żadnego z nich, ale wdrożyć własny, dostosowany do twoich potrzeb, który, jeśli dobrze rozumiem, to elastyczność programowania i szybkie wdrażanie.

Myślę też, że powinieneś skupić się na poprawie tego drugiego. Jak składa się Twój proces wdrażania ? W „ Ciągłym dostarczaniu: niezawodne wydania oprogramowania poprzez automatyzację kompilacji, testowania i wdrażania ” autorzy identyfikują możliwe przyczyny rzadkich wdrożeń, z których niektóre to:

• Proces wdrażania nie jest zautomatyzowany.
• Testowanie zajmuje dużo czasu.
• Ludzie nie rozumieją procesu kompilacji / testowania / wdrażania.
• Programiści nie są dyscyplinowani w utrzymywaniu działania aplikacji poprzez wprowadzanie niewielkich, stopniowych zmian, a więc często psują istniejącą funkcjonalność

Czy któryś z nich brzmi jak coś, co można poprawić? Być może mógłbyś powiedzieć nam trochę więcej o tym, jak Ty i Twój zespół radzicie sobie z tą częścią projektu.