Przepływ pracy GIT do tworzenia stron internetowych

12

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?

jb510
źródło
BTW, umieszczam to pytanie tutaj na Programmers.SE w oparciu o to: meta.programmers.stackexchange.com/posts/6312/revisions
jb510
Udostępnianie badań pomaga wszystkim . Powiedz nam, co próbowałeś i dlaczego nie spełnia twoich potrzeb. To pokazuje, że poświęciłeś trochę czasu, aby spróbować sobie pomóc, oszczędza nam to powtarzania oczywistych odpowiedzi, a przede wszystkim pomaga uzyskać bardziej konkretną i odpowiednią odpowiedź. Zobacz także How to Ask
gnat
@gnat Nie jestem pewien, co jeszcze mogę się w tym zakresie podzielić? Ponieważ gitflow jest tak zorientowany na wydanie, jest uciążliwy. GitHub-Flow wydaje się być dobry do codziennego wdrażania, ale dziesiątki gałęzi oczekujących na połączenie również wygląda na chaos. Miałem nadzieję, że ktoś odpowie „X jest świetny dla web dev, ponieważ Y”. Jest dobrze ujęty w link, który podałem, chyba mógłbym wyciągnąć z niego cytaty?
jb510
1
@gnat - całkowicie przepisałem pytanie, aby pokazać więcej badań i bardzo precyzyjnie określić odpowiedź, której szukam.
jb510

Odpowiedzi:

7

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.

Hernán Erasmo
źródło
2
+1, kluczem do cd nie jest git ani twój gitflow, ale przepływ pracy CI i dostawy.
Wyatt Barnett,
Dużo o tym myślę. Dzięki za wgląd. FWIW, unikam używania terminu CI, ponieważ nie używamy CI. Może powinniśmy, ale nie robimy tego, jest to zbyt kłopotliwe dla kilkudziesięciu projektów, nad którymi pracujemy w danym tygodniu, krótko-, długoterminowo.
jb510
2
@ jb510 - mamy podobną konfigurację projektu, nie marzyłbym o lataniu bez CI. Przełączanie kontekstów jest dużo łatwiejsze, gdy wszystkie głupie, ale delikatne części są skrypty.
Wyatt Barnett
1
Czasami brak możliwości łatwego wdrożenia CI jest oznaką tego, ile potrzebujesz CI w projekcie. Brak testów jednostkowych? Wdrożenie wszystkich instrukcji? Wiele skomplikowanych kroków wdrażania? Potrzebuje badania.
Kzqai,
1
Przez lata śledziłem to pytanie i odpowiadałem. Miałem nadzieję, że inni również udzielą odpowiedzi, ale sama jest to świetna odpowiedź, więc w końcu oznaczenie jej jako zaakceptowanej (prawdopodobnie powinno to zrobić dawno temu)
jb510