Nous écrivons un projet. Ajoutez SpringBoot et configurez un processus CI - "Projet Java de A à Z"

Un article d'une série sur la création d'un projet Java (les liens vers d'autres documents se trouvent à la fin). Son objectif est d'analyser les technologies clés, le résultat est d'écrire un robot télégramme. Salutations, chers lecteurs. Comme décrit dans la partie précédente , nous procéderons comme prévu. Nous avons déjà créé un projet et il est temps de le remplir de code. Désormais, tous les problèmes seront ajoutés en tant que commits distincts. Je vais décrire ici tout ce qui est nécessaire. Si quelque chose me manque ou si je ne le décris pas assez clairement, demandez dans les commentaires, j'essaierai de répondre.

Nous écrivons JRTB-0M

Dans cette tâche, nous devons ajouter un framework SpringBoot vide pour les travaux futurs. Nous ferons cela de la même manière que nous l'avons fait dans l'article sur SpringBoot + Flyway . Téléchargez le projet , ouvrez-le dans IDEA et créez une nouvelle branche appelée JRTB-0 . J'ai décrit comment procéder à travers une idée ici . Cela nous permettra de suivre plus facilement les travaux à l’avenir. Saviez-vous déjà qu’il n’existe plus de branche master ? Maintenant, cela s'appelle neutre- main . Alors on s'y habitue. Bien que, pour être honnête, nous puissions toujours le renommer master. Nous allons sur Spring Initializr et créons un framework SpringBoot pour notre bot. Pour le moment, la plus jeune version du boot sprint proposée est la 2.3.7, prenons-la. Je décrirai séparément les paramètres suivants :

• Projet : Projet Maven - nous avons déjà discuté de Maven ici et ici . Par conséquent, je décrirai en plus uniquement ce que je n'ai pas divulgué dans les articles précédents. S'il y a de tels "points blancs", bien sûr)
• Langage : Java - tout est clair ici. Si nous le souhaitons, nous pouvons réécrire cette affaire en Kotlin. Je viens de m'acheter un livre Kotlin in Action, nous apprendrons Kotlin ensemble))
• Spring Boot : 2.3.7 - nous prenons la plus petite version proposée pour éliminer tout problème. Il s'agit déjà d'une version complètement moderne de la botte.

Métadonnées du projet :

• Groupe : com.github.javarushcommunity - nous sélectionnons ici le domaine sur lequel notre groupe de référentiels est hébergé.
• Artefact : javarush-telegrambot - description maximale du projet.
• Nom : Javarush TelegramBot - nous l'écrirons dans son intégralité ici.
• Description : Bot Telegram pour Javarush de communauté en communauté - voici une description plus détaillée du projet.
• Nom du package : com.github.javarushcommunity.jrtb - ici, vous pouvez déjà utiliser une abréviation pour le nom du projet. Le projet va maintenant démarrer avec ce package. Pourquoi tant ? Ainsi, lorsque nous ajouterons d’autres projets au chemin de classe, ils seront dans des packages différents. Chacun à sa manière. Ceci est important pour maintenir les principes de la POO.
• Emballage : Le pot est notre norme)
• Java : 11 - nous aurons une longueur d'avance. Je ne pense pas que j'utiliserai les innovations après le huitième Java, mais qu'il en soit ainsi. Il ne demande pas de nourriture)... cette décision nous donnera un petit œuf de Pâques à l'avenir)

Nous n’ajouterons aucune dépendance pour l’instant. Nous n’en avons pas besoin pour cette tâche. Après avoir rempli tout cela, nous obtenons (voici un lien vers le projet généré) : Après avoir rempli, cliquez sur GÉNÉRER et ajoutez tous les éléments internes de l'archive à notre projet. Ajoutez des fichiers au projet. En conséquence, nous avons une candidature. Pour vérifier s'il est assemblé, allez dans le terminal et écrivez : $ mvn clean package Si vous avez la même chose qu'ici, tout va bien : le projet est assemblé, et le jarnik est déjà prêt dans le dossier cible. À ce stade, la tâche décrite dans la description est prête. C'est simple, non ? Par conséquent, nous nous engageons et poussons vers notre branche : nous ajoutons le nom de notre tâche au début de la description du commit, afin qu'il soit clair plus tard dans le cadre de quelle tâche le travail a été effectué. Cliquez sur Commit et Push ... Encore une fois, nous examinons et vérifions exactement ce que nous voulons pousser du référentiel local vers le référentiel distant et, en nous assurant que tout va bien, cliquez sur Push . Quelle est notre prochaine étape ? Selon toutes les règles (qui peuvent être lues dans cet article , dans la partie sur le flux GitHub), vous devez créer une pull request pour la branche principale et attendre qu'un membre de l'équipe examine le code. Puisque je suis seul, je vais officiellement créer une pull request et tout revoir à nouveau. Je vais sur la page du référentiel, et Github sait déjà que nous avons un ajout et propose de créer une pull request : il n'y a aucun obstacle pour les patriotes (c) - nous le créons comme suggéré. Nous définissons le même label, le même projet que sur la tâche sur laquelle nous travaillons et remplissons la description : Cliquez sur Créer une pull request .

Mise en place du processus CI

Nous allons à la pull request créée : ci-dessous, nous voyons que nous n'avons pas configuré l'intégration continue (ci-après - CI). Eh bien, ce n’est pas configuré, et alors ? Pourquoi avons-nous besoin de CI ? Au fait, qu’est-ce que le CI ? C'est à peu près la liste des questions qui devraient nous préoccuper en ce moment. En général, CI est un processus continu de fusion de code dans une base de code commune et d'exécution d'une version du projet avant cela. Ce qu'on appelle build (de l'anglais build). Chaque fois que nous construisons un projet, nous nous assurons que le projet a été compilé, que tous ses tests ont réussi, et après la construction du projet, vous pouvez ajouter des autotests des testeurs à CI qui sont exécutés sur cette version spécifique. De cette façon, nous sommes plus sûrs que les nouvelles modifications fonctionnent comme prévu et n’interrompent pas les fonctionnalités précédentes. CI est également bon car il démarre automatiquement après la mise à jour de la base de code. Autrement dit, nous avons poussé nos modifications dans la branche et le processus a commencé - assemblage, tests, autotests et autres étapes. Si l’une de ces étapes échoue, la build est considérée comme interrompue et ne peut pas être fusionnée dans la branche principale. C'est exactement ce que nous allons faire maintenant : nous ajouterons des actions GitHub, qui exécuteront notre code après le push. GitHub Actions s'intègre parfaitement dans notre GitHub Flow, nous allons donc l'utiliser pour automatiser notre travail. Cet outil est très puissant et volumineux, mais pour l'instant nous l'utiliserons uniquement pour exécuter le build et vérifier qu'il est assemblé selon les besoins. Pour l'activer, recherchez le bouton Actions sur la page du référentiel et suivez-le : Recherchez le workflow d'intégration continue dont nous avons besoin : cliquez sur Configurer ce workflow. Ensuite, on nous propose d'utiliser leur modèle : nous sommes tout à fait d'accord, clarifions juste un peu tout :

# 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

Cela indique que GitHub Action est appelée dans deux cas :

1. Lorsqu'une poussée est effectuée vers la branche principale.
2. Lorsqu'une pull request est créée dans la branche principale.

La section Tâches décrit les étapes qui seront effectuées. Nous n’avons qu’une seule étape : construire. Cela montre que notre projet sera lancé dans Ubuntu avec la commande mvn -B package --file pom.xml . C'est exactement ce que nous avons fait localement. Si vous souhaitez modifier quelque chose ici, s'il vous plaît. J'utiliserai ce modèle, cela me suffira. Je clique sur Démarrer la validation , sélectionne Créer une nouvelle branche pour configurer le processus, puis Proposer un nouveau fichier . Mais le processus de construction a échoué... Comme vous pouvez le voir, échec après 14 secondes - construction. On dirait que quelque chose s’est passé : passons au montage et regardons les détails : il est dit que je n’ai pas pu retrouver un tel souvenir. Pourquoi? Ahhh, exactement, exactement ! Parce que nous avons créé des changements dans la branche master, mais notre tâche n'est pas encore là. Et c'est pourquoi il n'a pas trouvé la mémoire... Par conséquent, maintenant nous procédons comme suit : nous fusionnons ces données dans le maître, puis nous fusionnons la branche principale dans JRTB-0, et ensuite tout devrait bien se passer. Dans une pull request avec des modifications d'actions github, cliquez sur Merge pull request : Et répétez Confirm merge . Ensuite, Github nous propose de supprimer la branche dans laquelle nous avons travaillé. Nous ne refusons pas et ne supprimons pas : Ensuite, je n'ai pas trouvé dans la demande d'extraction de SpringBoot comment extraire les modifications de la branche principale du site Web, nous le ferons donc manuellement via IDEA.

Étape 1 : Mettez à jour la branche principale vers le référentiel local.

L'idée est d'aller sur la branche master, d'appuyer sur ctrl + t et de mettre à jour la branche master :

Étape 2 : Fusionnez les modifications de la branche principale vers la branche JRTB-0.

Passons à JRTB-0 et fusionnons-y le principal.

Étape 3 : pousser les modifications.

Appuyez sur ctrl + shift + k et confirmez la poussée. Maintenant, nous attendons que le build passe et il sera vert !)) Mais il est à nouveau rouge. Qu'est-ce que c'est? Nous entrons dans les journaux d'actions et constatons que nous sommes désynchronisés dans les versions Java. Dans GitHubActions, c'est 8, mais nous utilisons 11 : Maintenant, il y a deux options : soit corriger les actions, soit abaisser la version au huitième. La première option, me semble-t-il, est meilleure et plus correcte. Nous apportons des modifications dans un commit séparé : nous ne travaillerons pas avec Java 8, mais avec Java 11. Et après, finalement, tout s'est bien passé pour nous, et nous avons pu mettre en place notre processus CI pour le projet. De telles choses doivent être mises en place dès le début, afin que vous n’ayez pas à vous en préoccuper plus tard. Vous pouvez maintenant voir que le build est réussi et vous pouvez fusionner sans crainte :

Configuration du travail avec les branches dans le référentiel

Vous pouvez également configurer des éléments tels que des règles dans le référentiel lorsque vous travaillez avec des branches. Je veux faire en sorte que la branche principale ne puisse pas être poussée directement, mais uniquement via des demandes d'extraction, et je veux faire en sorte qu'il soit impossible de fusionner une demande d'extraction si la construction échoue (c'est-à-dire si les actions GitHub échouent à une étape ). Pour ce faire, recherchez le bouton Paramètres et sélectionnez Branches : Pour le moment, il n'y a pas de règles pour les branches, ajoutons-en donc une nouvelle via le bouton Ajouter une règle : Il y a beaucoup de paramètres ici, et chacun peut faire quelque chose qui lui convient. besoins. Pour que la construction réussisse dans la demande d'extraction avant la fusion, ajoutez une case à cocher pour Exiger que les vérifications d'état soient réussies avant la fusion et sélectionnez le statut dont nous avons besoin - construire. Cela suffit pour le moment : vous pourrez ensuite mettre à jour ce volant et voir ce que vous voulez d'autre. Cliquez sur Créer pour créer ce volant. Ensuite, si nous revenons à notre pull request, nous pouvons voir que notre vérification est désormais marquée comme obligatoire : Vérifions notre page de projet, qui affiche tous les statuts des tâches : vous pouvez immédiatement voir sur quelle tâche est en cours de travail. De plus, le travail a déjà été effectué et la tâche est en statut de révision de code.

Fermeture de JRTB-0

Maintenant que nous avons préparé une pull request et créé un CI pour celle-ci, nous devons terminer la dernière étape : fermer la tâche, la déplacer vers le bon statut, examiner les modifications apportées à notre projet sur le tableau. Notre pull request est prête à être fusionnée dans le maître. Dans la pull request, cliquez sur le bouton Merge pull request : Après une fusion réussie, vous pouvez la supprimer, et vous le faites généralement. Je ne ferai pas cela pour vous permettre de voir plus facilement les changements entre les branches/commits. Dès qu'une pull request est fusionnée, elle est automatiquement terminée dans notre tableau de projet : La dernière étape consiste à fermer le ticket (issue) avec un lien vers la pull request dans laquelle il se trouvait : Ce ticket est automatiquement terminé sur le conseil. Le début est fait, la première tâche est accomplie !

conclusions

Il semblerait que nous ayons déjà commencé à travailler et à écrire du code, mais des réglages sont encore nécessaires. Oui, cela prend du temps, mais cela sera rentable au centuple lorsque le projet deviendra plus grand et plus complexe et que vous aurez besoin de garanties que vous ne casserez pas tout avec un seul commit. La pull request où tout cela se produit est disponible ici . Peut-être que lorsque vous le lirez, il sera déjà fermé. Ce n'est pas effrayant : toutes les informations nécessaires seront stockées via le lien. Merci à tous d'avoir lu, à bientôt. En outre!

Une liste de tous les matériaux de la série se trouve au début de cet article.