Ciągła integracja

Pozdrawiam, koledzy! Masz dość zmuszania komputera do ciągłego tworzenia projektu? To ten artykuł jest dla ciebie! W tym artykule postaram się krótko i przejrzyście przedstawić materiał dotyczący Ciągłej Integracji (dalej po prostu CI), odpowiem na tak proste pytania jak: „Co to jest?”, „Dlaczego?” i dlaczego?" i podam przykład projektu testowego. Ten artykuł jest przeznaczony dla doświadczonego użytkownika, który przynajmniej zna Build System: Maven , wie, jak używać Git i wie, jak przesyłać projekty do GitHub ;

„Co to jest ciągła integracja?”

Zobaczmy, co Wiki mówi nam na ten temat : Ciągła integracja (CI, angielski Continuous Integration) to praktyka tworzenia oprogramowania, która polega na łączeniu kopii roboczych we wspólną główną gałąź programistyczną kilka razy dziennie i wykonywaniu częstych automatycznych kompilacji projektu na początku wykrywanie potencjalnych defektów i rozwiązania problemów integracyjnych. Straszne, prawda? Spróbujmy wyjaśnić ten termin w prostych słowach: Ciągła integracja to system służący do budowania i automatycznego testowania oprogramowania z określonymi konfiguracjami na określonych komputerach w celu wykrycia błędów i niekompatybilności. OK, nie ma problemu, rozpracowaliśmy to, ale pojawia się następujące logiczne pytanie:

Dlaczego potrzebujemy CI?

Wyobraźmy sobie, że piszesz duży projekt i istnieje potrzeba dodania/zmiany funkcjonalności. Udało ci się to napisać, napisać testy, uruchomić i wszystko wydaje się być w porządku, ale nie. Zdarzają się sytuacje, gdy zmiana w jednej funkcjonalności wpływa na inną, kolejną na trzecią i tak dalej, aż gdzieś prześlizgnie się błąd i pojawi się błąd. Tak, można powiedzieć, że to najprawdopodobniej źle zaprojektowany projekt i możesz mieć rację, ale co jeśli tak nie jest, a te połączenia naprawdę powinny tam być? A co jeśli piszesz i tworzysz projekt więcej niż raz, co często ma miejsce? Przeprowadziłeś testy nowo napisanej funkcjonalności i dały one pozytywny wynik. Szybko podjąłeś decyzję, potem gdzieś odepchnąłeś i już myślisz o tym, jak będziesz palił cygaro w domu, popijając drogą whisky, ale nie. Niestety, twój kolega lub szef, nieważne kto, twierdzi, że z powodu twojego zatwierdzenia cała kompilacja uległa awarii. Ze zdziwieniem mówisz, że jesteś programistą, wszystko przetestowałeś. Ale często po prostu nie ma czasu na ciągłe testowanie całego projektu i testujesz tylko fragment kodu, w którym dokonałeś zmian, a nie cały zestaw jako całość. I tu z pomocą przychodzi nam CI. Przy każdym wypchnięciu dowolnego zasobu CI zbuduje Twój projekt od zera, przeprowadzi WSZYSTKIE testy i tylko jeśli wszystkie testy zakończą się pomyślnie, a projekt zostanie zbudowany, kompilacja otrzyma status pomyślny . W przeciwnym razie będziesz miał okazję wrócić i zobaczyć, co poszło nie tak. Czas więc zadać pytanie „Dlaczego tak, a nie inaczej?” i przyjrzyj się implementacji oprogramowania. Przykład Jak już mówiłem, artykuł przeznaczony jest dla osób znających Mavena i Gita. Dlatego mam nadzieję, że wiecie, jak i czym się zajmuję poza konfiguracją CI itp.

1. Najpierw utwórzmy prosty projekt testowy Mavena i utwórzmy w nim klasę, która wypisuje „Hello World!” i wykonuje jakąś prostą operację i napiszmy najprostszy test dla tej klasy.

   W rezultacie powinniśmy mieć prymitywną strukturę projektu:

   Wszystkie źródła będą na moim GitHubie. Nie ma znaczenia, co napiszesz w swoim Main i jakie będą testy.

2. Wypychamy nasz projekt do GitHuba.

3. Teraz zaczyna się zabawa. Z CI wybrałem Travis CI ze względu na jego dostępność i niezawodność. Travis używa GitHuba do hostowania swojego kodu źródłowego.

   Przejdź więc do witryny Travis CI i zaloguj się za pośrednictwem GitHub. W profilu podpinamy nasz projekt:

   Wszystko jest gotowe do montażu za każdym naciśnięciem, tylko pytanie JAK złożyć?

4. Wracamy do naszego ukochanego POMYSŁU i tworzymy plik .travis.yml

   Ten plik jest odpowiedzialny za konfigurację kompilacji Travisa. Przyjrzyjmy się najpopularniejszemu ustawieniu:

   • Należy określić język , w którym realizowany jest projekt;
   • Określ ścieżkę do katalogów , aby przyspieszyć kompilację;
   • Określ sposób powiadamiania o udanym lub nieudanym montażu.

   Tak powinna wyglądać typowa konfiguracja Travisa:

   # https://docs.travis-ci.com/user/languages/java/
   language: java
   jdk: oraclejdk9
   
   # Improve Build Speed https://dzone.com/articles/travis-ci-tutorial-java-projects
   cache:
     directories:
     - $HOME/.m2
   
   # Notifications https://docs.travis-ci.com/user/notifications/
   notifications:
     email:
       recipients:
         - qThegamEp@gmail.com
       on_success: always # default: change
       on_failure: always # default: always

   Dla przejrzystości dodałem komentarze z linkami.

5. Wciskamy ponownie do GitHub i otwieramy stronę Travisa , wybieramy projekt i monitorujemy kompilację. W rezultacie otrzymujemy powiadomienie o pomyślnej kompilacji:

   Również na stronie możemy zobaczyć plakietkę z udanym montażem naszego projektu, którą możemy wstawić do naszego README.md:

Przydatne linki:

• Mój projekt testowy , który możesz obejrzeć/pobrać jeśli czegoś nie rozumiesz;

• Właściwie sama strona internetowa Travis CI ;

• Samouczek na oficjalnej stronie internetowej dotyczący konfiguracji i korzystania z Travis CI;

• Dobre wideo ;

• Kolejny poradnik ;

• Następny artykuł

W tekście mogą występować błędy i pominięcia. Dziękuję za uwagę!