Rodzice zawsze mi powtarzali – „ucz się dziecko systematycznie”. Ale dzieci zawsze wiedzą lepiej. Z czasem każdy z nas przekonuje się jednak, że systematyczne podejście ma większy sens niż walka za pięć dwunasta. Co to ma wspólnego z wytwarzaniem oprogramowania? To właśnie temat tego wpisu.

Życie bez ciągłej integracji

Klasyczny proces rozwoju oprogramowania polega na tworzeniu osobnej gałęzi dla każdego projektu. Największym plusem takiego podejścia jest możliwość odłożenia w czasie decyzji, które projekty wejdą w skład wdrożenia. Zamiast planować długofalowo, możemy w oparciu o stan zaawansowania developmentu i testów integrować poszczególne projekty. A jakie są minusy? Scalenie (merge) gałęzi kodu, w których wykonano dużo zmian, jest dość czasochłonne. Zawsze pojawiają się konflikty, wynikające z tego, że jeden fragment kodu został w różny sposób zmodyfikowany w ramach kilku projektów. Liczba takich konfliktów i czas ich rozwiązywania są trudne do przewidzenia. W zależności od wielkości projektu i czasu życia scalanych gałęzi, potrafi to zająć kilka, a nawet kilkanaście dni. Co więcej, proces rozwiązywania konfliktów nie jest bezbłędny. Dość często dochodzi do przypadkowej ingerencji w poprawność procesów biznesowych. Pół biedy, jeżeli po połączeniu projektów wykonujemy pełną procedurę testową. Wtedy tracimy „tylko” czas. Niestety z reguły firmy ograniczają się do weryfikacji regresji. A błędy związane z nowymi zmianami odkrywane są dopiero po wdrożeniu na środowisko produkcyjne.

Co integrujemy?

Ciągła integracja to w zasadzie podstawa nowoczesnego prowadzenia projektów. Zakłada ona, że cały rozwój odbywa się w jednej gałęzi (branchu) kodu. Takie podejście bardzo ogranicza liczbę konfliktów i praktycznie do zera eliminuje problematyczne merge. Szansa, że podczas dwu-, trzymiesięcznej fazy developmentu, dwóch programistów zmodyfikuje tę samą metodę jest bardzo duża. Szansa, że zrobią to tego samego dnia, jest już zdecydowanie mniejsza. Właśnie na takiej systematyce opiera się ciągła integracja. Dodatkowo, skoro mamy już wszystkie zmiany w jednej gałęzi, możemy iść o krok dalej. Standardem jest regularne (nawet po każdej integracji) kompilowanie aplikacji i uruchamianie choćby podstawowego zestawu testów. Zbudowaną paczkę można od razu wdrożyć na środowisko stage’ingowe (preprodukcyjne). Tutaj można na bieżąco weryfikować implementowane zmiany.

Co znaczy ciągle?

Tutaj ważny jest zdrowy rozsądek. Integrowanie zmian co miesiąc jest lepsze niż co dwa miesiące. A robienie tego raz w tygodniu jest lepsze niż raz w miesiącu. Ideałem, do którego dążymy, jest wykonywanie tego codziennie. Standardowy proces polega na pracy w branchu utworzonym specjalnie na potrzeby danej zmiany. Następnie tworzymy pull-request (czyli żądanie integracji). Zmieniony kod jest przeglądany (proces code-review), w celu wykrycia potencjalnych błędów, niespójności czy możliwych usprawnień. W zależności od wyniku przeglądu wraca do poprawy lub jest integrowany. Czy koniecznie trzeba to robić na koniec każdego dnia pracy? Oczywiście nie. Jeżeli wykonanie sensownej zmiany zajmie dwa dni, to właśnie po takim czasie rozpoczynamy proces.

Duże zmiany

A jak radzić sobie z dużymi zmianami? Nie wszystkie prace da się przecież podzielić na małe zadania. Czy wtedy rezygnujemy z ciągłej integracji? Oczywiście, że nie. Zastanówmy się, czy wrzucenie nieskończonego lub nawet niedziałającego kodu jest problematyczne? Na pierwszy rzut oka tak. Jednak czy na pewno? Problem stanowi tylko użycie takiego kodu. Tak długo, jak nie jest on wywoływany, wszystko jest w porządku. Najprostszym sposobem byłoby jego zakomentowanie, jednak to wyklucza nawigowanie po nim czy testowanie go. Zdecydowanie lepszym pomysłem jest zastosowanie feature flag. Działają one na zasadzie przełącznika, który aktywuje lub dezaktywuje określone fragmenty kodu. To z kolei daje nam realną możliwość zastosowania ciągłej integracji, nawet w przypadku długo trwających implementacji.

Jeżeli myślimy o pracy w metodykach zwinnych, to właśnie od wdrożenia praktyki ciągłej integracji powinniśmy zacząć. Bez tego uzyskanie szybkiego feedbacku, który jest podstawą agile, nie będzie możliwe.

Dodaj komentarz

avatar
  Subscribe  
Powiadom o