Dla zespołów Agile i DevOps zajmujących się tworzeniem oprogramowania system Git jest de facto systemem kontroli wersji oraz zasadniczym elementem łańcucha narzędzi DevOps. Ten projekt Open Source objęty bardzo dobrym wsparciem jest na tyle elastyczny, że można go stosować w wielu różnych przepływach pracy dostosowanych do potrzeb dowolnego zespołu programistycznego. W przeciwieństwie do scentralizowanego rozproszony charakter tego systemu zapewnia mu najwyższą wydajność działania, a programistom swobodę eksperymentowania w środowisku lokalnym i publikowania zmian dopiero, gdy będą gotowe do udostępnienia zespołowi.
Oprócz korzyści, jakie przynoszą elastyczność i rozproszony charakter, system Git cechują pewne kluczowe funkcje, które wspierają zespoły programistyczne Agile i DevOps oraz zwiększają ich możliwości. Pomyśl o systemie Git jako o składniku procesu programistycznego Agile i DevOps: zmiany można wypychać do pipeline'u wdrożenia szybciej niż w przypadku prac z monolitycznymi wydaniami i scentralizowanymi systemami kontroli wersji. System Git działa w taki sam sposób, jak Twój zespół Agile i DevOps (i należy do tego dążyć).
Porada 1: Zacznij myśleć o zadaniach jako o gałęziach w systemie Git
System Git wchodzi do gry, gdy funkcje zostaną sprecyzowane i dodane do harmonogramu produktu, a zespół programistyczny będzie gotowy do pracy. Cofnijmy się w tym miejscu o krok, aby przeprowadzić błyskawiczny intensywny kurs opracowywania funkcji według zasad Agile: zespoły produktowe, projektowe, QA oraz inżynierskie przeprowadzają spotkanie początkowe, w trakcie którego wypracowują wspólny oraz opracowywanej funkcji (wymagania), określają zakres projektu oraz zadania, na które trzeba podzielić funkcję, aby ją ukończyć. Te zadania — nazywane również historyjkami użytkowników — przypisuje się wówczas do poszczególnych programistów.
Jest to moment, w którym system Git zaczyna wpisywać się przepływ pracy Agile. W Atlassian tworzymy nową gałąź dla każdego zgłoszenia z osobna. Bez względu na to, czy jest to nowa funkcja, poprawka błędu czy drobne ulepszenie istniejącego kodu, każda zmiana kodu ma własną gałąź.
Tworzenie gałęzi jest proste i umożliwia zespołom łatwą współpracę w obrębie jednej centralnej bazy kodu. Gdy programista tworzy gałąź, w praktyce ma do dyspozycji własną, wyizolowaną wersję bazy kodu, w której może wprowadzać zmiany. Dla zespołu Agile oznacza to, że dzięki podziałowi funkcji na historyjki użytkowników, a następnie gałęzie, zespół programistyczny może zajmować się poszczególnymi zadaniami indywidualnie i pracować z większą wydajnością na tym samym kodzie, ale w odrębnych repozytoriach. Prace się nie dublują, a dzięki możliwości skoncentrowania się na niewielkich fragmentach prac w repozytoriach odrębnych od repozytorium głównego, liczba zależności spowalniających proces programistyczny jest mniejsza.
Oprócz tworzenia gałęzi zadań istnieją również inne rodzaje tworzenia gałęzi w systemie Git i nie wykluczają się one nawzajem. Można na przykład tworzyć gałęzie wydań. Pozwala to programistom ustabilizować i wzmocnić prace zaplanowane w ramach konkretnego wydania, bez wstrzymywania innych programistów pracujących nad przyszłymi wydaniami.
Po utworzeniu gałęzi wydania należy regularnie scalać ją z gałęzią główną, aby mieć pewność, że prace nad funkcją zostaną uwzględnione w przyszłych wydaniach. Aby zminimalizować dodatkowe obciążenie, najlepiej utworzyć gałąź wydania możliwie jak najbliżej zaplanowanej daty wydania.
Porada 2: Wiele gałęzi można testować indywidualnie — wykorzystaj to
Gdy gałęzie zostaną uznane za ukończone i będą gotowe do przeglądów kodu, system Git odegra kolejną kluczową rolę w przepływie pracy programowania Agile — zostanie wykorzystany na potrzeby testowania. Skuteczne zespoły Agile i DevOps stosują przeglądy kodu i konfigurują automatyczne testy (w ramach ciągłej integracji lub ciągłego dostarczania). Aby ułatwić przeglądy i testowanie kodu, programiści mogą w prosty sposób, za pomocą pull requestu, powiadomić innych członków zespołu, że praca wykonana w ramach gałęzi jest gotowa do przeglądu i wymaga sprawdzenia. Mówiąc wprost, pull request jest sposobem poproszenia innego programisty o scalenie jednej z Twoich gałęzi z gałęzią główną oraz poinformowania, że gałąź jest gotowa do testowania.
Dzięki odpowiednim narzędziom serwer ciągłej integracji może kompilować i testować Twoje pull requesty, zanim jeszcze je scalisz. Zyskasz w ten sposób pewność, że scalenie nie spowoduje problemów. Ta pewność generalnie ułatwia poprawianie błędów i usuwanie konfliktów, ponieważ system Git zna różnice między gałęzią a główną bazą kodu, które pojawiły się od momentu wyodrębnienia gałęzi.
Długo opracowywana gałąź funkcji, która nie jest scalana z gałęzią główną, może negatywnie wpłynąć na zwinność i możliwość stosowania iteracji. Jeśli masz taką długoterminową gałąź funkcji, pamiętaj, że de facto masz dwie odmienne wersje bazy kodu, co spowoduje zwiększanie liczby poprawek błędów i konfliktów. Najlepszym rozwiązaniem jest tworzenie krótkoterminowych gałęzi funkcji. Taki rezultat można uzyskać przez podział historyjek użytkowników na mniejsze zadania, uważne planowanie sprintów oraz scalanie kodu na wczesnym etapie w celu dostarczenia ich jako domyślnie ukrytych funkcji.
Porada 3: System Git zapewnia przejrzystość i wysoką jakość programowania Agile
W połączeniu systemu Git z metodyką Agile chodzi o wydajność, testowanie, automatyzację i ogólną zwinność. Po scaleniu gałęzi z gałęzią główną przepływ pracy Agile został ukończony. W podobny sposób scalenie kodu za pomocą pull requestów oznacza, że gdy kod będzie ukończony, będziesz dysponować dokumentacją potwierdzającą, że Twoja praca dostała zielone światło, że inni członkowie zespołu zatwierdzili kod oraz że ten kod jest gotowy do wydania. To pozwala zespołom Agile posuwać prace naprzód w dużym tempie, z gwarancją częstych wydań, co jest cechą wyróżniającą fantastyczne zespoły Agile.
Kluczem do programowania Agile jest przyjęcie regularnej kadencji wydań. Aby system Git sprawdzał się w Twoim przepływie pracy Agile, musisz dbać o to, aby Twoja gałąź główna zawsze ma zielone światło. To oznacza, że jeśli funkcja nie jest gotowa, poczekaj na następne wydanie. W przypadku stosowania krótszych cykli wydawania nie powinno to stanowić problemu.
