Programowanie oparte na trunku a Git Flow

Aby tworzyć wysokiej jakości oprogramowanie, musimy być w stanie śledzić wszystkie zmiany i w razie potrzeby je odwrócić. Systemy kontroli wersji wypełniają tę rolę, śledząc historię projektu i pomagając scalać zmiany wprowadzone przez wiele osób. Znacznie przyspieszają pracę i dają nam możliwość łatwiejszego wyszukiwania błędów.

Co więcej, praca w zespołach rozproszonych jest możliwa głównie dzięki tym narzędziom. Umożliwiają kilku osobom pracę nad różnymi częściami projektu w tym samym czasie, a później łączenie ich wyników w jeden produkt. Przyjrzyjmy się bliżej systemom kontroli wersji i wyjaśnijmy, jak doszło do rozwoju opartego na trunku i przepływu w Git.

Jak systemy kontroli wersji zmieniły świat

Zanim powstały systemy kontroli wersji, ludzie polegali na ręcznym tworzeniu kopii zapasowych poprzednich wersji projektów. Ręcznie kopiowali zmodyfikowane pliki, aby uwzględnić pracę wielu programistów nad tym samym projektem.

Kosztowało to dużo czasu, miejsca na dysku i pieniędzy.

Patrząc na historię, możemy ogólnie wyróżnić trzy generacje oprogramowania do kontroli wersji.

Przyjrzyjmy się im:

Zauważamy, że wraz z dojrzewaniem systemów kontroli wersji istnieje tendencja do zwiększania możliwości równoległej pracy nad projektami.

Jedną z najbardziej przełomowych zmian było przejście od blokowania plików do łączenia zmian. Umożliwiło to programistom wydajniejszą pracę.

Kolejnym znaczącym usprawnieniem było wprowadzenie systemów rozproszonych. Git był jednym z pierwszych narzędzi wykorzystujących tę filozofię. To dosłownie umożliwiło rozkwit światu open-source. Git umożliwia programistom kopiowanie całego repozytorium w operacji zwanej rozwidleniem i wprowadzanie pożądanych zmian bez konieczności martwienia się o konflikty scalania.

Później mogą rozpocząć pull request, aby scalić swoje zmiany z oryginalnym projektem. Jeśli początkowy programista nie jest zainteresowany włączeniem tych zmian z innych repozytoriów, może samodzielnie przekształcić je w osobne projekty. To wszystko jest możliwe dzięki temu, że nie ma koncepcji centralnego przechowywania.

Style rozwoju

Obecnie najpopularniejszym systemem kontroli wersji jest zdecydowanie Git, którego udział w rynku w 2016 roku wyniósł około 70 procent.

Git został spopularyzowany wraz z rozwojem Linuksa i ogólnie sceny open-source. GitHub, obecnie najpopularniejszy magazyn online dla projektów publicznych, również w znacznym stopniu przyczynił się do jego rozpowszechnienia. Zawdzięczamy Gitowi wprowadzenie łatwych w zarządzaniu pull requestów.

Mówiąc prościej, pull requesty to żądania tworzone przez programistę w celu połączenia zmian, które stworzył z głównym projektem. Obejmuje proces przeglądu tych zmian. Recenzenci mogą dodawać komentarze do każdego elementu, który według nich można poprawić lub który uważa za niepotrzebny.

Po otrzymaniu informacji zwrotnej, twórca może na nią odpowiedzieć, tworząc dyskusję lub po prostu śledzić ją i odpowiednio zmieniać swój kod.

Git to tylko narzędzie. Możesz go używać na wiele różnych sposobów. Obecnie dwa najpopularniejsze style programowania, z jakimi można się spotkać, to Git flow i programowanie oparte na trunku. Dość często ludzie znają jeden z tych stylów i mogą lekceważyć drugi.

Przyjrzyjmy się im obu i dowiedzmy się, jak i kiedy powinniśmy z nich korzystać.

Przepływ Gita

W modelu rozwoju przepływu Git masz jedną główną gałąź programistyczną z ścisłym dostępem do niej. Często nazywa się to develop deweloperską.

Deweloperzy tworzą gałęzie funkcji z tej głównej gałęzi i pracują nad nimi. Po zakończeniu tworzą żądania ściągnięcia. W pull requestach inni programiści komentują zmiany i mogą prowadzić dyskusje, często dość długie.

Uzgodnienie ostatecznej wersji zmian zajmuje trochę czasu. Po uzgodnieniu żądanie ściągnięcia jest akceptowane i scalane z główną gałęzią. Po podjęciu decyzji, że główna gałąź osiągnęła wystarczającą dojrzałość, aby zostać wydana, tworzona jest osobna gałąź, aby przygotować ostateczną wersję. Aplikacja z tej gałęzi jest testowana, a poprawki błędów są wprowadzane do momentu, gdy jest gotowa do opublikowania dla użytkowników końcowych. Po wykonaniu tej czynności łączymy produkt końcowy z gałęzią master i oznaczamy go wersją wydania. W międzyczasie w gałęzi deweloperskiej można develop nowe funkcje.

Poniżej możesz zobaczyć diagram przepływu Git, przedstawiający ogólny przepływ pracy:

Jedną z zalet przepływu Git jest ścisła kontrola. Tylko autoryzowani programiści mogą zatwierdzać zmiany po dokładnym zapoznaniu się z nimi. Zapewnia jakość kodu i pomaga wcześnie eliminować błędy.

Trzeba jednak pamiętać, że to też może być ogromną wadą. Tworzy lejek spowalniający rozwój oprogramowania. Jeśli szybkość jest Twoim głównym problemem, może to być poważny problem. Funkcje opracowane osobno mogą tworzyć długowieczne gałęzie, które mogą być trudne do połączenia z głównym projektem.

Co więcej, pull requesty skupiają się na przeglądzie kodu wyłącznie na nowym kodzie. Zamiast patrzeć na kod jako całość i pracować nad jego ulepszaniem jako takim, sprawdzają tylko nowo wprowadzone zmiany. W niektórych przypadkach mogą one prowadzić do przedwczesnej optymalizacji, ponieważ zawsze można zaimplementować coś, co działa szybciej.

Co więcej, pull requesty mogą prowadzić do rozbudowanego mikrozarządzania, w którym główny programista dosłownie zarządza każdą pojedynczą linią kodu. Jeśli masz doświadczonych programistów, którym możesz zaufać, poradzą sobie z tym, ale możesz marnować ich czas i umiejętności. Może też poważnie demotywować programistów.

W większych organizacjach kolejnym problemem jest polityka biurowa podczas pull requestów. Można sobie wyobrazić, że osoby, które zatwierdzają pull requesty, mogą wykorzystać swoją pozycję do celowego blokowania niektórych programistów przed wprowadzaniem jakichkolwiek zmian w bazie kodu. Mogą to zrobić z powodu braku pewności siebie, podczas gdy niektórzy mogą nadużywać swojej pozycji, aby wyrównać osobiste rachunki.

Zalety i wady Git Flow

Jak widać, wykonywanie pull requestów może nie zawsze być najlepszym wyborem. Powinny być używane tylko w stosownych przypadkach.

Kiedy Git Flow działa najlepiej?

• Kiedy prowadzisz projekt open source.
  Ten styl pochodzi ze świata open-source i tam sprawdza się najlepiej. Ponieważ każdy może wnieść swój wkład, chcesz mieć bardzo ścisły dostęp do wszystkich zmian. Chcesz mieć możliwość sprawdzenia każdego wiersza kodu, ponieważ szczerze mówiąc, nie możesz ufać ludziom, którzy wnoszą swój wkład. Zazwyczaj nie są to projekty komercyjne, więc szybkość rozwoju nie jest problemem.

• Kiedy masz dużo młodszych programistów.
  Jeśli pracujesz głównie z młodszymi programistami, chcesz mieć możliwość dokładnego sprawdzenia ich pracy. Możesz dać im wiele wskazówek, jak robić rzeczy wydajniej i szybciej poprawiać swoje umiejętności. Osoby, które akceptują pull requesty, mają ścisłą kontrolę nad powtarzającymi się zmianami, dzięki czemu mogą zapobiec pogarszaniu się jakości kodu.

  

• Kiedy masz już ugruntowany produkt.
  Ten styl wydaje się również grać dobrze, gdy masz już udany produkt. W takich przypadkach nacisk jest zwykle kładziony na wydajność aplikacji i możliwości ładowania. Taka optymalizacja wymaga bardzo precyzyjnych zmian. Zwykle czas nie jest ograniczeniem, więc ten styl dobrze się tutaj sprawdza. Co więcej, do tego stylu świetnie pasują duże przedsiębiorstwa. Muszą ściśle kontrolować każdą zmianę, ponieważ nie chcą zrujnować swojej wielomilionowej inwestycji.

Kiedy Git Flow może powodować problemy?

• Kiedy dopiero zaczynasz.
  Jeśli dopiero zaczynasz, Git flow nie jest dla Ciebie. Są szanse, że chcesz szybko stworzyć minimalny opłacalny produkt. Wykonywanie pull requestów tworzy ogromne wąskie gardło, które dramatycznie spowalnia cały zespół. Po prostu nie możesz sobie na to pozwolić. Problem z przepływem Git polega na tym, że pull requesty mogą zająć dużo czasu. W ten sposób po prostu nie da się zapewnić szybkiego rozwoju.

• Kiedy musisz szybko wykonać iterację.
  Po dotarciu do pierwszej wersji produktu najprawdopodobniej będziesz musiał kilka razy ją przestawić, aby spełnić potrzeby klientów. Ponownie, wiele gałęzi i żądań ściągnięcia znacznie zmniejsza prędkość rozwoju i nie jest to zalecane w takich przypadkach.

• Kiedy pracujesz głównie ze starszymi programistami.
  Jeśli Twój zespół składa się głównie ze starszych programistów, którzy pracowali ze sobą przez dłuższy czas, to tak naprawdę nie potrzebujesz wspomnianego wyżej mikrozarządzania żądaniami ściągnięcia. Ufasz swoim programistom i wiesz, że są profesjonalistami. Pozwól im wykonywać swoją pracę i nie spowalniaj ich całą biurokracją przepływu Git.

Przepływ pracy programistyczny oparty na trunku

W modelu programistycznym opartym na trunku wszyscy programiści pracują na jednej gałęzi z otwartym do niej dostępem. Często jest to po prostu gałąź master . Zatwierdzają w nim kod i go uruchamiają. To bardzo proste.

W niektórych przypadkach tworzą one krótkotrwałe gałęzie funkcji. Gdy kod na ich gałęzi skompiluje się i przejdzie wszystkie testy, łączą go bezpośrednio z master . Zapewnia to, że rozwój jest naprawdę ciągły i zapobiega tworzeniu przez programistów konfliktów scalania, które są trudne do rozwiązania.

Przyjrzyjmy się przepływowi pracy programistycznemu opartemu na trunku.

Jedynym sposobem przeglądu kodu w takim podejściu jest wykonanie pełnego przeglądu kodu źródłowego. Zwykle długie dyskusje są ograniczone. Nikt nie ma ścisłej kontroli nad tym, co jest modyfikowane w bazie kodu źródłowego — dlatego ważne jest, aby mieć egzekwowalny styl kodu. Deweloperzy pracujący w takim stylu powinni być doświadczeni, abyś wiedział, że nie obniżą jakości kodu źródłowego.

Ten styl pracy może być świetny, gdy pracujesz z zespołem doświadczonych programistów. Pozwala im szybko i bez zbędnej biurokracji wprowadzać nowe usprawnienia. Pokazuje również, że im ufasz, ponieważ mogą wprowadzić kod bezpośrednio do gałęzi master . Programiści w tym przepływie pracy są bardzo autonomiczni — dostarczają produkty bezpośrednio i są sprawdzani pod kątem wyników końcowych w działającym produkcie. W tej metodzie jest zdecydowanie mniej mikrozarządzania i możliwości polityki biurowej.

Jeśli z drugiej strony nie masz doświadczonego zespołu lub z jakiegoś powodu im nie ufasz, nie powinieneś stosować tej metody — zamiast tego powinieneś wybrać przepływ Git. Zaoszczędzi ci to niepotrzebnych zmartwień.

Plusy i minusy rozwoju opartego na bagażniku

Przyjrzyjmy się bliżej obu stronom kosztów — najlepszym i najgorszym scenariuszom.

Kiedy rozwój oparty na trunku działa najlepiej?

• Kiedy dopiero zaczynasz.
  Jeśli pracujesz nad swoim minimalnym opłacalnym produktem, ten styl jest dla Ciebie idealny. Oferuje maksymalną szybkość rozwoju przy minimum formalności. Ponieważ nie ma pull requestów, programiści mogą dostarczać nowe funkcje z prędkością światła. Tylko pamiętaj, aby zatrudnić doświadczonych programistów.

• Kiedy musisz szybko wykonać iterację.
  Gdy dotrzesz do pierwszej wersji swojego produktu i zauważysz, że Twoi klienci chcą czegoś innego, nie zastanawiaj się dwa razy i użyj tego stylu, aby skierować się w nowym kierunku. Nadal jesteś w fazie eksploracji i musisz jak najszybciej zmienić swój produkt.

• Kiedy pracujesz głównie ze starszymi programistami.
  Jeśli Twój zespół składa się głównie z doświadczonych programistów, powinieneś im zaufać i pozwolić im wykonywać swoją pracę. Ten przepływ pracy daje im niezbędną autonomię i umożliwia opanowanie zawodu. Po prostu nadaj im cel (zadania do wykonania) i obserwuj, jak Twój produkt rośnie.

Kiedy rozwój oparty na trunku może powodować problemy?

• Kiedy prowadzisz projekt open source.
  Jeśli prowadzisz projekt typu open source, lepszym rozwiązaniem jest Git flow. Potrzebujesz bardzo ścisłej kontroli nad zmianami i nie możesz ufać współtwórcom. W końcu każdy może wnieść swój wkład. W tym trolle internetowe.

• Kiedy masz dużo młodszych programistów.
  Jeśli zatrudniasz głównie młodszych programistów, lepszym pomysłem jest ścisła kontrola tego, co robią. Rygorystyczne żądania ściągnięcia pomogą im poprawić swoje umiejętności i szybciej znajdą potencjalne błędy.

• Kiedy stworzyłeś produkt lub zarządzasz dużymi zespołami.
  Jeśli masz już dobrze prosperujący produkt lub zarządzasz dużymi zespołami w ogromnym przedsiębiorstwie, lepszym pomysłem może być Git flow. Chcesz mieć ścisłą kontrolę nad tym, co dzieje się z produktem o ugruntowanej pozycji, wartym miliony dolarów. Prawdopodobnie najważniejsza jest wydajność aplikacji i możliwości wczytywania. Taka optymalizacja wymaga bardzo precyzyjnych zmian.

Użyj odpowiedniego narzędzia do właściwej pracy

Jak powiedziałem wcześniej, Git to tylko narzędzie. Jak każde inne narzędzie, należy go odpowiednio używać.

Git flow zarządza wszystkimi zmianami za pomocą żądań ściągnięcia. Zapewnia ścisłą kontrolę dostępu do wszystkich zmian. Świetnie nadaje się do projektów open-source, dużych przedsiębiorstw, firm o ugruntowanych produktach lub zespołu niedoświadczonych młodszych programistów. Możesz bezpiecznie sprawdzić, co jest wprowadzane do kodu źródłowego. Z drugiej strony może prowadzić do rozbudowanego mikrozarządzania, sporów dotyczących polityki biurowej i znacznie spowolnienia rozwoju.

Rozwój oparty na pniu daje programistom pełną autonomię i wyraża większą wiarę w nich oraz ich osąd. Dostęp do kodu źródłowego jest bezpłatny, więc naprawdę musisz być w stanie zaufać swojemu zespołowi. Zapewnia doskonałą szybkość tworzenia oprogramowania i ogranicza procesy. Czynniki te sprawiają, że doskonale sprawdza się podczas tworzenia nowych produktów lub zmiany istniejącej aplikacji w zupełnie nowym kierunku. Działa cuda, jeśli pracujesz głównie z doświadczonymi programistami.

Mimo to, jeśli pracujesz z młodszymi programistami lub osobami, którym nie ufasz w pełni, Git flow jest znacznie lepszą alternatywą.

Wyposażony w tę wiedzę mam nadzieję, że będziesz w stanie wybrać workflow idealnie pasujący do Twojego projektu.