Pourquoi et quand Liquibase?
J'ai essayé de chercher cette question sur le débordement de pile mais n'ai trouvé aucune question pour ceci. Je suis nouveau sur liquibase et veut savoir pourquoi liquibase? Et quand exactement faut-il utiliser liquibase dans le projet?
Je sais que cela consiste à conserver toutes les modifications de base de données au même endroit, mais la même chose peut être faite en créant un simple fichier SQL dans un système de référentiel et en le mettant à jour régulièrement.
La différence essentielle entre un fichier de création de schéma auto-géré et Liquibase (ou d'autres outils migration de schéma ) est que ces derniers fournissent un journal des modifications de schéma. Ceci est un enregistrement des changements de schéma au fil du temps. Il permet au concepteur de base de données de spécifier les modifications dans le schéma et permet la mise à niveau ou la dégradation par programme du schéma à la demande.
Il y a d'autres avantages, tels que:
- Indépendance du fournisseur de base de données (c'est discutable, mais ils essaient)
- documentation automatisée
- base de données diffs
Un autre outil est voie de migration .
Vous choisiriez d'utiliser un outil de migration de schéma lorsque vous souhaitez ou devez gérer automatiquement les mises à jour de schéma sans perte de données. En d'autres termes, vous vous attendez à ce que le schéma change après le déploiement de votre système dans un environnement à longue durée de vie, tel qu'un site client ou un environnement de test stable.
J'ai vu liquibase créer une discipline parmi les développeurs en matière de modification de schéma. Vous ne pouvez tout simplement pas écraser les modifications d’autres développeurs et les exécuter. Au lieu de cela, vous créez votre propre jeu de modifications, ajoutez-le à la fin de la séquence de modifications à exécuter. Cela apporte également une clarté sur ce que le changement est arrivé quand et qui l'a apporté.
Une approche très "versionnée" de la maintenance du schéma.
Pour commencer, cela donne une impression de "travail inutile".
Lorsque vous avez plusieurs instances de base de données dans dev, qa, production et que vous souhaitez disposer d'un outil pour suivre automatiquement l'historique des modifications et appliquer intelligemment les modifications (appliquer le diff du schéma actuel et du schéma final), des outils tels que liquibase ou flyway seront très utiles. .
Je pense qu'il est possible de répondre à Pourquoi liquibase si vous consultez l'article ci-dessous http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html
Si vous le lisez attentivement, il est très utile de pouvoir passer à une version inférieure d’une version supérieure à l’aide de simples commandes mvn ou CLI, ce que vous n’obtiendrez pas si vous passez par l’approche consistant à valider votre fichier SQL dans GIT, vous devez exécuter manuellement ces scripts et vous n’avez pas non plus l’ensemble des modifications comme: - qui a créé l’auteur des modifications, etc.
Je crois que Liquibase est formidable lorsque votre philosophie est que la base de données est une réflexion après coup. Cette philosophie a causé la majorité des mauvaises bases de données en production - et la plupart d’entre elles sont mauvaises. Une base de données doit être conçue avec une vue complète du système d'entreprise dans son ensemble, et non pas composée par les développeurs d'applications, chacun travaillant dans son propre silo. Cette dernière méthode donne lieu à des solutions de contournement, à des données dénormalisées, à de mauvaises relations entre les tables, à la duplication des domaines d’activité, ainsi qu’à un système complexe, au coût de maintenance élevé, que le client haïra peu après son déploiement en raison des problèmes qu’il provoque. Si une base de données est conçue pour refléter avec exactitude les relations commerciales, sa durée de vie sera 5 fois plus longue et sa fonction sera 5 fois plus efficace que celle conçue au cas par cas, comme la plupart d’entre elles le sont malheureusement.
Liquibase n'est pas un problème en soi, mais permet aux développeurs d'applications de concevoir la base de données. C'est le problème.
En tant que personne DevOps de mon équipe, je préférerais avoir tous mes fichiers SQL à un seul endroit, c’est-à-dire dans mon SCM (Gestion du code source)
Aussi pendant la phase CI /CD, si le schéma de base de données est créé en même temps, cela économise beaucoup de temps et de ressources. Il ne serait pas nécessaire qu'une autre personne gère votre base de données pour ce client.
ORM comme Flyway, Liquibase, EF, etc. aide à y parvenir.