fbpx

W poprzednim artykule z serii Vademecum DevOps inżyniera zajmowaliśmy się omówieniem cyklu wytwarzania oprogramowania. Integracja ciągła stanowi bardzo ważny element tej „układanki”. Dziś wyjaśnimy Ci dlaczego.

Sprawdź naszą ofertę i weź udział w naszych warsztatach dla DevOpsów

Niezależnie od tego, czy jesteś programistą, testerem, czy innym członkiem zespołu developerskiego. Nieważne, czy budujecie rozbudowany system działający w przeglądarce internetowej, aplikację desktopową, czy być może aplikację mobilną. Prawdopodobnie masz do czynienia z tysiącami lub dziesiątkami tysięcy linii kodu źródłowego, który zorganizowany jest w pewien ułożony sposób, dzięki czemu wszystko działa tak jak powinno.

Niestety sprawa nieco się komplikuje, gdy przychodzi moment, kiedy do Twojej aplikacji musi zostać dodana nowa funkcjonalność lub poprawiony krytyczny błąd (wprowadzony przy okazji poprzednich poprawek). Czy (i jak!) możesz być pewien, że Twoja kolejna zmiana w kodzie nie spowoduje nieoczekiwanych problemów? Co zrobić, aby uchronić się przed katastrofą na produkcji?

Z pomocą przychodzi integracja ciągła, dzięki której dowiesz się, czy kod, który stworzyłeś działa. A jeżeli będzie odpowiednio skonstruowana, to dowiesz się tego bardzo szybko i na bardzo wczesnym etapie Twojej pracy.

Czym jest integracja ciągła?

Integracja ciągła to praktyka wytwarzania oprogramowania, w której programiści pracujący nad wspólnym projektem wprowadzają swoje zmiany do głównej gałęzi kodu od kilku do nawet kilkunastu razy dziennie. Każdorazowo zmiana taka uruchamia proces, którego pierwszym etapem jest ich zbudowanie oraz przetestowanie. Poprawne zakończenie tego etapu otwiera drogę do etapów kolejnych. Błąd natomiast skutkuje poinformowaniem zespołu o napotkanych problemach oraz wymusza na nim wprowadzenie niezbędnych poprawek (zazwyczaj odbywa się to bardzo szybko).

Każda szanująca się firma technologiczna stosuje dziś integrację ciągła. Dzięki niej, proces tworzenia oprogramowania odbywa się w małych iteracjach, jest przewidywalny i niezawodny. Integracja ciągła wymaga zaangażowania wszystkich programistów pracujących nad projektem.

Czy potrzebujesz integracji ciągłej?

Małe i kontrolowane zmiany w systemie są dużo bezpieczniejsze. Dzięki automatyzacji na każdym etapie budowania produktu, programiści unikają konieczności wykonywania powtarzalnej pracy i przy okazji minimalizują ryzyko popełnienia tzw. błędu ludzkiego.

Jak zacząć?

Warunkami koniecznymi wprowadzenia integracji ciągłej są:

  • automatyzacja budowania/kompilacji,
  • automatyzacja testowania,
  • przejrzystość procesu (każdy członek zespołu musi mieć możliwość łatwego śledzenia wyników),
  • częste i małe zmiany w kodzie źródłowym (zamiast rzadkich i dużych).

Jak to działa w praktyce?

W uproszczeniu integracja ciągła z perspektywy programisty może wyglądać w następujący sposób:

  1. Programista tworzy w repozytorium gałąź kodu (tzw. branch), na którym nanosi odpowiednie zmiany w kodzie źródłowym a następnie umieszcza je w centralnym repozytorium.
  2. Narzędzie odpowiedzialne za integrację ciągłą (np. Jenkins) wykrywa pojawienie się zmiany i uruchamia proces budowania oraz testowania jej na środowisku testowym wraz z całą aplikacją. W przypadku problemów, autor zmian jest informowany e-mailowo bądź przez firmowy komunikator (np. Slack) wraz z informacją co nie zadziałało (np. które testy nie zakończyły się pomyślnie).
  3. Jeżeli wstępny proces budowania oraz testowania zakończył się sukcesem, następuje przejście do kolejnej fazy, którą może być umieszczenie zmian na serwerze testowym, na którym odbywać się będą kolejne testy (np. wykonywane manualnie przez zespół QA). W przypadku jakichkolwiek problemów zmiany są wycofywane, a ich autor informowany o tym fakcie – co wymusza na nim wykonanie niezbędnych poprawek.
  4. Weryfikacja na serwerze testowym, która zakończyła się pomyślnie, jest jednocześnie „zielonym światłem” na przeniesienie zaplanowanych zmian w głównej gałęzi repozytorium i skutkuje przejściem do kolejnego etapu integracji, którym może być umieszczenie zmian na serwerze produkcyjnym.
  5. Na końcu zespół informowany jest o wprowadzeniu nowej zmiany.

Oczywiście powyższy schemat jest bardzo umowny i może różnić się w zależności od specyfiki wytwarzanego oprogramowania, czy wielkości oraz składu zespołów.

Zalety integracji ciągłej

Większa produktywność zespołu programistów

Największą zaletą integracji ciągłej jest zwiększona produktywność programistów. Ciągła integracja sprawia, że programiści nie muszą wykonywać żmudnych ręcznych zadań za każdym razem, kiedy wprowadzają zmiany w kodzie źródłowym. Zamiast tego mogą skupić się na zaprogramowaniu funkcji, których wprowadzenie oczekuje biznes.

Krótszy cykl wprowadzania nowych wersji oprogramowania

Dzięki integracji ciągłej zespół może automatycznie budować i testować każdą pojedynczą zmianę kodu źródłowego, a następnie wdrażać ją w wybranych środowiskach. Dzięki temu proces wydawania kolejnych wersji staje się szybszy, bardziej odporny na błędy i bezpieczny.

Szybsze reagowanie na wykryte problemy

Zautomatyzowany proces testowania może obejmować weryfikację następujących obszarów:

  • jakości kodu źródłowego (pod kątem ustalonych standardów)
  • poprawności działania kodu źródłowego (testy jednostkowe),
  • poprawnego działania naniesionych zmian wraz z całością systemu (testy integracyjne),
  • bezpieczeństwa pod kątem ogólnie znanych luk,
  • poprawnego działania z systemu z perspektywy użytkownika końcowego (testy end to end).