Close

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

Dowiedz się, dlaczego ta praktyka zarządzania kontrolą wersji jest powszechna wśród zespołów DevOps.

Kev Zettler — zdjęcie portretowe
Kev Zettler

Full stack web developer


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.

Poznaj rozwiązanie

Tworzenie i obsługa oprogramowania za pomocą Open DevOps

Materiały pokrewne

Jak zacząć stosować ciągłą integrację

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 już teraz.

Kev Zettler
Kev Zettler

Kev jest wiodącym web deweloperem i przedsiębiorcą z ponad dziesięcioleciem doświadczenia w tworzeniu produktów i zespołów za pomocą metodologii Agile. Jest zapalonym twórcą, autorem i edukatorem w zakresie nowych technologii open source, takich jak DevOps, kryptowaluty i VR/AR. W wolnym czasie bierze udział w jamach poświęconych tworzeniu gier indie.


Udostępnij ten artykuł

Zalecane lektury

Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.

Ilustracja DevOps

Społeczność DevOps

Ilustracja DevOps

Przeczytaj blog

Ilustracja przedstawiająca mapę

Zacznij korzystać za darmo

Zapisz się do newslettera DevOps

Thank you for signing up