Comment revenir en arrière des migrations en utilisant Flyway?

Question

Les migrations MyBatis divisent chaque fichier SQL en deux sections :

1. Une pour migrer vers l'avant d'une version
2. Une pour migrer en arrière d'une version

Comment revenir en arrière les versions en utilisant Flyway ?

Answer 1

Alors que Flyway prend en charge les rollbacks (comme une fonctionnalité réservée aux versions commerciales), son utilisation est déconseillée :

https://documentation.red-gate.com/fd/migrations-184127470.html#Migrations-UndoMigrations

Alors que l'idée des migrations d'annulation est intéressante, malheureusement elle échoue parfois en pratique. Dès que vous avez des changements destructeurs (drop, delete, truncate, ...), vous commencez à avoir des problèmes. Et même si ce n'est pas le cas, vous finissez par créer des alternatives faites maison pour restaurer les sauvegardes, qui doivent également être correctement testées.

Les migrations d'annulation supposent que la migration entière a réussi et doit maintenant être annulée. Cela ne résout pas les problèmes des migrations de version échouées sur des bases de données sans transactions DDL. Pourquoi ? Une migration peut échouer à n'importe quel moment. Si vous avez 10 instructions, il est possible que la 1ère, la 5ème, la 7ème ou la 10ème échoue. Il n'y a tout simplement aucun moyen de le savoir à l'avance. En revanche, les migrations d'annulation sont écrites pour annuler une migration de version entière et ne seront pas utiles dans de telles conditions.

Une approche alternative que nous préférons est de maintenir la compatibilité ascendante entre la base de données et toutes les versions du code actuellement déployées en production. Ainsi, une migration échouée n'est pas une catastrophe. L'ancienne version de l'application est toujours compatible avec la base de données, vous pouvez donc simplement annuler le code de l'application, enquêter et prendre des mesures correctives.

Cela devrait être complété par une stratégie de sauvegarde et de restauration appropriée et bien testée. Elle est indépendante de la structure de la base de données et une fois testée et prouvée efficace, aucun script de migration ne peut la rompre. Pour des performances optimales, et si votre infrastructure le permet, nous recommandons d'utiliser la technologie de snapshot de votre solution de stockage sous-jacente. Surtout pour des volumes de données importants, cela peut être plusieurs ordres de grandeur plus rapide que les sauvegardes et restaurations traditionnelles.

Answer 2

Cela est pris en charge depuis Flyway 5.0. Malheureusement, il s'agit d'une fonctionnalité exclusive aux versions commerciales.

https://flywaydb.org/documentation/command/undo

Answer 3

En développement, le retour en arrière du DDL prend en charge une approche itérative sans nécessiter d'arrêt pendant que la base de données et le système de fichiers sont reconstitués pour chaque modification, et en production, le retour en arrière du DDL n'est qu'un autre en avant qui ne sera probablement jamais utilisé, mais qui est bon d'avoir prêt et testé pour corriger rapidement les exceptions dans les applications de flux de revenus de production 7x24 ou les chargements de données si quelque chose d'inattendu se produit.

Par exemple, cela peut résoudre facilement des problèmes tels que :

1. une nouvelle contrainte NOT NULL,
2. une nouvelle contrainte UNIQUE,
3. un enregistrement parent manquant pour une nouvelle contrainte FOREIGN KEY,
4. un changement d'INDEX qui a des effets indésirables,
5. des modifications à un DÉCLENCHEUR (TRIGGER) ou une PROCÉDURE ou une FONCTION stockée,
6. révoquer les autorisations d'accès sur une table toujours utilisée par une opération héritée, ou...

Non une panacée, pas une excuse pour éviter les bons tests, simplement une stratégie utile, j'espère donc que cela suscite une discussion sur son utilisation judicieuse !

Tom

Answer 4

Je suppose que vous avez besoin d'une stratégie de retour en arrière, par exemple si un partenaire échoue à l'étape de production et que son déploiement est essentiel pour votre version.

Vous pourriez nommer vos scripts SQL Flyway de la manière suivante :
V.000_.sql

Maintenant vous pouvez laisser
V.998_rollback.sql pour le retour en arrière
et créer V.999_reenroll.sql pour l'inscription à nouveau.

Dans votre environnement CI/CD, vous aurez besoin de 2 autres tâches (déclenchées manuellement) après votre tâche de déploiement. Une pour le retour en arrière, qui exécute le processus de retour en arrière incluant flyway migrate. L'autre pour l'inscription à nouveau.
Vous devrez simplement vous occuper de la configuration cible dans Flyway.
Pour votre tâche de déploiement, votre cible devrait être .997
Pour votre tâche de retour en arrière .998

Lorsque vous démarrez une nouvelle version, assurez-vous de ne pas exécuter le script de retour en arrière/inscription à nouveau de l'ancienne version.

Comme mentionné précédemment, une stratégie de sauvegarde et de restauration bien testée est la solution recommandée.

(désolé pour le mauvais anglais)