Comment annuler les migrations en utilisant Flyway?
Les migrations MyBatis divisent chaque fichier SQL en deux sections:
- Un pour migrer vers l'avant une version
- Un pour la migration d'une version en arrière
Comment peut-on restaurer des versions en utilisant Flyway ?
Alors que Flyway prend en charge les rollbacks (en tant que fonctionnalité commerciale uniquement), son utilisation est déconseillée:
https://flywaydb.org/documentation/command/undo
Bien que l'idée d'annuler les migrations soit agréable, elle se décompose malheureusement parfois dans la pratique. Dès que vous avez des changements destructeurs (drop, delete, truncate,…), vous commencez à avoir des ennuis. Et même si vous ne le faites pas, vous finissez par créer des alternatives maison pour la restauration des sauvegardes, qui doivent également être testées correctement.
Les migrations d'annulation supposent que la migration entière a réussi et doit maintenant être annulée. Cela n'aide pas en cas d'échec des migrations versionnées sur des bases de données sans transactions DDL. Pourquoi? Une migration peut échouer à tout moment. Si vous avez 10 relevés, il est possible que le 1er, le 5e, le 7e ou le 10e échoue. Il n'y a tout simplement aucun moyen de savoir à l'avance. En revanche, les migrations d'annulation sont écrites pour annuler une migration versionnée entière et n'aideront pas dans de telles conditions.
Une approche alternative que nous jugeons préférable est de maintenir la compatibilité descendante entre la base de données et toutes les versions du code actuellement déployées en production. De cette façon, une migration ayant échoué n'est pas une catastrophe. L'ancienne version de l'application est toujours compatible avec la base de données, vous pouvez donc simplement restaurer 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. Il est indépendant de la structure de la base de données et, une fois testé et éprouvé, aucun script de migration ne peut le casser. Pour des performances optimales et si votre infrastructure le prend en charge, nous vous recommandons d'utiliser la technologie de capture instantanée de votre solution de stockage sous-jacente. Surtout pour les volumes de données plus importants, cela peut être plusieurs ordres de grandeur plus rapide que les sauvegardes et les restaurations traditionnelles.
Ceci est pris en charge depuis Flyway 5.0. Malheureusement, c'est une fonctionnalité commerciale uniquement.
Je suppose que vous avez besoin d'une stratégie de restauration, par exemple un partenaire échoue au stade de la production et son déploiement est essentiel pour votre sortie.
Vous pouvez nommer vos scripts SQL Flyway comme suit:
V <YourReleaseNumber> .000_ <description> .sql
Maintenant tu peux partir
V <YourReleaseNumber> .998_rollback.sql pour la restauration
et faites V <YourReleaseNumber> .999_reenroll.sql pour vous réinscrire.
Dans votre environnement CI/CD, vous avez besoin de 2 travaux supplémentaires (déclenchés manuellement) après votre travail de déploiement. Un pour la restauration, qui exécute le processus de restauration, y compris la migration par voie de migration. Autre pour réinscription.
Il vous suffit de prendre soin de la configuration cible dans la voie de migration.
Pour votre travail de déploiement, votre cible doit être <YourReleaseNumber> .997
Pour votre travail de restauration <YourReleaseNumber> .998
Lorsque vous démarrez une nouvelle version, assurez-vous de ne pas exécuter le script de restauration/réinscription de l'ancienne version.
Comme indiqué précédemment, une stratégie de sauvegarde et de restauration bien testée est la solution recommandée.
(essaye le mauvais anglais)