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
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.
Udostępnij ten artykuł
Następny temat
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.
Społeczność DevOps
Przeczytaj blog
