Tworzenie oprogramowania oparte o gałąź główną

Tworzenie oprogramowania oparte o gałąź główną to praktyka zarządzania kontrolą wersji, w ramach której programiści scalają małe, częste aktualizacje z gałęzią główną. Usprawnia ona fazy scalania i integracji, pomaga we wprowadzeniu procesu CI/CD, poprawia dostarczanie oprogramowania i zwiększa wydajność organizacyjną.

Gdy proces tworzenia oprogramowania dopiero raczkował, programiści nie mieli do dyspozycji nowoczesnych systemów kontroli wersji. Musieli równolegle tworzyć dwie wersje oprogramowania, aby móc śledzić zmiany i w razie potrzeby je cofać. Z czasem okazało się, że proces ten jest pracochłonny, kosztowny i nieefektywny. 

Wraz z rozwojem systemów kontroli wersji pojawiły się różne style tworzenia oprogramowania, dzięki którym programiści mogli łatwiej znajdować błędy, kodować równolegle z innymi programistami i przyspieszyć wydawanie kolejnych wersji. Obecnie większość programistów wykorzystuje jeden z dwóch modeli tworzenia oprogramowania, które zapewniają jego wysoką jakość — Gitflow lub tworzenie oprogramowania oparte o gałąź główną. 

Gitflow, który został spopularyzowany jako pierwszy, to bardziej rygorystyczny model tworzenia oprogramowania, w ramach którego tylko określone osoby mogą zatwierdzać zmiany w kodzie głównym. Pozwala to zachować jakość kodu i zminimalizować liczbę błędów. Tworzenie oprogramowania oparte o gałąź główną jest bardziej otwartym modelem, ponieważ wszyscy programiści mają dostęp do kodu głównego. Dzięki temu zespoły mogą szybko iterować i wdrażać proces CI/CD.

Na czym polega tworzenie oprogramowania oparte o gałąź główną?

Tworzenie oprogramowania oparte o gałąź główną to praktyka zarządzania kontrolą wersji, w ramach której programiści scalają małe, częste aktualizacje z gałęzią główną. Jest to powszechna praktyka wśród zespołów DevOps i część cyklu życia DevOps, ponieważ usprawnia fazy scalania i integracji. Tworzenie oprogramowania oparte o gałąź główną jest wymaganą praktyką w przypadku procesu CI/CD. Programiści mogą tworzyć krótkotrwałe gałęzie z kilkoma małymi commitami — zupełnie inaczej niż w przypadku strategii polegających na tworzeniu długotrwałych gałęzi funkcji. Wraz ze wzrostem złożoności bazy kodu i liczebności zespołu model tworzenia oprogramowania opartego o gałąź główną pomaga w utrzymaniu płynności wydań produkcyjnych.

Gitflow a tworzenie oprogramowania oparte o gałąź główną

Gitflow jest alternatywnym modelem tworzenia gałęzi Git, który wykorzystuje długotrwałe gałęzie funkcji i wiele gałęzi podstawowych. Gitflow obejmuje większą liczbę bardziej długotrwałych gałęzi i większe commity niż tworzenie oprogramowania oparte o gałąź główną. W tym modelu programiści tworzą gałąź funkcji i opóźniają scalenie jej z gałęzią główną do momentu ukończenia pracy nad funkcją. Te długotrwałe gałęzie wymagają więcej współpracy przy scalaniu, ponieważ w ich przypadku istnieje większe ryzyko odchyleń od gałęzi głównej i wprowadzenia sprzecznych aktualizacji. 

Gitflow obejmuje również oddzielne linie podstawowych gałęzi do tworzenia oprogramowania, poprawek, funkcji i wydań. Istnieją różne strategie scalania commitów między tymi gałęziami. Jako że występuje więcej gałęzi, którymi trzeba zarządzać, często mamy do czynienia z większą złożonością, która wymaga dodatkowych sesji planowania i przeglądu ze strony zespołu. 

Tworzenie oprogramowania oparte o gałąź główną jest o wiele bardziej uproszczone, ponieważ skupia się na gałęzi głównej jako źródle poprawek i wydań. W przypadku tego modelu zakłada się, że gałąź główna jest zawsze stabilna, bez problemów i gotowa do wdrożenia.

Korzyści płynące z modelu tworzenia oprogramowania opartego o gałąź główną

Tworzenie oprogramowania oparte o gałąź główną to praktyka, która jest wymagana w przypadku ciągłej integracji. Jeśli procesy kompilacji i testowania są zautomatyzowane, ale programiści pracują nad izolowanymi, długimi gałęziami funkcji, które są rzadko integrowane z gałęzią współdzieloną, pełny potencjał ciągłej integracji nie jest wykorzystywany.

Tworzenie oprogramowania oparte o gałąź główną redukuje trudności związane z integracją kodu. Kiedy programiści kończą nową pracę, muszą scalić nowy kod z gałęzią główną. Nie powinni jednak scalać z nią zmian, dopóki nie potwierdzą, że mogą pomyślnie dokonać kompilacji. Podczas tej fazy mogą pojawić się konflikty, jeśli od momentu rozpoczęcia nowej pracy wprowadzono modyfikacje. Złożoność tych konfliktów rośnie wraz z powiększaniem się zespołów programistów i skalowaniem bazy kodu. Dzieje się tak, gdy programiści tworzą oddzielne gałęzie, które odbiegają od gałęzi źródłowej, a inni programiści jednocześnie scalają nakładający się kod. Na szczęście model tworzenia oprogramowania opartego o gałąź główną ogranicza tę złożoność.

Umożliwia ciągłą integrację kodu

W modelu tworzenia oprogramowania opartego o gałąź główną istnieje repozytorium ze stałym strumieniem commitów płynących do gałęzi głównej. Wprowadzenie zestawu zautomatyzowanych testów i monitorowania pokrycia kodu do tego strumienia commitów umożliwia ciągłą integrację. Kiedy nowy kod jest łączony z gałęzią główną, uruchamiane są zautomatyzowane testy integracji i pokrycia kodu w celu sprawdzenia jego jakości.

Zapewnia ciągły przegląd kodu

Szybkie, małe commity wprowadzane w modelu tworzenia oprogramowania opartego o gałąź główną sprawiają, że proces przeglądu kodu jest bardziej efektywny. Dzięki małym gałęziom programiści mogą szybko zobaczyć i przejrzeć drobne zmiany. Jest to znacznie łatwiejsze w porównaniu z rozbudowaną gałęzią funkcji, w przypadku której weryfikator czyta strony kodu lub ręcznie kontroluje rozległe zmiany w kodzie.

Umożliwia kolejne wydania kodu produkcyjnego

Zespoły powinny wykonywać częste, codzienne scalenia z gałęzią główną. Tworzenie oprogramowania oparte o gałąź główną ma na celu utrzymanie jej w stanie „zielonym”, co oznacza, że jest ona gotowa do wdrożenia w każdej chwili. Zautomatyzowane testy, pokrycie kodu i przeglądy kodu dają pewność, że projekt jest gotowy do wdrożenia do produkcji w dowolnym momencie. Daje to zespołowi możliwość częstego wdrażania do produkcji i wyznaczania kolejnych celów w postaci codziennych wydań produkcyjnych.

Tworzenie oprogramowania oparte o gałąź główną i CI/CD

Wraz ze wzrostem popularności CI/CD modele tworzenia gałęzi były udoskonalane i optymalizowane, co doprowadziło do powstania modelu tworzenia oprogramowania opartego o gałąź główną. Obecnie model ten jest wymagany w procesie ciągłej integracji. Dzięki ciągłej integracji programiści korzystają z tego modelu w połączeniu ze zautomatyzowanymi testami, które są uruchamiane po każdym commicie w gałęzi głównej. Zapewnia to, że projekt działa przez cały czas.

Najlepsze praktyki w zakresie tworzenia oprogramowania opartego o gałąź główną

Tworzenie oprogramowania oparte o gałąź główną pozwala zespołom na szybkie i spójne wydawanie kodu. Poniżej znajduje się lista ćwiczeń i praktyk, które pomogą poprawić rytm pracy Twojego zespołu i stworzyć zoptymalizowany harmonogram wydań.

Tworzenie oprogramowania w małych partiach

Tworzenie oprogramowania oparte o gałąź główną przebiega w szybkim rytmie, co pozwala sprawnie dostarczyć kod do produkcji. Gdyby porównać ten model tworzenia oprogramowania do muzyki, byłoby to szybkie staccato — krótkie, zwięzłe nuty w szybkim tempie (takimi nutami byłyby właśnie commity repozytorium). Utrzymywanie małego rozmiaru commitów i gałęzi umożliwia scalanie i wdrażanie w szybszym tempie. 

Małe zmiany w postaci kilku commitów lub modyfikacji kilku wierszy kodu minimalizują problemy poznawcze. Zespołom znacznie łatwiej jest prowadzić rzeczowe dyskusje i podejmować szybkie decyzje, jeśli zamiast rozległych zmian przeglądają niewielką ilość kodu.

Flagi funkcji

Flagi funkcji dobrze uzupełniają tworzenie oprogramowania oparte o gałąź główną, umożliwiając programistom umieszczanie („wrappowanie”) nowych zmian w nieaktywnej ścieżce kodu i późniejsze jej aktywowanie. Dzięki temu mogą zrezygnować z tworzenia osobnej gałęzi funkcji w repozytorium i zatwierdzić nowy kod funkcji bezpośrednio w gałęzi głównej w ramach ścieżki flagi funkcji. 

Flagi funkcji bezpośrednio sprzyjają wydawaniu aktualizacji w małych partiach. Zamiast tworzenia gałęzi funkcji i oczekiwania na skompilowanie pełnej specyfikacji, programiści mogą tworzyć commity gałęzi wprowadzające flagę funkcji i wypychające nowe commity gałęzi, które kompilują specyfikację funkcji w ramach danej flagi.

Wprowadź kompleksowe zautomatyzowane testowanie

Zautomatyzowane testowanie jest niezbędne w każdym nowoczesnym projekcie tworzenia oprogramowania, w ramach którego ma być wykorzystywany proces CI/CD. Istnieje wiele rodzajów zautomatyzowanych testów, które są uruchamiane na różnych etapach pipeline'u wydania. Krótkie testy jednostkowe i integracyjne są wykonywane podczas tworzenia i po scaleniu kodu. Dłuższe, kompleksowe testy z pełnym stosem są przeprowadzane w późniejszych fazach pipeline'u w pełnym środowisku stagingowym lub produkcyjnym.

Zautomatyzowane testy pomagają w tworzeniu oprogramowania opartym o gałąź główną poprzez utrzymywanie małych partii podczas scalania nowych commitów przez programistów. Pakiet zautomatyzowanych testów przegląda kod pod kątem wszelkich problemów i automatycznie go zatwierdza lub odrzuca. Pomaga to programistom szybko tworzyć commity i poddawać je zautomatyzowanym testom, aby sprawdzić, czy pojawiają się przez nie nowe problemy.

Wykonywanie asynchronicznych przeglądów kodu

W przypadku tworzenia oprogramowania opartego o gałąź główną przegląd kodu powinien być wykonywany natychmiast, a nie umieszczany w systemie asynchronicznym w celu późniejszego wykonania. Zautomatyzowane testy zapewniają warstwę zapobiegawczego przeglądu kodu. Kiedy programiści są gotowi do przejrzenia pull requesta członka zespołu, mogą najpierw sprawdzić, czy zautomatyzowane testy zakończyły się powodzeniem, a pokrycie kodu wzrosło. W ten sposób weryfikator uzyskuje natychmiastowe potwierdzenie, że nowy kod spełnia określone specyfikacje. Wówczas może on skupić się na optymalizacji.

Korzystaj z maksymalnie trzech aktywnych gałęzi w repozytorium kodu aplikacji

Po scaleniu gałęzi najlepszą praktyką jest jej usunięcie. Repozytorium z dużą liczbą aktywnych gałęzi wiąże się z pewnymi niefortunnymi skutkami ubocznymi. Chociaż może pomóc zespołom zorientować się, jakie prace są w toku, badając aktywne gałęzie, korzyść ta przepada, jeśli wciąż istnieją nieaktualne i nieaktywne gałęzie. Niektórzy programiści używają interfejsów użytkownika Git, które mogą stać się nieporęczne podczas ładowania dużej liczby zdalnych gałęzi.

Scalaj gałęzie z gałęzią główną co najmniej raz dziennie

Wydajne zespoły korzystające z modelu tworzenia oprogramowania opartego o gałąź główną powinny zamykać i scalać wszystkie otwarte i gotowe do scalenia gałęzie przynajmniej codziennie. To ćwiczenie pomaga utrzymać odpowiedni rytm pracy i nadaje rytm monitorowania wydań. Zespół może następnie oznaczyć gałąź główną pod koniec dnia jako commit wydania, co ma przydatny skutek uboczny w postaci generowania codziennego przyrostu wydania w modelu Agile.

Mniejsza liczba zamrożeń kodu i faz integracji

Zespoły CI/CD pracujące zgodnie z metodyką Agile nie powinny potrzebować planowanych zamrożeń kodu ani przerw na czas faz integracji — choć organizacja może ich potrzebować z innych powodów. Przymiotnik „ciągła” lub „ciągłe” w nazwach procesów CI/CD sugeruje, że aktualizacje stale napływają. Zespoły wykorzystujące model tworzenia oprogramowania opartego o gałąź główną powinny starać się unikać blokowania zamrożeń kodu i odpowiednio planować pracę, tak aby pipeline wydania nie został zastopowany.

Kompiluj szybko i wykonuj natychmiast

Aby utrzymać szybki rytm wydań, należy zoptymalizować czas wykonywania kompilacji i testów. Narzędzia kompilacji CI/CD powinny w stosownych przypadkach używać warstw pamięci podręcznej, aby uniknąć drogich obliczeń związanych z elementami statycznymi. Testy powinny być zoptymalizowane pod kątem użycia odpowiednich stubów dla usług innych firm.

Podsumowując…

Model tworzenia oprogramowania opartego o gałąź główną jest obecnie najczęściej stosowany przez wydajne zespoły inżynierów, ponieważ pozwala on nadać i utrzymać odpowiedni rytm wydawania oprogramowania z wykorzystaniem uproszczonej strategii tworzenia gałęzi Git. Ponadto model ten zapewnia zespołom inżynierów większą elastyczność i lepszą kontrolę nad sposobem dostarczania oprogramowania do użytkownika końcowego.

Bitbucket firmy Atlassian ma wbudowane funkcje CI/CD, które umożliwiają tworzenie oprogramowania oparte o gałąź główną. Wypróbuj teraz.