Wir schreiben ein Projekt. SpringBoot hinzufügen und CI-Prozess einrichten – „Java-Projekt von A bis Z“

Ein Artikel aus einer Reihe über die Erstellung eines Java-Projekts (Links zu anderen Materialien finden Sie am Ende). Sein Ziel ist es, Schlüsseltechnologien zu analysieren, das Ergebnis ist das Schreiben eines Telegram-Bots. Grüße, liebe Leser. Wie im vorherigen Teil beschrieben , werden wir nach Plan vorgehen. Wir haben bereits ein Projekt erstellt und es ist Zeit, es mit Code zu füllen. Jetzt werden alle Issues als separate Commits hinzugefügt. Ich werde hier alles Notwendige beschreiben. Wenn ich etwas übersehe oder es nicht klar genug beschreibe, frage in den Kommentaren nach, ich versuche zu antworten.

Wir schreiben JRTB-0M

In dieser Aufgabe müssen wir ein leeres SpringBoot-Framework für zukünftige Arbeiten hinzufügen. Wir werden dies auf die gleiche Weise tun wie im Artikel über SpringBoot + Flyway . Laden Sie das Projekt herunter , öffnen Sie es in IDEA und erstellen Sie einen neuen Zweig namens JRTB-0 . Ich habe hier anhand einer Idee beschrieben, wie das geht . Dies wird es uns in Zukunft erleichtern, die Arbeit nachzuverfolgen. Wussten Sie schon, dass es keine Master- Filiale mehr gibt? Jetzt heißt es neutrally- main . Also gewöhnen wir uns daran. Obwohl wir es, um ehrlich zu sein, jederzeit wieder in „Master“ umbenennen können. Wir gehen zu Spring Initializr und erstellen ein SpringBoot-Framework für unseren Bot. Die derzeit jüngste angebotene Version des Boot Sprint ist 2.3.7, nehmen wir es mal. Folgende Einstellungen beschreibe ich gesondert:

• Projekt: Maven-Projekt – Maven haben wir hier und hier bereits besprochen . Daher beschreibe ich zusätzlich nur das, was ich in den vorherigen Artikeln nicht preisgegeben habe. Wenn es solche „weißen Flecken“ gibt, natürlich)
• Sprache: Java - hier ist alles klar. Wenn der Wunsch besteht, können wir diese Angelegenheit in Kotlin umschreiben. Ich habe mir gerade ein Buch „Kotlin in Action“ gekauft, wir werden Kotlin gemeinsam lernen))
• Spring Boot: 2.3.7 – wir nehmen die kleinste angebotene Version, um etwaige Probleme auszuschließen. Dies ist bereits eine völlig moderne Version des Stiefels.

Projektmetadaten:

• Gruppe: com.github.javarushcommunity – hier wählen wir die Domain aus, auf der unsere Gruppe von Repositorys gehostet wird.
• Artefakt: javarush-telegrambot – maximale Beschreibung des Projekts.
• Name: Javarush TelegramBot – wir schreiben es hier vollständig.
• Beschreibung: Telegram-Bot für Javarush von Community zu Community – hier ist eine detailliertere Beschreibung des Projekts.
• Paketname: com.github.javarushcommunity.jrtb – hier können Sie bereits eine Abkürzung für den Projektnamen verwenden. Nun startet das Projekt mit diesem Paket. Warum so viele? Wenn wir also andere Projekte zum Klassenpfad hinzufügen, befinden sie sich in unterschiedlichen Paketen. Jeder auf seine ganz eigene Art und Weise. Dies ist wichtig, um die OOP-Prinzipien aufrechtzuerhalten.
• Verpackung: Glas ist unser Standard)
• Java: 11 – wir sind einen Schritt voraus. Ich glaube nicht, dass ich nach dem achten Java Neuerungen nutzen werde, aber lass es sein. Er bittet nicht um Essen)... diese Entscheidung wird uns in Zukunft ein kleines Osterei bescheren)

Wir werden vorerst keine Abhängigkeiten hinzufügen. Das brauchen wir für diese Aufgabe nicht. Nachdem wir dies alles ausgefüllt haben, erhalten wir (hier ist ein Link zum generierten Projekt): Klicken Sie nach dem Ausfüllen auf GENERIEREN und fügen Sie alle Interna im Archiv zu unserem Projekt hinzu. Fügen Sie dem Projekt Dateien hinzu. Als Ergebnis haben wir eine Bewerbung. Um zu überprüfen, ob es überhaupt assembliert ist, gehen Sie zum Terminal und schreiben Sie: $ mvn clean package. Wenn Sie dasselbe wie hier haben, ist alles in Ordnung: Das Projekt ist assembliert und der Jarnik liegt bereits im Zielordner bereit. An diesem Punkt ist die Aufgabe in der Beschreibung fertig. Es ist einfach, oder? Deshalb committen und pushen wir zu unserem Branch: Den Namen unserer Aufgabe fügen wir am Anfang der Commit-Beschreibung hinzu, damit später klar ist, im Rahmen welcher Aufgabe die Arbeit erledigt wurde. Klicken Sie auf „Commit and Push“ ... Noch einmal prüfen wir, was genau wir vom lokalen Repository auf das Remote-Repository übertragen möchten, und klicken auf „ Push“ , um sicherzustellen, dass alles in Ordnung ist . Was ist unser nächster Schritt? Gemäß allen Regeln (die in diesem Artikel im Abschnitt über den GitHub-Flow nachgelesen werden können) müssen Sie eine Pull-Anfrage für den Hauptzweig erstellen und darauf warten, dass jemand aus dem Team den Code überprüft. Da ich alleine bin, werde ich offiziell eine Pull-Anfrage erstellen und alles noch einmal überprüfen. Ich gehe auf die Repository-Seite und Github weiß bereits, dass wir eine Ergänzung haben und bietet an, eine Pull-Anfrage zu erstellen: Es gibt keine Hindernisse für Patriots (c) – wir erstellen sie, wie vorgeschlagen. Wir setzen die gleiche Bezeichnung und das gleiche Projekt wie für die Aufgabe, an der wir arbeiten, und füllen die Beschreibung aus: Klicken Sie auf „Pull-Anfrage erstellen“ .

Einrichten des CI-Prozesses

Wir gehen zur erstellten Pull-Anfrage: Unten sehen wir, dass wir keine kontinuierliche Integration konfiguriert haben (im Folgenden: CI). Nun, es ist nicht konfiguriert, na und? Warum brauchen wir überhaupt CI? Was ist CI überhaupt? Dies ist ungefähr die Liste der Fragen, die uns in diesem Moment beschäftigen sollten. Im Allgemeinen handelt es sich bei CI um einen kontinuierlichen Prozess, bei dem Code in einer gemeinsamen Codebasis zusammengeführt wird und davor ein Build des Projekts ausgeführt wird. Der sogenannte Build (vom englischen Build). Jedes Mal, wenn wir ein Projekt erstellen, stellen wir sicher, dass das Projekt kompiliert wurde und alle seine Tests erfolgreich bestanden wurden. Außerdem können Sie nach dem Erstellen des Projekts Autotests von Testern zu CI hinzufügen, die für diesen bestimmten Build ausgeführt werden. Auf diese Weise können wir sicherer sein, dass die neuen Änderungen wie erwartet funktionieren und die vorherige Funktionalität nicht beeinträchtigen. CI ist auch gut, weil es nach der Aktualisierung der Codebasis automatisch startet. Das heißt, wir haben unsere Änderungen in die Verzweigung übertragen und der Prozess begann – Montage, Tests, Autotests und andere Schritte. Wenn einer dieser Schritte fehlschlägt, gilt der Build als fehlerhaft und kann nicht mit dem Hauptzweig zusammengeführt werden. Genau das werden wir jetzt tun: Wir werden GitHub Actions hinzufügen, die unseren Code nach dem Push ausführen. GitHub Actions passt perfekt in unseren GitHub Flow, sodass wir es zur Automatisierung unserer Arbeit verwenden werden. Dieses Tool ist sehr leistungsstark und umfangreich, aber wir werden es vorerst nur verwenden, um den Build auszuführen und zu überprüfen, ob er nach Bedarf zusammengestellt wurde. Um es zu aktivieren, suchen Sie die Schaltfläche „Aktionen“ auf der Repository-Seite und folgen Sie ihr: Suchen Sie den von uns benötigten Continuous-Integration-Workflow: Klicken Sie auf Diesen Workflow einrichten. Als nächstes wird uns angeboten, ihre Vorlage zu verwenden: Wir stimmen vollkommen zu, lassen Sie uns einfach alles ein wenig klären:

# 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

Dies weist darauf hin, dass die GitHub-Aktion in zwei Fällen aufgerufen wird:

1. Wenn ein Push zum Hauptzweig erfolgt.
2. Wenn eine Pull-Anfrage im Hauptzweig erstellt wird.

Im Abschnitt „Jobs“ werden die Schritte beschrieben, die ausgeführt werden. Wir haben nur einen Schritt – bauen. Es zeigt, dass unser Projekt in Ubuntu mit dem Befehl mvn -B package --file pom.xml gestartet wird . Genau das haben wir vor Ort gemacht. Wenn Sie hier etwas ändern möchten, bitte. Ich werde diese Vorlage verwenden, sie wird mir ausreichen. Ich klicke auf „ Commit starten“ , wähle „Neuen Zweig erstellen“ aus, um den Prozess zu konfigurieren, und wähle dann „ Neue Datei vorschlagen“ aus . Aber der Build-Prozess ist gescheitert ... Wie Sie sehen können, schlägt der Build nach 14 Sekunden fehl. Es sieht so aus, als wäre etwas passiert: Kommen wir zur Montage und schauen wir uns die Details an: Dort steht, dass ich eine solche Erinnerung nicht finden konnte. Warum? Ahhh, genau, genau! Denn wir haben Änderungen im Master-Zweig erstellt, aber unsere Aufgabe ist noch nicht da. Und deshalb hat er den Speicher nicht gefunden ... Deshalb machen wir jetzt Folgendes: Wir führen diese Daten in den Master ein, dann führen wir den Hauptzweig in JRTB-0 zusammen, und dann sollte alles gut gehen. Klicken Sie in einer Pull-Anfrage mit Github-Aktionsänderungen auf Pull-Anfrage zusammenführen : Und wiederholen Sie Zusammenführung bestätigen . Als nächstes fordert uns Github auf, den Branch zu löschen, in dem wir gearbeitet haben. Wir verweigern und löschen nicht: Als nächstes habe ich in der Pull-Anfrage von SpringBoot nicht gefunden, wie man Änderungen aus dem Hauptzweig von der Website zieht, also werden wir es manuell über IDEA tun.

Schritt 1: Master-Zweig auf lokales Repository aktualisieren.

Die Idee besteht darin, zum Hauptzweig zu gehen, Strg + T zu drücken und den Hauptzweig zu aktualisieren:

Schritt 2: Änderungen vom Hauptzweig zum JRTB-0-Zweig zusammenführen.

Gehen wir zu JRTB-0 und verschmelzen den Hauptteil damit.

Schritt 3: Änderungen pushen.

Drücken Sie Strg + Umschalt + K und bestätigen Sie den Push. Jetzt warten wir darauf, dass der Build abgeschlossen ist und es grün sein wird!)) Aber es ist wieder rot. Was ist es? Wir gehen in die Aktionsprotokolle und stellen fest, dass die Java-Versionen nicht synchron sind. In GitHubActions ist es 8, aber wir verwenden 11: Jetzt gibt es zwei Möglichkeiten: entweder die Aktionen korrigieren oder die Version auf die Achte herabsetzen. Die erste Option scheint mir besser und richtiger zu sein. Änderungen nehmen wir in einem separaten Commit vor: Wir werden nicht mit Java 8, sondern mit Java 11 arbeiten. Und dann hat für uns endlich alles geklappt und wir konnten unseren CI-Prozess für das Projekt aufsetzen. Solche Dinge müssen in der Anfangsphase eingerichtet werden, damit Sie sich später nicht darum kümmern müssen. Jetzt können Sie sehen, dass der Build erfolgreich war und Sie ohne Angst zusammenführen können:

Einrichten der Arbeit mit Zweigen im Repository

Sie können solche Dinge im Repository auch als Regeln konfigurieren, wenn Sie mit Zweigen arbeiten. Ich möchte dafür sorgen, dass der Hauptzweig nicht direkt gepusht werden kann, sondern nur über Pull-Requests, und ich möchte dafür sorgen, dass es unmöglich ist, einen Pull-Request zusammenzuführen, wenn der Build fehlschlägt (das heißt, wenn GitHub-Aktionen fehlschlagen). irgendein Schritt). Suchen Sie dazu die Schaltfläche „ Einstellungen“ und wählen Sie „Zweige“ aus : Im Moment gibt es keine Regeln für Zweige. Fügen wir also über die Schaltfläche „Regel hinzufügen“ eine neue hinzu : Hier gibt es viele Einstellungen, und jeder kann etwas tun, was zu ihm passt Bedürfnisse. Damit der Build die Pull-Anfrage vor dem Zusammenführen erfolgreich durchlaufen kann, fügen Sie ein Kontrollkästchen zu „Statusprüfungen müssen vor dem Zusammenführen erforderlich sein“ hinzu und wählen Sie den Status aus, den wir benötigen – Build. Das reicht für den Moment: Dann können Sie dieses Lenkrad aktualisieren und sehen, was Sie sonst noch wollen. Klicken Sie auf Erstellen, um dieses Lenkrad zu erstellen. Wenn wir als nächstes noch einmal zu unserem Pull-Request gehen, können wir sehen, dass unsere Prüfung nun als erforderlich markiert ist: Schauen wir uns unsere Projektseite an, auf der alle Aufgabenstatus angezeigt werden: Sie können sofort sehen, an welcher Aufgabe gearbeitet wird. Darüber hinaus ist die Arbeit bereits erledigt und die Aufgabe befindet sich im Code-Review-Status.

Schließung von JRTB-0

Nachdem wir nun einen Pull-Request vorbereitet und ein CI dafür erstellt haben, müssen wir den letzten Schritt abschließen: die Aufgabe schließen, sie in den richtigen Status verschieben, die Änderungen in unserem Projekt an der Tafel betrachten. Unsere Pull-Anfrage ist bereit, in den Master eingebunden zu werden. Klicken Sie in der Pull-Anfrage auf die Schaltfläche „Pull-Anfrage zusammenführen“ : Nach einer erfolgreichen Zusammenführung können Sie sie löschen und tun dies normalerweise auch. Ich werde dies nicht tun, um es für Sie einfacher zu machen, Änderungen zwischen Zweigen/Commits zu erkennen. Sobald ein Pull-Request zusammengeführt wird, geht dieser automatisch in unserem Projektboard auf „erledigt“: Der letzte Schritt besteht darin, das Issue (Issue) mit einem Link zum Pull-Request zu schließen, in dem es sich befand: Dieses Issue geht automatisch auf „erledigt“. Planke. Der Anfang ist gemacht, die erste Aufgabe ist erledigt!

Schlussfolgerungen

Es scheint, dass wir bereits mit der Arbeit und dem Schreiben von Code begonnen haben, aber es sind noch Einstellungen erforderlich. Ja, es braucht Zeit, aber es wird sich hundertfach auszahlen, wenn das Projekt größer und komplexer wird und Sie Garantien brauchen, dass Sie nicht einfach mit einem Commit alles kaputt machen. Die Pull-Anfrage, in der dies alles geschieht, ist hier verfügbar . Vielleicht ist es beim Lesen bereits geschlossen. Es ist nicht beängstigend: Alle notwendigen Informationen werden über den Link gespeichert. Vielen Dank fürs Lesen, bis bald. Außerdem!

Eine Liste aller Materialien der Serie finden Sie am Anfang dieses Artikels.