Ciągła integracja - przegląd
Ciągła integracja została po raz pierwszy wprowadzona w 2000 roku wraz z oprogramowaniem znanym jako Cruise Control. Przez lata ciągła integracja stała się kluczową praktyką w każdej organizacji oprogramowania. Jest to praktyka programistyczna, która wymaga od zespołów programistów upewnienia się, że kompilacja i kolejne testy są przeprowadzane dla każdej zmiany kodu wprowadzonej w programie. Koncepcja ta miała na celu usunięcie problemu znajdowania późnych wystąpień problemów w cyklu życia kompilacji. Zamiast pracy deweloperów w izolacji i niewystarczającej integracji, wprowadzono ciągłą integrację, aby zapewnić, że zmiany kodu i kompilacje nigdy nie były wykonywane w izolacji.
Dlaczego ciągła integracja?
Ciągła integracja stała się integralną częścią każdego procesu tworzenia oprogramowania. Proces ciągłej integracji pomaga zespołowi programistycznemu odpowiedzieć na następujące pytania.
Czy wszystkie składniki oprogramowania współpracują ze sobą tak, jak powinny? - Czasami systemy mogą stać się tak złożone, że istnieje wiele interfejsów dla każdego komponentu. W takich przypadkach zawsze ważne jest, aby wszystkie komponenty oprogramowania bezproblemowo współpracowały ze sobą.
Czy kod jest zbyt skomplikowany do celów integracji? - Jeśli proces ciągłej integracji nadal kończy się niepowodzeniem, może istnieć możliwość, że kod jest po prostu zbyt złożony. Może to być sygnał do zastosowania odpowiednich wzorców projektowych, aby kod był mniej złożony i łatwiejszy w utrzymaniu.
Czy kod jest zgodny z ustalonymi standardami kodowania? - Większość przypadków testowych zawsze sprawdza, czy kod jest zgodny z odpowiednimi standardami kodowania. Wykonując automatyczny test po automatycznej kompilacji, warto sprawdzić, czy kod spełnia wszystkie pożądane standardy kodowania.
Ile kodu obejmuje testy automatyczne? - Nie ma sensu testowanie kodu, jeśli przypadki testowe nie obejmują wymaganej funkcjonalności kodu. Dlatego zawsze dobrą praktyką jest upewnienie się, że napisane przypadki testowe obejmują wszystkie kluczowe scenariusze aplikacji.
Czy wszystkie testy zakończyły się pomyślnie po ostatniej zmianie? - Jeśli test się nie powiedzie, nie ma sensu kontynuowanie wdrażania kodu, więc warto sprawdzić, czy kod jest gotowy do przejścia do etapu wdrażania, czy nie.
Przepływ pracy
Poniższy obraz przedstawia szybki przepływ pracy pokazujący, jak działa cały przepływ pracy Continuous Integration w dowolnym projekcie tworzenia oprogramowania. Przyjrzymy się temu szczegółowo w następnych rozdziałach.
Tak więc, na podstawie powyższego przepływu pracy, ogólnie wygląda to, jak działa proces ciągłej integracji.
Najpierw programista przesyła kod do repozytorium kontroli wersji. W międzyczasie serwer Continuous Integration na maszynie do budowania integracji odpytuje repozytorium kodu źródłowego pod kątem zmian (np. Co kilka minut).
Wkrótce po zatwierdzeniu serwer Continuous Integration wykrywa zmiany w repozytorium kontroli wersji, więc serwer Continuous Integration pobiera najnowszą kopię kodu z repozytorium, a następnie wykonuje skrypt kompilacji, który integruje oprogramowanie
Serwer Continuous Integration generuje informacje zwrotne, wysyłając pocztą e-mail wyniki kompilacji do określonych członków projektu.
Testy jednostkowe są następnie przeprowadzane, jeśli kompilacja tego projektu zakończy się pomyślnie. Jeśli testy zakończą się pomyślnie, kod jest gotowy do wdrożenia na serwerze pomostowym lub produkcyjnym.
Serwer Continuous Integration kontynuuje odpytywanie w poszukiwaniu zmian w repozytorium kontroli wersji i cały proces się powtarza.