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.
- 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)
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:
- Quando viene effettuata una spinta al ramo principale.
- Quando viene creata una richiesta pull nel ramo principale.
GO TO FULL VERSION