Ciągła integracja (ang. continuous integration), ciągłe dostarczanie (ang. continuous delivery) i DevOps to trzy bardzo popularne terminy, dla których niejeden programista ostatnimi czasy stracił głowę. Na pierwszy rzut oka wszystkie te określenia mogą wydawać się nieco egzotyczne. Jednakże ich zrozumienie, a co ważniejsze, prawidłowe wdrożenie w całej organizacji dostarcza wymiernych korzyści nie tylko zespołowi wytwórczemu, ale również, a może i przede wszystkim, zespołowi produktowemu.
Głównym, aczkolwiek niejedynym celem, z punktu widzenia Product Managera, powyższych praktyk jest jak najszybsze uzyskanie wartościowej informacji zwrotnej od użytkownika. W jaki sposób? Odpowiedź na to pytanie znajdziesz w dalszej części artykułu, który jest pierwszą częścią cyklu “Techniczny Poradnik Product Managera”.
Ciągła integracja, czyli integrujmy się częściej
Wyobraź sobie, że zespół programistyczny, z którym rozwijasz produkt, pracuje równocześnie nad dwiema nowymi funkcjonalnościami. Jednakże zarówno Tomek (pracujący nad funkcjonalnością A), jak i Andrzej (rozwijający funkcjonalność B), aby zrealizować wszystkie wymagane historyjki użytkownika, musieli dokonać znaczących zmian w dokładnie tych samych plikach. Co więcej, po dwóch tygodniach owocnej pracy okazało się, że łącznie, w różny sposób, uaktualnili 25 plików. Jak myślisz, ile czasu zajęłoby im połączenie wprowadzonych zmian, tak aby kod napisany przez Tomka i Andrzeja nadal działał tak, jak zaplanował to każdy z nich?
Chcesz jeszcze lepiej zrozumieć świat IT? Sprawdź nasz Kurs Podstaw IT
Ciągła integracja (CI) to praktyka programistyczna, która rozwiązuje problem budowania, testowania oraz integracji kodu. Jej zasadniczym elementem jest pojedyncze, współdzielone repozytorium kodu źródłowego, do którego dostęp powinien posiadać każdy programista rozwijający produkt. Efektywność tej praktyki w dużej mierze zależy od członków zespołu wytwórczego. Andrzej i Tomek, wykorzystując możliwości repozytorium kodu, muszą integrować swoje bieżące zmiany regularnie i często – najlepiej kilkakrotnie w ciągu godziny, ale przynajmniej raz dziennie. Dzięki temu zarówno oni, jak i pozostali programiści, mogą śledzić i co ważniejsze, uwzględniać zmiany dokonane w kodzie przez innych członków zespołu.
Opanuj podstawy Product Discovery w 5 dni
Zapisz się na Product Discovery Academy FREE - 5-dniowy, darmowy kursu podstaw product discovery od Product Academy. Codziennie czeka na Ciebie rozbudowana lekcja wideo i materiały dodatkowe.
„Ciągła integracja nie eliminuje błędów, ale sprawia, że ich znalezienie i usunięcie jest drastycznie łatwiejsze.”
Martin Fowler
Serwer ciągłej integracji
Równie istotnym elementem ciągłej integracji jest serwer ciągłej integracji, który tak samo jak Andrzej i Tomek musi posiadać dostęp do współdzielonego repozytorium kodu. Po co? Aby automatycznie, bez udziału człowieka, sprawdzić czy każda kolejna zmiana dokonana przez programistę jest integralna z obecną wersją kodu oraz wszystkimi modyfikacjami wprowadzanymi przez pozostałych członków zespołu. W jaki sposób? W momencie wysłania przez programistę zmian do repozytorium kodu serwer ciągłej integracji samoczynnie wykrywa i pobiera tę zmianę, buduje system (produkt) oraz uruchamia testy. Jeżeli wszystkie testy zakończą się powodzeniem, serwer automatycznie informuje zespół o sukcesie (tzw. zielony build). W sytuacji, kiedy przynajmniej jeden test się nie powiedzie (tzw. czerwony build), serwer automatycznie ostrzega zespół (np. poprzez notyfikację na Slacku), a problem powinien zostać jak najszybciej rozwiązany.
Należy tutaj podkreślić, że produkt, którego kod źródłowy nie jest pokryty wystarczającą liczbą dobrych testów, jest kiepskim kandydatem do ciągłej integracji, a co za tym idzie, do ciągłego dostarczania.
Podsumowanie
Ciągła integracja rozwiązuje wiele problemów z zakresu codziennej pracy zespołu pracującego nad tym samym produktem. Przede wszystkim ułatwia czasochłonny i podatny na błędy proces integracji kodu. Z punktu widzenia Product Managera, większa wydajność zespołu wytwórczego oraz szybsze wykrywanie potencjalnych błędów to istotna wartość dodana. Niemniej jednak dobre pokrycie kodu testami oraz „zielone światło” od serwera ciągłej integracji nie oznacza jeszcze, że nowa funkcjonalność w postaci kodu napisanego przez programistę, może pojawić się w środowisku produkcyjnym. A przecież bez szybkiego dostarczenia nowej wersji produktu użytkownikom, nie jesteśmy w stanie uzyskać informacji zwrotnej. Kolejną praktyką, która zbliży nas do tego celu, a swe podstawy opiera na prawidłowo wdrożonej ciągłej integracji jest ciągłe dostarczanie, które będzie tematem kolejnego artykułu z cyklu “Techniczny Poradnik Product Managera”.
Bonus: Narzędzia wspierające proces ciągłej integracji
Współdzielone repozytoria kodu:
Serwery ciągłej integracji:
➔ Darmowy kurs product discovery ✨ - opanuj podstawy product discovery w 5 dni
