Piszemy projekt. Dodaj SpringBoot i skonfiguruj proces CI - „Projekt Java od A do Z”

Artykuł z serii o tworzeniu projektu w Javie (linki do innych materiałów znajdują się na końcu). Jego celem jest analiza kluczowych technologii, efektem jest napisanie bota telegramowego. Witam Was drodzy czytelnicy. Jak opisano w poprzedniej części, pójdziemy zgodnie z planem. Stworzyliśmy już projekt i czas wypełnić go kodem. Teraz wszystkie problemy zostaną dodane jako osobne zatwierdzenia. Opiszę tu wszystko co niezbędne. Jeśli coś przeoczyłem lub nie opisałem tego wystarczająco jasno, pytaj w komentarzach, postaram się odpowiedzieć.

Piszemy JRTB-0M

W tym zadaniu musimy dodać pusty framework SpringBoot do przyszłej pracy. Zrobimy to w taki sam sposób, jak zrobiliśmy to w artykule o SpringBoot + Flyway . Pobierz projekt , otwórz go w IDEA i utwórz nową gałąź o nazwie JRTB-0 . Opisałem, jak to zrobić za pomocą pomysłu tutaj . Ułatwi nam to śledzenie prac w przyszłości. Czy wiesz już, że nie ma już gałęzi master ? Teraz nazywa się to neutralnie- głównym . Więc przyzwyczajamy się do tego. Chociaż szczerze mówiąc, zawsze możemy zmienić jego nazwę z powrotem na master. Przechodzimy do Spring Originizr i tworzymy framework SpringBoot dla naszego bota. W tej chwili najmłodszą oferowaną wersją boot sprintu jest 2.3.7, przyjmijmy to. Osobno opiszę następujące ustawienia:

• Projekt: Projekt Maven - o Mavenie pisaliśmy już tutaj i tutaj . Dlatego dodatkowo opiszę tylko to, czego nie ujawniłem w poprzednich artykułach. Jeśli oczywiście są takie „białe plamy”)
• Język: Java - tutaj wszystko jest jasne. Jeśli jest chęć, możemy tę kwestię przepisać w Kotlinie. Właśnie kupiłem sobie książkę Kotlin w Akcji, wspólnie nauczymy się Kotlina))
• Spring Boot: 2.3.7 - bierzemy najmniejszą oferowaną wersję, aby wyeliminować wszelkie problemy. To już całkowicie nowoczesna wersja buta.

Metadane projektu:

• Grupa: com.github.javarushcommunity – tutaj wybieramy domenę, na której hostowana jest nasza grupa repozytoriów.
• Artefakt: javarush-telegrambot - maksymalny opis projektu.
• Nazwa: Javarush TelegramBot – napiszemy ją tutaj w całości.
• Opis: Bot telegramowy dla Javarush od społeczności do społeczności - tutaj znajduje się bardziej szczegółowy opis projektu.
• Nazwa pakietu: com.github.javarushcommunity.jrtb - tutaj możesz już użyć skrótu nazwy projektu. Teraz projekt rozpocznie się od tego pakietu. Dlaczego tak dużo? Dzięki temu, gdy dodamy inne projekty do ścieżki klas, będą one w różnych pakietach. Każdy na swój niepowtarzalny sposób. Jest to ważne, aby zachować zasady OOP.
• Opakowanie: Słoik to nasz standard)
• Java: 11 – będziemy o krok do przodu. Nie sądzę, że po ósmej Javie skorzystam z innowacji, ale niech tak będzie. Nie prosi o jedzenie)... ta decyzja da nam w przyszłości małą wielkanocną jajko)

Na razie nie będziemy dodawać żadnych zależności. Nie potrzebujemy tego do tego zadania. Po wypełnieniu tego wszystkiego otrzymamy (tutaj link do wygenerowanego projektu): Po wypełnieniu klikamy GENERUJ i dodajemy do naszego projektu wszystkie elementy wewnętrzne znajdujące się w archiwum. Dodaj pliki do projektu. W rezultacie mamy aplikację. Aby sprawdzić, czy w ogóle jest zmontowany, przejdź do terminala i napisz: $ mvn clean package Jeśli masz to samo co stąd, wszystko jest w porządku: projekt jest zmontowany, a jarnik jest już gotowy w folderze docelowym. W tym momencie zadanie zawarte w opisie jest gotowe. To proste, prawda? Dlatego też zatwierdzamy i wypychamy do naszej gałęzi: Nazwę naszego zadania dodajemy na początku opisu zatwierdzenia, aby później było jasne, w ramach jakiego zadania została wykonana praca. Klikamy Commit i Push ... Jeszcze raz przeglądamy i sprawdzamy, co dokładnie chcemy wypchnąć z repozytorium lokalnego do zdalnego i upewniając się, że wszystko jest w porządku, klikamy Push . Jaki będzie nasz następny krok? Zgodnie ze wszystkimi zasadami (o których można przeczytać w tym artykule , w części poświęconej przepływowi GitHuba), należy utworzyć pull request dla głównej gałęzi i poczekać, aż ktoś z zespołu sprawdzi kod. Ponieważ jestem sam, formalnie utworzę żądanie ściągnięcia i sprawdzę wszystko jeszcze raz. Wchodzę na stronę repozytorium, a Github już wie, że mamy dodatek i oferuje utworzenie pull requesta: Dla patriotów nie ma przeszkód (c) - tworzymy go zgodnie z sugestią. Ustawiamy tę samą etykietę, projekt, co w zadaniu, nad którym pracujemy, i wypełniamy opis: Kliknij Utwórz pull request .

Konfigurowanie procesu CI

Przechodzimy do utworzonego pull requestu: poniżej widzimy, że nie mamy skonfigurowanej Continuous Integration (dalej – CI). Cóż, nie jest skonfigurowany, więc co? Po co nam w ogóle CI? Czym w ogóle jest CI? To w przybliżeniu lista pytań, które powinny nas w tej chwili niepokoić. Ogólnie rzecz biorąc, CI to ciągły proces łączenia kodu we wspólną bazę kodu i wcześniejsze uruchomienie kompilacji projektu. Tak zwana kompilacja (od angielskiego build). Za każdym razem, gdy budujemy projekt, upewniamy się, że projekt został skompilowany, wszystkie testy przeszły pomyślnie, a po zbudowaniu projektu możesz dodać autotesty od testerów do CI, które są uruchamiane na tej konkretnej kompilacji. Dzięki temu zyskujemy większą pewność, że nowe zmiany działają zgodnie z naszymi oczekiwaniami i nie psują dotychczasowej funkcjonalności. CI jest również dobre, ponieważ uruchamia się automatycznie po aktualizacji bazy kodu. Oznacza to, że przesunęliśmy nasze zmiany do gałęzi i rozpoczął się proces - montaż, testy, autotesty i inne etapy. Jeśli którykolwiek z tych kroków zakończy się niepowodzeniem, kompilacja zostanie uznana za uszkodzoną i nie będzie można jej połączyć z gałęzią główną. Dokładnie to teraz zrobimy: dodamy GitHub Actions, które po wypchnięciu uruchomią nasz kod. GitHub Actions idealnie wpasowuje się w nasz GitHub Flow, dlatego wykorzystamy go do automatyzacji naszej pracy. To narzędzie jest bardzo potężne i duże, ale na razie będziemy go używać tylko do uruchomienia kompilacji i sprawdzenia, czy jest zmontowane w razie potrzeby. Aby ją włączyć, znajdź przycisk Akcje na stronie repozytorium i postępuj zgodnie z nim: Znajdź przepływ pracy ciągłej integracji, którego potrzebujemy: Kliknij Skonfiguruj ten przepływ pracy. Następnie zaproponowano nam skorzystanie z ich szablonu: całkowicie się zgadzamy, po prostu wszystko trochę wyjaśnijmy:

# This workflow will build a Java project with Maven
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven

name: Java CI with Maven

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Build with Maven
      run: mvn -B package --file pom.xml

Oznacza to, że akcja GitHub jest wywoływana w dwóch przypadkach:

1. Po naciśnięciu głównej gałęzi.
2. Kiedy w gałęzi głównej tworzone jest żądanie ściągnięcia.

Sekcja zadań opisuje kroki, które zostaną wykonane. Mamy tylko jeden krok – budowanie. Pokazuje, że nasz projekt zostanie uruchomiony w Ubuntu za pomocą polecenia mvn -B package --file pom.xml . To jest dokładnie to, co zrobiliśmy lokalnie. Jeżeli chcesz coś tu zmienić to proszę. Skorzystam z tego szablonu, mi wystarczy. Klikam Rozpocznij zatwierdzanie , wybieram opcję Utwórz nową gałąź, aby skonfigurować proces, a następnie Zaproponuj nowy plik . Ale proces kompilacji upadł... Jak widać, niepowodzenie po 14 s - kompilacja. Wygląda na to, że coś się stało: przejdźmy do montażu i przyjrzyjmy się szczegółom: Mówi, że nie mogłem znaleźć takiej pamięci. Dlaczego? Ach, dokładnie, dokładnie! Ponieważ stworzyliśmy zmiany w gałęzi master, ale nasze zadanie jeszcze nie jest gotowe. I dlatego nie znalazł pamięci... Dlatego teraz robimy co następuje: scalamy te dane z masterem, potem łączymy główną gałąź z JRTB-0 i wtedy wszystko powinno pójść dobrze. W żądaniu ściągnięcia ze zmianami w działaniach Github kliknij Scal żądanie ściągnięcia : I powtórz Potwierdź połączenie . Następnie Github prosi nas o usunięcie gałęzi, w której pracowaliśmy. Nie odmawiamy i usuwamy: Następnie nie znalazłem w żądaniu ściągnięcia ze SpringBoot, jak pobrać zmiany z głównej gałęzi ze strony internetowej, więc zrobimy to ręcznie przez IDEA.

Krok 1: Zaktualizuj gałąź główną do lokalnego repozytorium.

Pomysł jest taki, aby przejść do gałęzi master, nacisnąć ctrl + t i zaktualizować gałąź master:

Krok 2: Scal zmiany z gałęzi głównej do gałęzi JRTB-0.

Przejdźmy do JRTB-0 i połączmy z nim główny.

Krok 3: wypychanie zmian.

Naciśnij ctrl + shift + k i potwierdź naciśnięcie. Teraz czekamy, aż kompilacja się zakończy i będzie zielona!)) Ale znowu jest czerwona. Co to jest? Wchodzimy do dzienników działań i widzimy, że nie mamy synchronizacji w wersjach Java. W GitHubActions jest to 8, ale my używamy 11: Teraz są dwie opcje: albo poprawić akcje, albo obniżyć wersję do ósmej. Wydaje mi się, że pierwsza opcja jest lepsza i bardziej poprawna. Zmiany wprowadzamy w osobnym zatwierdzeniu: będziemy pracować nie z Javą 8, ale z Javą 11. Potem w końcu wszystko się udało i mogliśmy skonfigurować nasz proces CI dla projektu. Takie rzeczy trzeba ustalić już na początkowym etapie, żeby nie trzeba było się tym później martwić. Teraz widzisz, że kompilacja została zakończona i możesz łączyć się bez obaw:

Konfigurowanie pracy z oddziałami w repozytorium

Możesz także skonfigurować w repozytorium takie rzeczy jak reguły podczas pracy z oddziałami. Chcę to zrobić tak, aby głównej gałęzi nie można było wypchnąć bezpośrednio, ale tylko za pomocą żądań ściągnięcia, i chcę to zrobić tak, aby niemożliwe było scalanie żądania ściągnięcia, jeśli kompilacja się nie powiedzie (to znaczy, jeśli akcje GitHub nie powiodą się w jakiś krok). Aby to zrobić, znajdź przycisk Ustawienia i wybierz Oddziały : W tej chwili nie ma żadnych reguł dla oddziałów, więc dodajmy nowy za pomocą przycisku Dodaj regułę : Jest tu wiele ustawień i każdy może zrobić coś, co mu odpowiada wymagania. Aby kompilacja przeszła pomyślnie w żądaniu ściągnięcia przed połączeniem, dodaj pole wyboru Wymagaj przejścia sprawdzania stanu przed połączeniem i wybierz potrzebny nam status - kompilacja. Na razie wystarczy: potem możesz zaktualizować tę kierownicę i zobaczyć, czego jeszcze chcesz. Kliknij opcję Utwórz , aby utworzyć tę kierownicę. Następnie, jeśli ponownie przejdziemy do naszego żądania ściągnięcia, zobaczymy, że nasza kontrola jest teraz oznaczona jako wymagana: Sprawdźmy stronę naszego projektu, która wyświetla wszystkie statusy zadań: Możesz od razu zobaczyć, nad jakim zadaniem pracujesz. Co więcej, praca została już wykonana, a zadanie znajduje się w fazie przeglądu kodu.

Zamykanie JRTB-0

Teraz gdy już przygotowaliśmy pull request i zrobiliśmy dla niego CI, pozostaje nam dokończyć ostatni etap: zamknąć zadanie, przenieść je do odpowiedniego statusu, przyjrzeć się zmianom w naszym projekcie na tablicy. Nasze żądanie ściągnięcia jest gotowe do połączenia z masterem. W żądaniu ściągnięcia kliknij przycisk Połącz żądanie ściągnięcia : po pomyślnym łączeniu możesz je usunąć i zwykle tak się dzieje. Nie zrobię tego, aby ułatwić ci zobaczenie zmian między gałęziami/zatwierdzeniami. Gdy tylko żądanie ściągnięcia zostanie scalone, zostanie ono automatycznie zakończone na naszej tablicy projektu: Ostatnim krokiem jest zamknięcie problemu (problemu) za pomocą łącza do żądania ściągnięcia, w którym było: To zadanie automatycznie zostaje zakończone na tablica. Początek został zrobiony, pierwsze zadanie wykonane!

wnioski

Wydawać by się mogło, że rozpoczęliśmy już pracę i pisanie kodu, jednak ustawienia są jeszcze potrzebne. Tak, to wymaga czasu, ale zwróci się stokrotnie, gdy projekt stanie się większy i bardziej złożony i będziesz potrzebować gwarancji, że nie zepsujesz wszystkiego jednym zatwierdzeniem. Żądanie ściągnięcia, w którym to wszystko się dzieje, jest dostępne tutaj . Być może, kiedy będziesz czytać, będzie już zamknięta. To nie jest straszne: wszystkie niezbędne informacje będą przechowywane za pośrednictwem linku. Dziękuję wszystkim za przeczytanie, do zobaczenia wkrótce. Ponadto!

Lista wszystkich materiałów wchodzących w skład serii znajduje się na początku artykułu.