Outil de migration de BD Liquibase ou Flyway ?

Question

Je veux configurer l'outil de migration des bases de données avec mon application web j2ee. L'application est construite en continu par le serveur Hudson. J'utilise à la fois ant et maven avec elle. J'ai donc besoin d'une compatibilité avec ces deux outils (si possible).

À l'avenir, j'ai besoin d'un support pour différentes bases de données pour cette application, ainsi que d'une configuration simple et facile avec l'application.

Actuellement, je regarde Liquibase et Flyway. Je voudrais savoir, en fonction de la situation décrite ci-dessus, lequel des deux sera le meilleur et pourquoi ?

Answer 1

Comme cdeszaq l'a déjà mentionné, le matrice de comparaison des caractéristiques sur le Page d'accueil de l'itinéraire aérien est un bon point de départ.

Les deux sites Liquibase et Voie de migration ont l'intégration de Maven et Ant.

L'étape suivante consiste à déterminer si vous pouvez vous contenter des formats XML ou SQL annoté de Liquibase ou si vous préférez ou exigez du SQL pur et si vous avez besoin de migrations Java.

Chacun a ses avantages et ses inconvénients :

• Liquibase XML : Le plus petit dénominateur commun, un format indépendant de la base de données. Il vous libère de l'écriture DDL et est compatible avec toutes les bases de données. Verrouillage par le fournisseur (peut ou non être un problème).
• SQL annoté de Liquibase : SQL avec métadonnées Liquibase dans les commentaires (doit être présent). La DDL est convertie en XML Liquibase avec des blocs SQL personnalisés au moment de l'exécution. Peut ou non être compatible entre les bases de données.
• Plain SQL (supporté par Flyway) : Fichier SQL DDL ordinaire. Peut ou non être compatible entre les bases de données. Pas d'annotations spéciales. Les vidages de structure de BD utilisant des outils de BD natifs peuvent être utilisés tels quels. Pas de constructions spécifiques aux outils. Pas de verrouillage.
• Migrations Java (supportées par Flyway) : Les migrations sont des classes Java utilisant l'API JDBC. Idéal pour traiter les LOBs et les transformations de données complexes. Peuvent ou non être compatibles avec d'autres bases de données. Verrouillage des fournisseurs (peut ou non être un problème).

Une petite note sur la portabilité des DDL : les BD en mémoire comme H2 ont de bons modes de compatibilité avec les BD "réelles". Cela peut éliminer le besoin d'une abstraction supplémentaire.

Ce sont d'autres facteurs de différenciation potentiels à rechercher :

• si vous souhaitez utiliser les vidages de bases de données (y compris ceux utilisant PL/SQL, T-SQL ou les procédures stockées de MySQL et PostgreSQL) : Optez pour Flyway.
• si la DDL est incompatible entre les bases de données, que le XML de Liquibase ne vous dérange pas et que vous n'avez pas besoin de fonctionnalités avancées spécifiques au fournisseur : Choisissez Liquibase.
• si vous avez besoin d'un support pour une BD non supportée par Flyway : Choisissez Liquibase.
• si vous avez besoin d'un support pour les LOBs (dans les données de référence par exemple) : Optez pour Flyway.

Cela nous amène à la question suivante simplicité et intégration des applications . C'est dans ce domaine que je pense que Flyway brille. Il est très léger et le intégration des applications ne pourrait pas être plus facile.

Pour faire une longue histoire courte et dans l'esprit de YAGNI : utiliser l'outil le plus simple qui correspond à vos besoins .

Note : La question des migrations descendantes est un faux-fuyant comme je l'ai décrit. ici

Clause de non-responsabilité : Je suis l'un des développeurs de Flyway et j'attends avec impatience vos commentaires. :-)

Answer 2

Flyway semble être un outil très similaire : léger, simple à utiliser et doté d'une bonne intégration. Je pense que vous rencontrerez moins de résistance de la part de vos collègues développeurs et DBA, si toutes les modifications de la base de données restent en SQL.

Personnellement, je m'en tiendrai à liquibase, qui offre des fonctionnalités plus puissantes :

• Tout changement de base de données est modélisé comme un "remaniement". Rend retour en arrière faisable.
• Génération de Scripts SQL pour examen par le DBA
• Extraire les schémas de base de données d'une base de données existante
• Opération de diffusion entre les instances de la base de données
• Prise en charge de plusieurs bases de données
• Exécution conditionnelle des changesets (basée sur DB , contexte ou si le changeset a été modifié).

Answer 3

Compte tenu de votre exigence listée de "Dans le futur, j'ai besoin d'un support pour différentes bases de données", je pense que Liquibase fonctionnera mieux pour vous. FlyWay est conçu autour de l'exécution de scripts SQL bruts qui sont spécifiques à la base de données alors que Liquibase a l'option de décrire vos changements d'une manière neutre par rapport à la base de données de sorte que la même mise à niveau script peut être utilisée avec plusieurs types de bases de données. Si vous commencez avec flyway (ou Liquibase en utilisant du sql formaté), cela fonctionnera bien jusqu'à ce que vous essayiez de déployer sur un type de base de données différent et que vous deviez réécrire votre script de modification.

Si le support des bases de données croisées était moins important, vous pourriez alors comparer les autres fonctionnalités et principes de conception de Liquibase et de FlyWay. La comparaison d'Axel est bonne, même si je ne considérerais pas FlyWay comme étant plus "simple" que Liquibase. Bien que Liquibase dispose de plus de fonctionnalités (comparaison/différence de bases de données, paramètres de journal des modifications, conditions préalables, dbdoc, génération de script de retour en arrière, sortie sql à exécuter), le cas normal de "ajouter un changement à appliquer à toutes nos bases de données" est tout aussi simple dans Liquibase que dans FlyWay.

Je résumerais les différences comme suit :

• FlyWay est de "niveau inférieur", vous spécifiant exactement le SQL que vous voulez exécuter, tandis que Liquibase est de "niveau supérieur", vous spécifiant ce que vous voulez modifier et Liquibase calculant le SQL.
• FlyWay gère les changements par nom de fichier alors que Liquibase gère les changements par ordre dans un fichier.

Avertissement : je suis un développeur Liquibase

Answer 4

Le site Page du projet Voie de migration semble avoir un bon tableau comparatif qui aborde ces points...

Je vous conseille d'essayer les deux (ou au moins de lire leur documentation), puis d'utiliser celui qui vous semble le meilleur. Ensuite, si cela ne fonctionne pas, vous avez toujours la majorité du travail (les migrations réelles) et vous pouvez assez facilement changer.

Dans les deux cas, les cadres sont assez légers, de sorte qu'ils n'ajoutent pas beaucoup d'éléments supplémentaires pour que les migrations fonctionnent.

Answer 5

Il existe un autre outil, appelé Autopatch

J'ai utilisé DbDeploy dans le passé, mais je veux un moyen de prendre en charge tout système de données externe. Autopatch semble avoir été conçu dans cet esprit alors je vais tenter le coup.