Stiamo scrivendo un progetto. Aggiungi SpringBoot e imposta un processo CI - "Progetto Java dalla A alla Z"

Un articolo tratto da una serie sulla creazione di un progetto Java (i collegamenti ad altri materiali sono alla fine). Il suo obiettivo è analizzare le tecnologie chiave, il risultato è scrivere un bot di Telegram. Saluti, cari lettori. Come descritto nella parte precedente , andremo secondo i piani. Abbiamo già creato un progetto ed è ora di riempirlo con il codice. Ora tutti i problemi verranno aggiunti come commit separati. Descriverò tutto ciò che è necessario qui. Se mi sfugge qualcosa o non lo descrivo abbastanza chiaramente, chiedi nei commenti, proverò a rispondere.

Scriviamo JRTB-0M

In questa attività dobbiamo aggiungere un framework SpringBoot vuoto per il lavoro futuro. Lo faremo nello stesso modo in cui lo abbiamo fatto nell'articolo su SpringBoot + Flyway . Scarica il progetto , aprilo in IDEA e crea un nuovo ramo chiamato JRTB-0 . Ho descritto come farlo attraverso un'idea qui . Ciò ci renderà più semplice tenere traccia del lavoro in futuro. Sapevi già che non esiste più un ramo master ? Adesso si chiama neutrally- main . Quindi ci abituiamo. Anche se, a dire il vero, possiamo sempre rinominarlo master. Andiamo su Spring Inizializr e creiamo un framework SpringBoot per il nostro bot. Al momento, la versione più giovane del Boot Sprint offerta è la 2.3.7, prendiamola. Descriverò separatamente le seguenti impostazioni:

• Progetto: Progetto Maven : abbiamo già discusso di Maven qui e qui . Pertanto, descriverò inoltre solo ciò che non ho rivelato negli articoli precedenti. Se ci sono tali "punti bianchi", ovviamente)
• Lingua: Java : qui è tutto chiaro. Se lo desideriamo, possiamo riscrivere la questione in Kotlin. Mi sono appena comprato un libro Kotlin in Action, impareremo Kotlin insieme))
• Spring Boot: 2.3.7 - prendiamo la versione più piccola offerta per eliminare eventuali problemi. Questa è già una versione completamente moderna dello stivale.

Metadati del progetto:

• Gruppo: com.github.javarushcommunity - qui selezioniamo il dominio su cui è ospitato il nostro gruppo di repository.
• Artefatto: javarush-telegrambot - descrizione massima del progetto.
• Nome: Javarush TelegramBot : lo scriveremo per intero qui.
• Descrizione: Bot Telegram per Javarush da comunità a comunità : ecco una descrizione più dettagliata del progetto.
• Nome del pacchetto: com.github.javarushcommunity.jrtb - qui puoi già utilizzare un'abbreviazione per il nome del progetto. Ora il progetto inizierà con questo pacchetto. Perchè così tanti? In modo che quando aggiungiamo altri progetti al classpath, si troveranno in pacchetti diversi. Ognuno nel suo modo unico. Questo è importante per mantenere i principi OOP.
• Confezione: il barattolo è il nostro standard)
• Java: 11 - saremo un passo avanti. Non penso che utilizzerò le innovazioni dopo l'ottavo Java, ma lascialo così. Non chiede cibo)... questa decisione ci regalerà in futuro un piccolo uovo di Pasqua)

Non aggiungeremo alcuna dipendenza per ora. Non ne abbiamo bisogno per questo compito. Dopo aver compilato tutto questo, otteniamo (ecco un collegamento al progetto generato): Dopo aver compilato, fare clic su GENERATE e aggiungere tutti gli interni nell'archivio al nostro progetto. Aggiungi file al progetto. Di conseguenza, abbiamo un'applicazione. Per verificare se è stato assemblato, vai al terminale e scrivi: $ mvn clean package Se hai lo stesso da qui, è tutto ok: il progetto è assemblato e il jarnik è già pronto nella cartella di destinazione. A questo punto, l'attività all'interno della descrizione è pronta. È semplice, vero? Pertanto, eseguiamo il commit e lo inviamo al nostro ramo: aggiungiamo il nome del nostro compito all'inizio della descrizione del commit, in modo che in seguito sia chiaro nell'ambito di quale compito è stato svolto il lavoro. Fai clic su Commit and Push ... Ancora una volta esaminiamo e controlliamo cosa esattamente vogliamo inviare dal repository locale a quello remoto e, assicurandoci che tutto sia a posto, fai clic su Push . Qual è il nostro prossimo passo? Secondo tutte le regole (che potete leggere in questo articolo , nella parte relativa al flusso di GitHub), è necessario creare una richiesta pull per il ramo principale e attendere che qualcuno del team riveda il codice. Dato che sono da solo, creerò formalmente una richiesta pull e rivedrò tutto di nuovo. Vado alla pagina del repository e Github sa già che abbiamo un'aggiunta e si offre di creare una richiesta pull: non ci sono ostacoli per i patrioti (c) - la creiamo, come suggerito. Impostiamo la stessa etichetta, progetto dell'attività su cui stiamo lavorando e compiliamo la descrizione: fai clic su Crea richiesta pull .

Impostazione del processo CI

Andiamo alla richiesta pull creata: di seguito vediamo che non abbiamo configurata la Continuous Integration (di seguito - CI). Beh, non è configurato, e allora? Perché abbiamo bisogno della CI? Cos'è comunque la CI? Questo è approssimativamente l'elenco delle domande che dovrebbero preoccuparci in questo momento. In generale, la CI è un processo continuo di fusione del codice in una base di codice comune e prima di eseguire una build del progetto. La cosiddetta build (dall'inglese build). Ogni volta che creiamo un progetto, ci assicuriamo che il progetto sia stato compilato, che tutti i suoi test siano stati superati con successo, inoltre, dopo aver creato il progetto, è possibile aggiungere test automatici dai tester al CI eseguito su questa build specifica. In questo modo, diventiamo più sicuri che le nuove modifiche funzionino come previsto e non interrompano la funzionalità precedente. Anche CI è utile perché si avvia automaticamente dopo l'aggiornamento della base di codice. Cioè, abbiamo trasferito le nostre modifiche al ramo e il processo è iniziato: assemblaggio, test, autotest e altri passaggi. Se uno qualsiasi di questi passaggi fallisce, la build viene considerata interrotta e non può essere unita al ramo principale. Questo è esattamente ciò che faremo ora: aggiungeremo GitHub Actions, che eseguirà il nostro codice dopo il push. GitHub Actions si adatta perfettamente al nostro GitHub Flow, quindi lo useremo per automatizzare il nostro lavoro. Questo strumento è molto potente e capiente, ma per ora lo utilizzeremo solo per eseguire la build e verificare che sia assemblato secondo necessità. Per abilitarlo, trova il pulsante Azioni nella pagina del repository e seguilo: Trova il flusso di lavoro di integrazione continua di cui abbiamo bisogno: fai clic su Imposta questo flusso di lavoro. Successivamente ci viene proposto di utilizzare il loro template: siamo completamente d'accordo, chiariamo solo un po' il tutto:

# 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

Ciò indica che GitHub Action viene chiamato in due casi:

1. Quando viene effettuata una spinta al ramo principale.
2. Quando viene creata una richiesta pull nel ramo principale.

La sezione dei lavori descrive i passaggi che verranno eseguiti. Abbiamo solo un passaggio: costruire. Mostra che il nostro progetto verrà avviato in Ubuntu con il comando mvn -B package --file pom.xml . Questo è esattamente ciò che abbiamo fatto a livello locale. Se vuoi cambiare qualcosa qui, per favore. Utilizzerò questo modello, mi basterà. Faccio clic su Avvia commit , seleziono Crea un nuovo ramo per configurare il processo e quindi Proponi nuovo file . Ma il processo di compilazione è fallito... Come puoi vedere, Fallimento dopo 14 secondi - build. Sembra che sia successo qualcosa: passiamo al montaggio e guardiamo i dettagli: Dice che non sono riuscito a trovare un ricordo del genere. Perché? Ahhh, esatto, esatto! Perché abbiamo creato modifiche nel ramo principale, ma il nostro compito non è ancora arrivato. Ed è per questo che non ha trovato la memoria... Pertanto, ora facciamo quanto segue: uniamo questi dati nel master, poi uniamo il ramo principale in JRTB-0, e poi tutto dovrebbe andare bene. In una richiesta pull con modifiche alle azioni github, fai clic su Unisci richiesta pull : e ripeti Conferma unione . Successivamente, Github ci chiede di eliminare il ramo in cui abbiamo lavorato. Non rifiutiamo ed eliminiamo: Successivamente, non ho trovato nella richiesta pull di SpringBoot come estrarre le modifiche dal ramo principale dal sito Web, quindi lo faremo manualmente tramite IDEA.

Passaggio 1: aggiorna il ramo principale nel repository locale.

L'idea è di andare al ramo master, premere ctrl + t e aggiornare il ramo master:

Passaggio 2: unisci le modifiche dal ramo principale al ramo JRTB-0.

Andiamo su JRTB-0 e uniamo quello principale.

Passaggio 3: inviare le modifiche.

Premi ctrl + maiusc + k e conferma la spinta. Ora stiamo aspettando che la build passi e sarà verde!)) Ma è di nuovo rosso. Che cos'è? Entriamo nei registri delle azioni e vediamo che non siamo sincronizzati nelle versioni Java. In GitHubActions è 8, ma noi usiamo 11: ora ci sono due opzioni: o correggere le azioni, oppure abbassare la versione all'ottavo. La prima opzione, mi sembra, è migliore e più corretta. Stiamo apportando modifiche in un commit separato: lavoreremo non con Java 8, ma con Java 11. Dopodiché, finalmente, tutto ha funzionato per noi e siamo stati in grado di impostare il nostro processo di CI per il progetto. Queste cose devono essere impostate nella fase iniziale, in modo da non doversene preoccupare in seguito. Ora puoi vedere che la build è passata e puoi unirti senza paura:

Impostazione del lavoro con i rami nel repository

Puoi anche configurare tali cose nel repository come regole quando lavori con i rami. Voglio fare in modo che il ramo principale non possa essere inviato direttamente, ma solo tramite richieste pull, e voglio fare in modo che sia impossibile unire una richiesta pull se la build fallisce (cioè se GitHub Actions fallisce in qualche passo). Per fare ciò, trova il pulsante Impostazioni e seleziona Rami : Al momento non ci sono regole per i rami, quindi aggiungiamone una nuova tramite il pulsante Aggiungi regola : Ci sono molte impostazioni qui e ognuno può fare qualcosa per soddisfare le proprie esigenze. esigenze. Affinché la build passi con successo nella richiesta pull prima dell'unione, aggiungi una casella di controllo a Richiedi controlli di stato da superare prima dell'unione e seleziona lo stato di cui abbiamo bisogno: build. Per ora basta: poi potrai aggiornare questo volante e vedere cos'altro vuoi. Fare clic su Crea per creare questo volante. Successivamente, se andiamo di nuovo alla nostra richiesta pull, possiamo vedere che il nostro controllo è ora contrassegnato come richiesto: controlliamo la pagina del nostro progetto, che mostra tutti gli stati delle attività: puoi immediatamente vedere su quale attività si sta lavorando. Inoltre, il lavoro è già stato svolto e l'attività è in stato di revisione del codice.

Chiusura JRTB-0

Ora che abbiamo preparato una richiesta pull e creato un CI per essa, dobbiamo completare l'ultima fase: chiudere l'attività, spostarla nello stato corretto, guardare le modifiche nel nostro progetto sulla lavagna. La nostra richiesta pull è pronta per essere unita al master. Nella richiesta pull, fai clic sul pulsante Unisci richiesta pull : dopo un'unione riuscita, puoi eliminarla e di solito lo fai. Non lo farò per rendere più semplice la visualizzazione delle modifiche tra rami/commit. Non appena una richiesta pull viene unita, viene automaticamente completata nella nostra bacheca del progetto: L'ultimo passaggio è chiudere il problema (problema) con un collegamento alla richiesta pull in cui si trovava: Questo problema viene automaticamente completato asse. L'inizio è stato fatto, il primo compito è finito!

conclusioni

Sembrerebbe che abbiamo già iniziato a lavorare e scrivere codice, ma sono ancora necessarie le impostazioni. Sì, ci vuole tempo, ma verrà ripagato centuplicato quando il progetto diventerà più grande e complesso e avrai bisogno di garanzie che non rompi tutto con un solo commit. La richiesta pull in cui tutto ciò accade è disponibile qui . Forse, quando leggerai, sarà già chiuso. Non è spaventoso: tutte le informazioni necessarie verranno archiviate tramite il collegamento. Grazie a tutti per aver letto, a presto. Inoltre!

Un elenco di tutti i materiali della serie si trova all'inizio di questo articolo.