Flyway et liquibase ensemble?
J'ai examiné Liquibase et Flyway individuellement et sur une seule comparaison individuelle, Liquibase semble être le meilleur outil pour nos besoins. Certaines sources mentionnent l'utilisation simultanée de Liquibase et de Flyway. Liquibase semble avoir tout ce que Flyway a et plus de flexibilité en matière de rollbacks. Le principal avantage de Flyway semble ne pas avoir à utiliser XML, mais Liquibase vous permet de spécifier un fichier SQL dans leur XML.
Fondamentalement, je ne sais toujours pas quels seraient les avantages d'utiliser Flyway & Liquibase ensemble par rapport à Liquibase, le cas échéant. Peut-être qu'il y a un moyen de le faire, je ne vois pas que même si Liquibase faisait référence à des fichiers SQL Flyway valides, les deux outils devraient être exécutés indépendamment et toujours avoir les mêmes pièges même si vous pouviez techniquement utiliser l'un ou l'autre outil.
Une petite correction, avant de répondre à la question. L'hypothèse
Liquibase semble avoir tout ce que Flyway a
n'est pas correct. Flyway brille quand il s'agit d'analyser SQL. Vous pouvez utiliser des fichiers SQL non modifiés générés par vos outils natifs contenant toutes sortes de complexité comme les packages et procédures PL/SQL, les changements de délimiteur MySQL, T-SQL, les procédures PostgreSQL, ... Avec Liquibase, vous devrez les diviser en instructions individuelles, ajouter des commentaires supplémentaires aux fichiers SQL, ...
La beauté de pouvoir utiliser vos fichiers SQL tels quels est que vous évitez le verrouillage. Vous pouvez prendre vos fichiers SQL existants, commencer à utiliser Flyway avec un investissement minimal et vous en éloigner plus tard si cela ne correspond plus à vos besoins. Ce n'est pas le cas avec Liquibase.
De plus, la question des migrations vers le bas (pensez-y comme des transactions compensatoires et non des annulations) est vraiment quelque chose qui sonne bien en théorie, mais qui n'est presque jamais nécessaire dans la pratique. Voir https://flywaydb.org/documentation/faq#downgrade
Cependant, en ce qui concerne l'utilisation d'un ou des deux, je suis certainement d'accord avec SteveDonie (membre de l'équipe Liquibase) que l'utilisation d'un seul au lieu des deux ensemble est presque toujours le meilleur choix.
Avertissement: je suis le créateur de Flyway
Je ne recommanderais jamais d'utiliser les deux outils en même temps. D'après mon expérience, même un seul d'entre eux provoque des conflits/collisions de temps en temps dans un grand environnement distribué (plus de 5 équipes ayant accès à la même base de données).
Je vais également vous donner quelques avantages et inconvénients lorsqu'il s'agit de faire fonctionner ces outils dans des projets avec de grandes équipes réparties:
FlyWay:
Inconvénients: Très strict en ce qui concerne les modifications des fichiers de migration. Si quelqu'un a archivé son fichier de migration, il n'est pas recommandé de le modifier. C'est comme utiliser force Push in git dans des projets partagés. La modification d'une migration (soit son contenu, soit le nom du fichier) entraînera un échec de migration sur chaque machine qui avait la version précédente du fichier. L'ensemble du pack de migration devra être exécuté à partir de zéro. Dans certains cas, cela peut prendre beaucoup de temps.
Avantages: Eh bien, ce qui a été décrit dans Cons va, en même temps, développer un niveau de discipline. Cela peut être une restriction raisonnable lorsque l'on parle d'introduire des modifications simultanées par plusieurs équipes dans une application en cours de production.
Liquibase:
Inconvénients: Avec quelques réglages devrait vous permettre de modifier les migrations existantes (appliquées). Bien que cela puisse être considéré comme un avantage, avec beaucoup de personnes travaillant sur la même base de code, une prudence supplémentaire doit être exercée. La flexibilité a un prix. Il est plus facile d'introduire une "régression" ou une incohérence lorsqu'un tel style de changement "git force Push" est autorisé pour les projets distribués.
Avantages: Plus configurable et plus flexible. Pourrait inclure des solutions pour NoSql à l'avenir. Quelques plugins utiles (intégration hibernate, par exemple).