Migration de schéma: SQL Server Data Tools vs Liquibase et Flyway

Cela peut sembler une question stupide, mais j'ai cherché des solutions open source pour la migration de schémas, à savoir Liquibase et Flyway.

Cependant, mon patron m'a dit que SQL Server Data Tools (SSDT) ​​accomplit le même travail. Je ne suis pas sûr d'être d'accord, mais je peux trouver très peu sur Internet qui le compare directement à Liquibase et / ou Flyway.

Mon point de vue est que SSDT est un outil de développement, de modélisation et de conception de données pour SQL Server et prend également en charge la comparaison de schémas (et la génération de scripts de ceux-ci) et le contrôle des sources. Il s'attaque à un problème différent bien qu'il puisse y avoir un certain chevauchement avec Liquibase / Flyway dans certains aspects de la migration de schéma. Mais en tant qu'outil de migration de schéma global, Liquibase et Flyway sont des outils entièrement dédiés tandis que SSDT est davantage destiné à la conception et au développement d'une base de données.

Tout avis serait très apprécié, même si c'est juste pour dire qu'il n'y a pas de comparaison et que le SSDT n'est pas du tout un outil de migration de schéma en soi.

SSDT est comparable à Liquibase / Flyway car il fait ce qu'il fait mais en adoptant une approche différente. Avec SSDT, vous disposez de l'environnement de développement pour obtenir des éléments tels que la définition, la recherche de références et d'intellect, ainsi que la possibilité de compiler un projet dans un dacpac, puis de déployer ce dacpac dans une base de données.

La méthode SSDT (et la méthode de comparaison SQL Redgate) pour effectuer un déloyment consiste à déclarer ce que vous voulez, donc si vous souhaitez modifier une table qui ressemble à:

create table a(id int)

à une table qui ressemble à:

create table a(id int, another_column varchar(12))

avec SSDT, vous changez simplement votre définition de table en la seconde et laissez SSDT s'inquiéter de la façon de la mettre à niveau (peut-il faire une modification de table, ajouter une colonne ou l'ordre des colonnes change-t-il donc vous devrez reconstruire la table, etc.).

Avec Liquibase (DbUp, ReadyRoll, méthodes manuelles, etc.), dans ce cas, vous devez écrire la table alter vous-même et vous assurer que vous exécutez les scripts dans le bon ordre, envisagez ce scénario:

1. Version 1 - créer une colonne bonjour sur la table
2. Version 2 - renommer la colonne bonjour en joe_blogs
3. Release 3 - rename column joe_blogs to hello
4. Version 4 - créer une colonne joe_blogs

Si l'une des versions est manquée, aucune des suivantes ne peut continuer.

Avantages des scripts de mise à niveau (Liquibase, DbUp, etc.):

• Vous avez un contrôle total sur les scripts
• Les DBA / développeurs sont habitués à cela

Avantages de la comparaison / fusion (SSDT, Redgate SQL Compare):

• Pas besoin d'écrire des scripts de mise à niveau
• Il est facile d'accéder à n'importe quelle version spécifique, il suffit de comparer et de fusionner cette version

Inconvénients des scripts de mise à niveau:

• Doit être exécuté dans l'ordre
• Comptez sur les humains sans faire d'erreurs
• Peut être lent surtout si vous avez beaucoup de changements
• À moins que votre équipe ne soit très disciplinée, les bases de données dans différents environnements (dev, test, staging, prod, etc.) sont souvent désynchronisées, rendant tout test invalide
• Rétrograder une version signifie écrire l'inverse de tous les scripts que vous avez déjà écrits

Inconvénients de l'utilisation de la comparaison / fusion:

• Les outils ne sont pas fiables à 100%, peut-être injustement
• SSDT nécessite un projet fonctionnel, de nombreuses bases de données ont du code qui ne se compile ou ne s'exécute pas réellement (pensez aux tables supprimées mais pas aux procédures, etc.), j'ai vu cela dans environ 8/10 bases de données dont j'ai hérité :)
• De nombreux DBA / développeurs hésitent à abandonner le développement dans SSMS / bloc-notes

Personnellement, je pense vraiment que SSDT est un environnement de développement professionnel et cela signifie que je peux me concentrer sur l'écriture de code et de tests utiles plutôt que sur l'écriture de scripts de mise à niveau qui ne sont en eux-mêmes qu'un moyen de parvenir à une fin.

Vous avez demandé des opinions alors vous y allez :)

ed

Je viens de compléter la réponse de prévision.

La plus grande différence décrite sur le site Web de Flyway sur la place centrale:

Résout un seul problème et le résout bien. Flyway migre votre base de données, vous n'avez donc plus à vous en soucier.

Visual Studio + SSDT + SSIS = outil ETL à pleine puissance, avec un seul inconvénient réel - il ne fonctionne que sous Windows Il a besoin de Windows + SQL Server pour exécuter les packages, mais fonctionne avec la plupart des sources.

Pour transférer / migrer des données - beaucoup de produits sur le marché. Commercial, Open Sources, Communauté / Express et etc.

Pour migrer du code - tout n'est pas si bon. Même si le logiciel promet de "convertir les déclencheurs, les procédures et les fonctions sans problème", en fait - seulement une migration simple et la plupart du code - manuel.

J'ai travaillé avec les outils de données du serveur SQL et Flyway. En utilisant SSDT, j'obtiens les avantages suivants:

1. Je peux compiler le projet de base de données .. ce qui signifie qu'il n'y a aucune crainte de supprimer une colonne référencée par une vue, une fonction ou des procs stockés. Ceci est une excellente fonctionnalité, car dans le passé, nous n'avons trouvé de tels échecs qu'après la sortie

2. Après une construction réussie, SSDT génère ce que l'on appelle un "DACPAC". Pensez à cela un msi avec une version.

3. Un dacpac donné, avec par exemple la version 5, peut être appliqué à une base de données qui se trouve sur la version Dacpac 1,2,3,4 ou 6,7,8 etc. Si elle est appliquée à 1-4, la base de données sera mise à niveau. Si appliqué à 6,7 etc., la base de données sera rétrogradée / annulée. Il y aura des avertissements, en cas de perte de données, qui peuvent être supprimés. Ainsi, nous obtenons une excellente fonctionnalité de restauration, qui n'est pas disponible avec d'autres outils comme flyway, etc. Avec flyway, il faut fournir un nouvel ensemble de scripts pour la restauration.

4. DACPAC applique toutes les modifications en une seule transaction; ce qui signifie que s'il y a 5 changements de table dans la mise à niveau et que l'un d'entre eux échoue, la transaction entière est annulée. Flyway le prend également en charge, mais pour chaque fichier.

Cependant, SSDT et DACPAC sont spécifiques à Microsoft SQL Server; flyway peut être utilisé pour une variété de bases de données.

Donc, en fin de compte, si vous utilisez uniquement SQL Server, il devrait être assez facile de choisir SSDT et DACPAC.