Samouczek ciągłej dostawy - budowanie rurociągu ciągłego dostarczania przy użyciu Jenkinsa

Ciągła dostawa:

Continuous Delivery to proces, w którym zmiany w kodzie są automatycznie budowane, testowane i przygotowywane do wydania na produkcję.Mam nadzieję, że podobał Ci się mój Tutaj omówię następujące tematy:

• Co to jest ciągła dostawa?
• Rodzaje testowania oprogramowania
• Różnica między ciągłą integracją, dostarczaniem i wdrażaniem
• Jaka jest potrzeba ciągłej dostawy?
• Praktyczne korzystanie z Jenkins i Tomcat

Pozwól nam szybko zrozumieć, jak działa Continuous Delivery.

Co to jest ciągła dostawa?

Jest to proces polegający na tworzeniu oprogramowania w taki sposób, aby można je było w dowolnym momencie wydać do produkcji.Rozważ poniższy diagram:

co to jest instancja w java

Pozwólcie, że wyjaśnię powyższy schemat:

• Zautomatyzowane skrypty kompilacji wykryją zmiany w zarządzaniu kodem źródłowym (SCM), takim jak Git.
• Po wykryciu zmiany kod źródłowy zostanie wdrożony na dedykowanym serwerze kompilacji, aby upewnić się, że kompilacja nie kończy się niepowodzeniem, a wszystkie klasy testowe i testy integracji działają poprawnie.
• Następnie aplikacja kompilacji jest wdrażana na serwerach testowych (serwerach przedprodukcyjnych) w celu przeprowadzenia testu akceptacji użytkownika (UAT).
• Na koniec aplikacja jest ręcznie wdrażana na serwerach produkcyjnych w celu wydania.

Zanim przejdę dalej, będzie uczciwie, wyjaśnię ci różne rodzaje testów.

Rodzaje testowania oprogramowania:

Ogólnie rzecz biorąc, istnieją dwa rodzaje testów:

• Testowanie czarnej skrzynki: Jest to technika testowa, która ignoruje wewnętrzny mechanizm systemu i koncentruje się na danych wyjściowych generowanych na podstawie dowolnego wejścia i wykonania systemu. Nazywa się to również testowaniem funkcjonalnym. Zasadniczo służy do sprawdzania poprawności oprogramowania.
• Testowanie Whitebox: to technika testowania uwzględniająca wewnętrzny mechanizm systemu. Nazywa się to również testami strukturalnymi i testami szklanymi. Zasadniczo służy do weryfikacji oprogramowania.

Testowanie Whitebox:

Istnieją dwa rodzaje testów, które należą do tej kategorii.

• Testów jednostkowych: Jest to testowanie pojedynczej jednostki lub grupy jednostek powiązanych. Jest to często wykonywane przez programistę w celu sprawdzenia, czy jednostka, którą zaimplementował, wytwarza oczekiwane dane wyjściowe na podstawie danych wejściowych.
• Testy integracyjne: Jest to rodzaj testów, w których znajduje się grupa komponentówpołączone w celu uzyskania wyniku. Ponadto interakcja między oprogramowaniem a sprzętem jest testowana, jeśli komponenty oprogramowania i sprzętu mają jakikolwiek związek. Może podlegać zarówno testom białoskrzynkowym, jak i testom czarnoskrzynkowym.

Testowanie czarnej skrzynki:

Istnieje wiele testów, które należą do tej kategorii. Skupię się nakilka, które warto znać, aby zrozumieć ten blog:

• Testy funkcjonalne / akceptacyjne: Zapewnia, że ​​działa określona funkcjonalność wymagana w wymaganiach systemowych. Ma to na celu upewnienie się, że dostarczony produkt spełnia wymagania i działa zgodnie z oczekiwaniami klienta
• Testowanie systemu: Zapewnia, że ​​poprzez umieszczenie oprogramowania w różnych środowiskach (np. Systemach operacyjnych) nadal działa.
• Test naprężeń: Ocenia, jak system zachowuje się w niesprzyjających warunkach.
• Testowanie beta: Robią to użytkownicy końcowi, zespół poza programistą lub publiczne udostępnianie pełnej wersji wstępnej produktu, która jest znana jakobetawersja. Celem testów beta jest wykrycie nieoczekiwanych błędów.

Teraz jest właściwy moment na wyjaśnienie różnicy między ciągłą integracją, dostawą i wdrożeniem.

Różnice między ciągłą integracją, dostarczaniem i wdrażaniem:

Treści wizualne docierają do mózgu jednostki w szybszy i bardziej zrozumiały sposób niż informacje tekstowe. Zacznę więc od diagramu, który jasno wyjaśnia różnicę:

W Continuous Integration każde zatwierdzenie kodu jest kompilowane i testowane, ale nie jest w stanie do wydania. Chodzi mi o to, że aplikacja kompilacji nie jest automatycznie wdrażana na serwerach testowych w celu sprawdzenia jej przy użyciu różnych typów testów Blackbox, takich jak - Test akceptacji użytkownika (UAT).

W Continuous Delivery aplikacja jest stale wdrażana na serwerach testowych dla UAT. Możesz też powiedzieć, że aplikacja jest gotowa do wydania w dowolnym momencie. Tak więc ciągła integracja jest oczywiście niezbędna do ciągłego dostarczania.

Ciągłe wdrażanie to kolejny krok po ciągłym dostarczaniu, w którym nie tylko tworzysz pakiet, który można wdrożyć, ale faktycznie wdrażasz go w sposób zautomatyzowany.

Pozwólcie, że podsumuję różnice za pomocą tabeli:

Mówiąc prosto, ciągła integracja jest częścią zarówno ciągłego dostarczania, jak i ciągłego wdrażania. Ciągłe wdrażanie przypomina ciągłe dostarczanie, z wyjątkiem tego, że wydania następują automatycznie.

Dowiedz się, jak tworzyć rurociągi CI / CD za pomocą Jenkins w chmurze

Ale pytanie brzmi, czy ciągła integracja wystarczy.

Dlaczego potrzebujemy ciągłej dostawy?

Zrozummy to na przykładzie.

Wyobraź sobie, że nad dużym projektem pracuje 80 programistów. Używają potoków ciągłej integracji, aby ułatwić automatyczne kompilacje. Wiemy, że kompilacja obejmuje również testy jednostkowe. Pewnego dnia zdecydowali się wdrożyć najnowszą wersję, która przeszła testy jednostkowe, w środowisku testowym.

To musi być długotrwałe, ale kontrolowane podejście do wdrożenia, które przeprowadzili ich specjaliści ds. Środowiska. Jednak system wydawał się nie działać.

Jaka może być oczywista przyczyna niepowodzenia?

Cóż, pierwszym powodem, dla którego większość ludzi pomyśli, jest problem z konfiguracją. Jak większość ludzi, nawet oni tak myśleli.Spędzili dużo czasu, próbując dowiedzieć się, co jest nie tak z konfiguracją środowiska, ale nie mogli znaleźć problemu.

Jeden spostrzegawczy programista podjął mądre podejście:

Następnie jeden ze starszych programistów wypróbował aplikację na swoim komputerze deweloperskim. Tam też się nie udało.

Wrócił do wcześniejszych i wcześniejszych wersji, aż stwierdził, że system przestał działać trzy tygodnie wcześniej. Mały, niejasny błąd uniemożliwił poprawne uruchomienie systemu. Chociaż projekt miał dobre pokrycie testami jednostkowymi.Mimo to 80 programistów, którzy zwykle przeprowadzali tylko testy, a nie samą aplikację, nie widziało problemu przez trzy tygodnie.

Oświadczenie dotyczące problemu:

Bez przeprowadzania testów akceptacji w środowisku podobnym do produkcyjnego, nie wiedzą nic o tym, czy aplikacja spełnia specyfikacje klienta, ani czy można ją wdrożyć i przetrwać w prawdziwym świecie. Jeśli chcą w odpowiednim czasie uzyskać informacje zwrotne na te tematy, muszą rozszerzyć zakres swojego procesu ciągłej integracji.

Pozwólcie, że podsumuję wyciągnięte wnioski, patrząc na powyższe problemy:

• Testy jednostkowe sprawdzają tylko perspektywę programisty rozwiązania problemu. Mają tylko ograniczoną możliwość udowodnienia, że ​​aplikacja robi to, co powinna z punktu widzenia użytkownika. Nie wystarczązidentyfikować rzeczywiste problemy funkcjonalne.
• Wdrażanie aplikacji w środowisku testowym to złożony, wymagający ręcznej pracy proces, który był dość podatny na błędy.Oznaczało to, że każda próba wdrożenia była nowym eksperymentem - ręcznym, podatnym na błędy procesem.

Rozwiązanie - ciągłe dostawy (automatyczny test akceptacji):

Przeszli na kolejny etap Continuous Integration (Continuous Delivery) i wprowadzili kilka prostych, zautomatyzowanych testów akceptacyjnych, które dowiodły, że aplikacja działa i może wykonywać swoją najbardziej podstawową funkcję.Większość testów uruchomionych na etapie testów akceptacyjnych to funkcjonalne testy akceptacyjne.

Zasadniczo zbudowali potok ciągłego dostarczania, aby upewnić się, że aplikacja jest bezproblemowo wdrożona w środowisku produkcyjnym, upewniając się, że aplikacja działa dobrze po wdrożeniu na serwerze testowym, który jest repliką serwera produkcyjnego.

Dość teorii, pokażę teraz, jak utworzyć potok ciągłego dostarczania przy użyciu Jenkinsa.

Potok ciągłego dostarczania za pomocą Jenkins:

Tutaj użyję Jenkinsa do utworzenia ciągłego rurociągu dostaw, który będzie obejmował następujące zadania:

Kroki związane z demo:

• Pobieranie kodu z GitHub
• Kompilacja kodu źródłowego
• Testowanie jednostkowe i generowanie raportów z testów JUnit
• Pakowanie aplikacji do pliku WAR i wdrażanie jej na serwerze Tomcat

Wymagania wstępne:

• Maszyna CentOS 7
• Jenkins 2.121.1
• Doker
• Tomcat 7

Krok - 1 Kompilowanie kodu źródłowego:

Zacznijmy od stworzenia projektu Freestyle w Jenkins. Rozważ poniższy zrzut ekranu:

Nadaj nazwę swojemu projektowi i wybierz Projekt Freestyle:

Kiedy przewiniesz w dół, znajdziesz opcję dodania repozytorium kodu źródłowego, wybierz git i dodaj adres URL repozytorium, w tym repozytorium znajduje się grzywna pom.xml, której użyjemy do zbudowania naszego projektu. Rozważ poniższy zrzut ekranu:

Teraz dodamy wyzwalacz kompilacji. Wybierz opcję ankiety SCM, w zasadzie skonfigurujemy Jenkins do odpytywania repozytorium GitHub co 5 minut pod kątem zmian w kodzie. Rozważ poniższy zrzut ekranu:

Zanim przejdę dalej, pozwólcie, że przedstawię wam małe wprowadzenie do cyklu budowania Mavena.

Każdy z cykli życia kompilacji jest definiowany przez inną listę faz kompilacji, przy czym faza kompilacji reprezentuje etap w cyklu życia.

Poniżej znajduje się lista etapów kompilacji:

• waliduj - sprawdź, czy projekt jest poprawny i czy wszystkie niezbędne informacje są dostępne
• kompiluj - skompiluj kod źródłowy projektu
• test - przetestuj skompilowany kod źródłowy przy użyciu odpowiedniego środowiska do testów jednostkowych. Testy te nie powinny wymagać pakowania ani wdrażania kodu
• pakiet - weź skompilowany kod i spakuj go w formacie przeznaczonym do dystrybucji, takim jak JAR.
• weryfikuj - przeprowadzaj wszelkie sprawdzenia wyników testów integracyjnych, aby upewnić się, że kryteria jakości są spełnione
• install - zainstaluj pakiet w lokalnym repozytorium, aby użyć go jako zależności w innych projektach lokalnie
• wdrażanie - wykonywane w środowisku kompilacji, kopiuje ostateczny pakiet do zdalnego repozytorium w celu udostępnienia innym programistom i projektom.

Mogę uruchomić poniższe polecenie, aby skompilować kod źródłowy, przeprowadzić testy jednostkowe, a nawet spakować aplikację do pliku wojennego:

czysty pakiet mvn

Możesz również podzielić pracę kompilacji na kilka etapów kompilacji. Ułatwia to organizowanie kompilacji w czystych, osobnych etapach.

Zaczniemy więc od kompilacji kodu źródłowego. Na karcie kompilacji kliknij wywołanie celów maven najwyższego poziomu i wpisz poniższe polecenie:

skompilować

Rozważ poniższy zrzut ekranu:

Spowoduje to pobranie kodu źródłowego z repozytorium GitHub, a także jego skompilowanie (faza kompilacji Maven).

Kliknij Zapisz i uruchom projekt.

jakie jest 6 sposobów użycia tego słowa kluczowego

Teraz kliknij wyjście konsoli, aby zobaczyć wynik.

Krok - 2 testy jednostkowe:

Teraz stworzymy jeszcze jeden projekt Freestyle do testów jednostkowych.

Dodaj ten sam adres URL repozytorium na karcie zarządzania kodem źródłowym, tak jak w poprzednim zadaniu.

Teraz w zakładce „Buid Trigger” kliknij „buduj po zbudowaniu innych projektów”. Tam wpisz nazwę poprzedniego projektu, w którym kompilujemy kod źródłowy i możesz wybrać dowolną z poniższych opcji:

• Wyzwalaj tylko wtedy, gdy kompilacja jest stabilna
• Wyzwalaj, nawet jeśli kompilacja jest niestabilna
• Wyzwalaj, nawet jeśli kompilacja się nie powiedzie

Myślę, że powyższe opcje są dość oczywiste, więc wybierz dowolną. Rozważ poniższy zrzut ekranu:

Na karcie Kompiluj kliknij wywołanie celów maven najwyższego poziomu i użyj poniższego polecenia:

test

Jenkins wykonuje również świetną robotę, pomagając wyświetlać wyniki testów i trendy w wynikach testów.

W rzeczywistości standardem raportowania testów w świecie Java jest format XML używany przez JUnit. Ten format jest również używany przez wiele innych narzędzi testujących Java, takich jak TestNG, Spock i Easyb. Jenkins rozumie ten format, więc jeśli Twoja kompilacja generuje wyniki testów JUnit XML, Jenkins może generować ładne graficzne raporty z testów i statystyki dotyczące wyników testów w czasie, a także umożliwia przeglądanie szczegółów wszelkich niepowodzeń testów. Jenkins śledzi również, jak długo trwają testy, zarówno globalnie, jak i na test - może się to przydać, jeśli chcesz śledzić problemy z wydajnością.

Więc następną rzeczą, którą musimy zrobić, jest skłonienie Jenkinsa do śledzenia naszych testów jednostkowych.

Przejdź do sekcji Czynności po kompilacji i zaznacz pole wyboru „Publikuj raport wyników testu JUnit”. Gdy Maven uruchamia testy jednostkowe w projekcie, automatycznie generuje raporty z testów XML w katalogu o nazwie surefire-reports. Dlatego wpisz „** / target / surefire-reports / *. Xml” w polu „Test raport XML”. Dwie gwiazdki na początku ścieżki („**”) to najlepszy sposób na uczynienie konfiguracji nieco bardziej niezawodną: pozwalają Jenkinsowi znaleźć katalog docelowy bez względu na to, jak skonfigurowaliśmy Jenkinsa do pobrania kodu źródłowego.

** / target / surefire-reports / *. xml

Ponownie zapisz go i kliknij Build Now.

Teraz raport JUnit jest zapisywany w / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behawior.

Na pulpicie nawigacyjnym Jenkinsmożesz również zauważyć wyniki testu:

Krok - 3 Tworzenie pliku WAR i wdrażanie na serwerze Tomcat:

Teraz następnym krokiem jest spakowanie naszej aplikacji w pliku WAR i wdrożenie go na serwerze Tomcat w celu przeprowadzenia testu akceptacji użytkownika.

Utwórz jeszcze jeden projekt freestyle i dodaj adres URL repozytorium kodu źródłowego.

Następnie na karcie wyzwalacza kompilacji wybierz kompilację, gdy budowane są inne projekty, rozważ poniższy zrzut ekranu:

Zasadniczo po zadaniu testowym faza wdrażania rozpocznie się automatycznie.

Na karcie kompilacji wybierz skrypt powłoki. Wpisz poniższe polecenie, aby spakować aplikację do pliku WAR:

pakiet mvn

Następnym krokiem jest wdrożenie tego pliku WAR na serwerze Tomcatserwer. W zakładce „Działania post-Build” wybierz rozmieść wojnę / ucho do kontenera. Tutaj podaj ścieżkę do pliku wojny i ścieżkę kontekstu. Rozważ poniższy zrzut ekranu:

Wybierz poświadczenia Tomcat i zwróć uwagę na powyższy zrzut ekranu. Musisz także podać adres URL serwera Tomcat.

Aby dodać poświadczenia w Jenkins, kliknij opcję poświadczeń na pulpicie nawigacyjnym Jenkins.

Kliknij System i wybierz poświadczenia globalne.

Następnie znajdziesz opcję dodania poświadczeń. Kliknij na nią i dodaj poświadczenia.

Dodaj poświadczenia Tomcat, rozważ poniższy zrzut ekranu.

Kliknij OK.

Teraz w konfiguracji projektu dodaj poświadczenia tomcat, które zostały wstawione w poprzednim kroku.

Kliknij Zapisz, a następnie wybierz Buduj teraz.

Przejdź do adresu URL tomcat ze ścieżką kontekstu, w moim przypadku jest to http: // localhost: 8081. Teraz dodaj na końcu ścieżkę kontekstu, rozważ poniższy zrzut ekranu:

Link - http: // localhost: 8081 / gof

Mam nadzieję, że zrozumiałeś znaczenie ścieżki kontekstu.

Teraz utwórz widok potoku, rozważ poniższy zrzut ekranu:

Kliknij ikonę plusa, aby utworzyć nowy widok.

Skonfiguruj potok tak, jak chcesz, rozważ poniższy zrzut ekranu:

funkcja sortowania c ++

Nie zmieniłem niczego poza wyborem początkowej pracy. Więc mój potok zacznie się od kompilacji. W oparciu o sposób, w jaki skonfigurowałem inne zadania, po przetestowaniu kompilacji i wdrożeniu.

Na koniec możesz przetestować potok, klikając RUN. Co pięć minut, jeśli nastąpi zmiana w kodzie źródłowym, zostanie wykonany cały potok.

Dzięki temu jesteśmy w stanie stale wdrażać naszą aplikację na serwerze testowym w celu wykonania testu akceptacji użytkownika (UAT).

Mam nadzieję, że podobał Ci się ten post na temat ciągłej dostawy. Jeśli masz jakiekolwiek wątpliwości, możesz je zamieścić w sekcji komentarzy poniżej, a ja skontaktuję się z Tobą najwcześniej z odpowiedzią.

Aby zbudować rurociągi CI / CD, musisz opanować szeroką gamę umiejętności Opanuj teraz wymagane umiejętności DevOps