Dlaczego potrzebujesz ciągłej integracji

Czym jest ciągła integracja (Continuous Integration), popularne CI? Czy to tylko modne pojęcie często powtarzające się w ofertach pracy dla programistów, czy kryje się za tym coś więcej? Przekonaj się na czym polega ciągła integracja i co możesz dzięki niej zyskać.

Czym jest CI

Ciągła integracja (Continuous Integration) to zestaw praktyk stosowanych podczas rozwijania oprogramowania. Zakłada częstą integrację kodu pochodzącego od różnych programistów. Po każdej zmianie w projekcie (odnotowanej w systemie kontroli wersji) aplikacja jest przebudowywana i wykonują się na niej testy, może być również instalowana na docelowym środowisku. Jeśli nastąpi problem w dowolnym kroku, zespół deweloperski zobowiązany jest przerwać pracę i naprawić usterkę.

Zalety stosowania CI

  • dostarczanie oprogramowania o wiele szybciej,
  • mniej błędów (błędy wyłapywane są na wczesnym etapie – tańsze w naprawie),
  • duże możliwości automatyzacji (np. budowanie wielu wersji aplikacji),
  • zmniejszone ryzyko niepowodzenia projektu,
  • kontrola nad stanem projektu (częste wykonywanie testów potwierdzające zgodność projektu z założeniami),
  • ciągły dostęp do najnowszej zbudowanej wersji (przydatne dla testerów),
  • możliwość generowania statystyk,
  • powtarzalność procesu.

Wady

  • jak każdy proces wymaga poświęcenia czasu m. in. na konfigurację i utrzymanie,
  • podczas trwania projektu, szczególnie gdy jest złożony, wprowadzanie CI może być trudne, ale CI można wdrażać etapami,
  • wraz ze wzrostem ilości projektów zwiększają się wymagania sprzętowe maszyny przeznaczonej dla serwera CI.
Ciągła integracja - wizualizacja łańcucha
Źródło: 9gag

Co jest niezbędne przed rozpoczęciem pracy z CI

  • system kontroli wersji
    Wszystko co niezbędne do stworzenia, zbudowania, uruchomienia i testowania aplikacji powinno być w jednym repozytorium.
  • automatyczny proces budowy projektu
    Projekt powinien być budowany za pomocą jednego polecenia wydawanego z konsoli. Przykładowo może to być skrypt wykonujący wiele skomplikowanych zadań. Budowa nie powinna być zależna od konkretnego IDE. Pomocne są popularne narzędzia wspomagające budowę projektu: Maven (o którym pisałam w jednym z wpisów), Ant, Gradle itp.
  • zgoda zespołu
    CI to praktyka, nie narzędzie. Zespół musi się zgodzić na to, że najwyższy priorytet ma naprawianie błędów wykrytych dzięki CI.

Narzędzia wspomagające CI

Oprócz repozytorium kodu potrzebujemy serwera ciągłej integracji. W uproszczeniu serwer składa się z dwóch komponentów. Pierwszy jest ciągłym procesem, który wykonuje proste zadania w określonym czasie, a drugi udostępnia wyniki tych zadań.

Interwał przebudowywania projektu możemy dowolnie konfigurować. Dobrze sprawdza się przebudowywanie projektu po każdej publikacji nowego kodu. Do jednego serwera CI możemy przyporządkować wiele projektów. Zazwyczaj serwer CI udostępnia listę projektów, na której możemy sprawdzić ich aktualny stan.

Serwery CI udostępniają wiele dodatkowych opcji. Jedną z bardziej przydatnych jest automatyczne powiadamianie zespołu o problemach poprzez mail, komunikator itp. Serwery często są zintegrowane z popularnymi bugtrackerami i mogą same tworzyć w nich zgłoszenia. Dzięki możliwości definiowania zadań do wykonania możemy zlecić cykliczne przeprowadzanie statycznej analizy kodu. Oczywiście nie brakuje też rozrywkowych elementów jak np. okazjonalne wyświetlanie memów czy tworzenie rankingów deweloperów (na podstawie ilości punktów zdobytych za “poprawne buildy”).

Warto zwrócić uwagę na integrację serwera CI z repozytorium wyników. Możliwość pobrania konkretnych zbudowanych wersji może oszczędzić sporo czasu, szczególnie w przypadku większych zespołów.

Obecnie mamy spory wybór serwerów CI zarówno bezpłatnych i płatnych. Każde rozwiązanie ma swoje zalety i wady, dlatego dobrze jest przemyśleć swój wybór. Warto przyjrzeć się przynajmniej kilku serwerom, przykładowo: Jenkins, Hudson, TeamCity.

Etapy pracy z CI

  1. sprawdź, czy CI aktualnie buduje projekt
    Jeśli tak, to zaczekaj aż skończy, być może ktoś będzie musiał naprawić błąd 😉
  2. zaktualizuj lokalne repozytorium kodu
    Pobierz kod z systemu kontroli wersji. Scal ewentualne konflikty z Twoim kodem.
  3. lokalnie zbuduj projekt
    Sprawdź czy projekt poprawnie buduje się na lokalnej maszynie i czy wszystkie testy kończą się sukcesem.
  4. prześlij zmiany do repozytorium kodu
    Zatwierdź swoje zmiany w kodzie i udostępnij je innym w systemie kontroli wersji.
  5. zaczekaj, aż CI zbuduje projekt
    Po opublikowaniu zmian w kodzie, serwer ciągłej integracji rozpocznie budowanie projektu. Jeśli podczas tego kroku ujawnią się błędy, powinieneś je naprawić. Upewnij się, że poprawka w projekcie pozwala na lokalne zbudowanie projektu i prześlij zmiany do repozytorium. Jeśli serwer CI zbudował projekt możesz zająć się dalszą pracą i powtarzać cykl.

Co jest niezbędne, żeby ciągła integracja dawała dobre rezultaty

  • regularność
    Bez częstego integrowania kodu proces CI nie ma sensu. Przy regularnym publikowaniu nowego kodu w repozytorium zmiany są mniejsze, łatwiej nad nimi panować i trudniej o konflikty.
  • posiadanie kompletnej suity testowej
    Bez zapewnienia dobrej jakości testów pokrywających znaczną część funkcjonalności aplikacji ciągła integracja umożliwia tylko sprawdzenie czy projekt się kompiluje.
  • krótki czas budowania i testów
    Najlepiej jeśli testy wykonują się w mniej niż 10min. Czas testów można zmniejszać poprzez ich optymalizację. Drugim sposobem jest podział budowania aplikacji przez CI na dwie fazy. Pierwsza to commit – buduje projekt oraz wykonuje testy jednostkowe, a druga stage – równolegle wykonuje testy integracyjne, akceptacyjne i wydajnościowe.

Dobre praktyki

Jeśli serwer CI wskazuje, że projekt się nie kompiluje, to nie ma sensu pobierać kodu z repozytorium i publikować swoich zmian. Osoba, która spowodowała błąd zapewne już pracuje nad jego rozwiązaniem. Najważniejszym celem jest zapewnienie stabilności. Jeśli problemu nie udaje się rozwiązać w krótkim czasie, to dobrze jest cofnąć całą zmianę w kodzie. Pozwala to na spokojną pracę pozostałych członków zespołu.

Pamiętaj, że jeśli projekt nie zbuduje się na CI, cały zespół nie może kontynuować pracy. Budując projekt lokalnie i wykonując testy przed opublikowaniem zmian w repozytorium kodu upewniasz się, że nie utrudnisz innym pracy.

Jeśli zdarzy się, że Twoja zmiana spowoduje błąd budowania projektu na serwerze ciągłej integracji napraw ją niezwłocznie, powinieneś brać odpowiedzialność za kod, który tworzysz. Zostawiając kod do poprawy na kolejny dzień spowodujesz, że osoba która przyjdzie do pracy wcześniej od Ciebie nie będzie mogła zająć się swoimi zadaniami. W przypadku kiedy zespoły są międzynarodowe inna strefa czasowa może spowodować, że zablokujesz komuś możliwość pracy w środku dnia.


Opracowano na podstawie własnych doświadczeń i książki: Jez Humble, David Farley, “Continuous delivery: reliable software releases through build, test, and deployment automation” , 2011 Pearson Education, Inc.

Zdjęcie wyróżniające: FreeImages.com/Nick Benjaminsz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *