SpringBoot + Flyway - "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. Dans cette partie, nous essayons de lancer SpringBoot et Flyway. Le minimum de théorie, comme vous le souhaitez))) Nous omettons la comparaison finale de Flyway/Liquibase pour une période de temps indéfinie et allons droit au but. Et pourtant, cela a déjà traîné. Afin de ne pas décrire Flyway deux fois, j'ai décidé de l'ajouter immédiatement à notre futur projet JRTB.

Que devons-nous faire dans ce cadre ?

1. Lancez une application SpringBoot basée sur Maven.
2. Ajoutez-y Flyway : heureusement, ils s’intègrent facilement.
3. Ajoutez un schéma pour les tables que nous avons dans la base de données exemple.

De cette façon, nous apprendrons à travailler avec Flyway. Pourquoi un projet séparé, et pas immédiatement dans notre JRTB ? Parce que plus tard, quiconque voudra comprendre comment procéder aura un projet avec un exemple et un article décrivant son utilisation. Eh bien, allons-y !

Qu'est-ce que la voie de migration

Pour utiliser quelque chose, vous devez d’abord comprendre de quoi il s’agit et pourquoi. Flyway est un outil de contrôle de version de base de données. Les mots sont bien connus, mais d’une manière ou d’une autre, la compréhension n’a pas été ajoutée, n’est-ce pas ? Essayons de décrire le problème que résout la voie de migration. Disons que nous avons un projet. Comme tout dans notre monde, ce n'est pas parfait, il n'a donc pas été possible de planifier et d'élaborer la version finale du projet. À chaque fois, certaines nuances inexpliquées apparaissent. Le projet utilise une base de données dans son travail. Bien entendu, si le projet change, la structure de la base de données peut également changer. Disons que nous ajoutons un nouveau champ pour l'une des entités de notre projet. Comment faire?

1. Ajoutez ce champ à notre entité, mettez tout à jour pour que la logique métier fonctionne.
2. Mettez à jour la base de données. La seule façon possible est de le faire manuellement. Pour ce faire, vous devez entrer et enregistrer le script SQL nécessaire.

Le deuxième point soulève de nombreuses questions :

1. Mais si nous avons plus d’un endroit où nous déployons notre projet, cela doit-il être fait dans chacun d’entre eux ?
2. et si nous voulons revenir en arrière, comment savoir exactement dans quel état se trouve actuellement la structure de la base de données ?
3. Comment serons-nous sûrs que le changement de base de données a réussi ?
4. Comment puis-je avoir la possibilité de suivre toutes les modifications de la base de données survenues sur le projet ?

Si vous le faites manuellement, les réponses ne seront pas les meilleures… Pour éviter toutes ces difficultés, vous pouvez utiliser un outil de migration de bases de données. L’un d’eux est Flyway. Quel est son métier? Dans le cadre du projet, nous stockons des fichiers SQL séparés (appelés migrations), qui stockent simultanément tout ce que nous faisons avec la base de données. Toutes les migrations s'effectuent strictement dans un certain ordre, ce qui vous permet de suivre les changements dans la structure et les données de la base de données (souvent, à l'aide de la migration, des données de test sont ajoutées au projet de sorte que lorsqu'il est déployé sur un serveur, il en ait déjà valeurs avec lesquelles vous pouvez tester le projet). Une fois les tests réussis, les migrations sont lancées lors de la construction du projet. Ils se connectent à la base de données et effectuent des migrations. Si des migrations ont déjà été effectuées sur cette base de données, alors flyway les ignorera simplement (il stocke les données sur les migrations et leur statut dans une table séparée de la base de données, ce qui permet de les gérer), et si une migration a échoué, alors le projet build et son montage (déploiement) sur le serveur s'arrêteront. J'ai essayé de le décrire avec le plus de détails possible. Si tout n’est pas encore tout à fait clair, ce n’est pas grave : avec la pratique, la compréhension viendra.

Lancez SpringBoot + Flyway

Qu'est-ce que Spring Boot

Que lançons-nous ?... Pour comprendre ce que nous faisons et pourquoi, vous devez décider ce qu'est SpringBoot. Tout d’abord, parlons rapidement (enfin, très rapidement) de Spring . À l’heure actuelle, il s’agit de la norme industrielle de facto en matière de développement d’applications serveur en Java. Norme de quoi ? Comment puis-je vous expliquer cela ? Spring est le squelette de l'application, sur lequel nous jetons ensuite la « viande » - notre logique métier. Avec l'aide de Spring (ci-après j'utiliserai ce papier calque pour ne pas perdre de temps à changer de langue :D)) Spring nous donne un point de départ à partir duquel nous commençons à tout faire. Il est multifacette, multimodulaire :

1. Voulez-vous travailler avec une base de données ? Envie de relationnel ? Voulez-vous du non relationnel ? Nous voici avec Spring Data.
2. Voulez-vous travailler avec des requêtes http ? Et voilà, Spring Web (Spring MVC).
3. Avez-vous besoin d'un conteneur pour tous vos objets en un seul endroit ? Voici Spring Core.
4. Avez-vous besoin de mettre en place la sécurité sur un projet afin qu'il y ait différents rôles et chaînes de commandement ? Sécurité du printemps.
5. Juste au moment où vous pensiez que ce serait bien d'avoir une telle chose, il s'avère que Spring a déjà ce dont vous avez besoin et qu'il s'intègre rapidement et facilement.

Par conséquent, nous pouvons dire qu'il ne s'agit pas seulement d'un framework (une bibliothèque aussi immense), mais de tout un écosystème qui se développe à un rythme effréné. Pour comprendre ce qu'est Spring Core, c'est-à-dire la base à laquelle sont connectés les modules, je vous conseille de regarder une démo en direct sur la création de votre propre framework. Il est hébergé par Evgeny Borisov, un gars très cool dans le domaine de Java et Spring. Faites tout ce qu'il a fait, et l'œuvre du printemps vous deviendra plus claire. SpringBoot, à son tour, est le summum de tout ce dont ils disposent. La magie de l'eau pure. Paramètres minimaux pour effectuer le premier lancement de l'application. Bien sûr, cela ne vous permettra pas de comprendre comment l’utiliser et quoi faire. Mais avant de vous lancer dans les profondeurs du développement, vous devez tout regarder à vol d'oiseau.

Lancement de SpringBoot

Puisque nous avons déjà compris ce qu'est Maven, créons un nouveau projet pour nos besoins. Pour cela, il vous suffit de vous rendre sur un site internet spécialement créé à cet effet. Cela s'appelle Spring Initializr . Ici, vous devez remplir et sélectionner ce dont vous avez besoin :

1. L'outil de construction de projet est Gradle ou Maven. Comme vous pouvez le constater, Ant n’est même plus mentionné. C'est un bon indice sur les outils de construction qui valent la peine.
2. Le langage dans lequel vous pouvez écrire est Java, Kotlin, groovy. Tout est simple ici : ils sont tous de type JVM et exécutent facilement du code Java. Soit dit en passant, cela vaut la peine de regarder Kotlin. Le Groovy est franchement devenu inintéressant (il fut un temps où ils passaient au groove, mais c'est vite passé).
3. Version Spring... Ici, vous devez comprendre que les versions de la partie principale de Spring et de ses modules sont cohérentes.
4. Données du projet. J'ai déjà décrit ces choses.
5. Nous choisissons quelles archives seront collectées - Jar ou War.
6. Eh bien, la version Java de notre préférée. Et récemment, il y a eu beaucoup de ces versions... Elles ont attendu des années, et maintenant il y en a deux par an.

Dans notre cas, nous publierons ce projet dans l' organisation JavaRush Community , les informations sur le projet seront donc appropriées :

1. Maven - ce n'est pas pour rien que nous vous en avons parlé plus tôt.
2. Java est notre chéri :D
3. Prenons la version 2.2.11. Pourquoi pas le plus récent ? Parce que plus il est récent, plus il y a de chances qu’il y ait des bugs. Pour nous, peu importe la version, mais l’ancienne sera plus fiable. Par conséquent, nous choisissons 2.2.11.
4. Groupe : com.github.javarushcommunity
5. Artefact : springboot-flyway-demo
6. Nom : Démo SpringBoot + Flyway
7. Description : le projet démontre l'intégration entre SpringBoot et Flyway . (Oui, la capacité de rédiger de la documentation est une partie importante du développement :))
8. Nom du package : com.github.javarushcommunity.springbootflywaydemo . Ici, ils créeront immédiatement pour nous un package de base avec une classe qui lancera notre application.
9. Conditionnement : Pot
10. Java : 8. N'allons pas devancer la locomotive et prenons le bon vieux huit. Pourquoi pas 11 ? Pourquoi? Pour notre exemple, je ne vois pas l’intérêt.

Ajoutons maintenant les modules. Nous devons trouver l’intégration avec Flyway. Vous pouvez également ajouter quelque chose lié à MySQL et Spring Data. Ajoutons un autre lombok (c'est une chose très nécessaire, faites-moi confiance pour l'instant :D)) Pour ce faire, cliquez sur AJOUTER DES DÉPENDANCES ... et sélectionnez tout ce dont vous avez besoin : C'est ainsi que nous ajoutons Flyway. Lombok... Et ainsi de suite. Le résultat, nous obtenons : Hein... nous avons tout rempli)) Cliquez maintenant sur GÉNÉRER... et c'est tout - l'archive avec le projet généré est prête :) Il y a aussi une chose aussi cool que PARTAGER... , qui vous donne un lien vers la page que vous venez de remplir. Autrement dit, voici celui que j'ai généré . Et même si quelque chose ne va pas, vous pouvez toujours vérifier en utilisant le lien. Ensuite, nous devons lier le projet créé au référentiel Git, nous clonons donc le projet springboot-flyway-demo créé et le téléchargeons via IDEA. Pour ce faire, vous devez ouvrir l'idée et sélectionner Fichier -> Nouveau -> Projet à partir de sources existantes... : Ajoutez maintenant l'URL et cliquez sur Cloner . L'étape suivante consiste à transférer les éléments internes du projet généré dans celui que nous avons cloné. Confus? Je vais vous montrer maintenant. Je l'ai décompressé et j'ai reçu l'ensemble de fichiers suivant : Ceux-ci doivent être transférés vers le projet cloné. Comme dans l'article précédent, ajoutons pom.xml en tant que projet maven : nous souhaitons maintenant examiner ce qui a été généré pour nous. Si vous ouvrez tous les dossiers dans src et au-delà, vous verrez la hiérarchie habituelle dans les projets Maven, dont nous avons parlé dans l'article précédent . Pour ceux qui ne l'ont pas lu, lisez-le ! On peut voir que nous avons une classe Application et que notre application SpringBoot sera lancée en l'utilisant. Grâce au plugin Maven pour SpringBoot, nous avons désormais la tâche dont nous avons besoin pour Maven, à savoir spring-boot:run. Où peut-on trouver ces informations ? A droite, en ouvrant la plaque Maven et notre projet : Il y aura une erreur, et nous ne pourrons pas la lire, nous verrons quelque chose comme ceci : Pour avoir plus d'informations, pour plus de rapidité nous pouvons exécuter la méthode main de la classe Application : Et puis nous verrons la vraie raison : Ici déjà Il y a plus d’informations et vous pouvez en faire quelque chose. Qu'est-ce qui ne va pas? Nous avons des dépendances associées à la base de données et nous devons donc fournir des paramètres pour nous y connecter. Pour ce faire, nous recherchons sur Google et constatons que nous devons ajouter les configurations suivantes à application.properties :

spring.datasource.url=jdbc:mysql://localhost:3306/flyway_demo_db
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

Nous exécutons à nouveau la méthode principale et obtenons : Nous devons maintenant ajouter au moins une migration. Pour créer correctement une migration, vous devez prendre le modèle suivant : V<VERSION>__<NOM>.sql A l'aide de ce modèle, nous allons créer un fichier de migration nommé V00001__Create_country_table.sql dans le dossier approprié : /src/main/resources/ db.migration/ . Créons-y une table de pays. Prenons le script du deuxième article sur la base de données . Avant de commencer, créons une base de données pour le travail : flyway_demo_db. Faisons cela via MysqlWorkbench : nous pouvons maintenant exécuter à nouveau la méthode principale : tout s'est bien passé, mais comme nous n'avons encore rien dans le projet, il a fini de fonctionner. Cependant, il ressort clairement des journaux ( lisez ce que sont les journaux ) que :

1. Connexion réussie à la base de données.
2. La migration a été validée et tout est ok.
3. Flyway a créé un tableau pour gérer les migrations.
4. Et quelle migration 00001 a commencé - la création du pays a été réussie.

Pour vérifier cela, vous pouvez aller voir ce qui se fait dans la base de données. Allons donc sur notre serveur MySQL et voyons ce qui se passe avec les tables de la base de données flyway_demo_db : $ USE flyway_demo_db; $AFFICHER LES TABLEAUX ; Comme je m'y attendais, une migration a eu lieu, au cours de laquelle la table country a été créée et la table flyway_schema_history est apparue, qui stocke des informations sur les migrations. Allons plus loin et voyons quels enregistrements existent (et s'il y en a). $SELECT * FROM flyway_schema_history; Voici l'enregistrement, le seul. Il contient de nombreuses données intéressantes. Version, description de la migration, quel type de SQL (et peut-être aussi XML), le nom du script lui-même, somme de contrôle ( c'est quelque chose comme un hashcode, qui est utilisé pour vérifier si la migration a changé ou non. Ceci est fait dans le cas où nous avons effectué une migration dans la base de données et qu'elle a ensuite été corrigée : cela ne peut pas être fait, toutes les modifications sont effectuées uniquement via une nouvelle migration et pour éviter que cela ne se produise, le montant du contrôle surveille cela ), nom SQL de l'utilisateur, traitement de la migration date, heure d'exécution et résultat (réussite ou échec) . Une migration écrite une seule fois ne doit pas être modifiée à l'avenir. Même s'il y a un défaut. Tous les changements ont lieu uniquement via une nouvelle migration. Il est très important. Pour montrer ce qui va se passer, modifions un peu notre script et essayons de le réexécuter. Ajoutons une entrée à la table des pays dans notre migration : et exécutons la méthode main et voici ce que nous obtenons : Comme je m'y attendais, flyway a reconnu que le script avait été modifié et n'a pas effectué la migration. Dans certains cas, il peut être nécessaire d'exécuter une migration mise à jour, et pour que flyway ignore cette opération, vous devez supprimer l'entrée dans la table flyway_schema_history, puis exécuter la migration mise à jour. Ce n'est pas un comportement normal et ne devrait pas l'être, mais vous devez également connaître cette méthode pour résoudre le problème. Nous avons traité de la première migration. Maintenant, je voudrais ajouter une autre migration, avec des données sur les pays, comme c'était le cas dans l'article sur la base de données : fichier V00002__Add_test_data_to_country.sql Et exécutons à nouveau la méthode principale : d'après les journaux, il est clair qu'avant le début de la migration, la base de données était en version 00001, donc toutes les migrations après cette version. Ensuite, la version 00002 a été lancée et a réussi. Vérifions, ou croyez-vous déjà que trois enregistrements par pays seront déjà dans la base de données ?)) Je vérifierais, donc preuve : Quelque chose comme ça. Si vous exécutez à nouveau le projet, flyway ignorera simplement le déploiement des migrations, car la base de données est entièrement conforme à la version requise.

Conclusion

Cette fois, nous avons appris à comprendre et à utiliser un outil de migration de base de données en conjonction avec SpringBoot. Ces informations sont nécessaires pour comprendre ce qu'est un outil de contrôle de version de base de données, en utilisant Flyway comme exemple. Amis, le code source du projet que j'ai montré est publié dans notre organisation sur Github . Si vous aimez l'exemple, donnez-lui une étoile et je comprendrai que mon travail est utile et vaut vraiment la peine d'être poursuivi. Traditionnellement, je suggère de m'abonner à mon compte Github . Grâce à lui, je mène tous mes travaux sur l'open source et tous ces projets de démonstration qui accompagnent invariablement mes articles. Merci à tous d'avoir lu. La prochaine fois, nous rédigerons notre candidature. Il y aura une certaine théorie nécessaire sur Docker à l'avenir, mais nous la diluerons fortement avec la pratique.

Liens utiles

Aujourd'hui, il n'y a pas beaucoup de liens utiles. Faites attention à la vidéo d'Evgeniy, ça vaut vraiment le coup !

1. Site de création de projets sur Spring
2. Evgeniy Borisov — Constructeur de ressorts
3. Documentation au printemps pour Flyway

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