Lors des phases de développement et de maintenance, il est souvent difficile de gérer les versions de bases de données différentes entre les différentes versions des applicatifs. On se retrouve souvent avec différents schémas de bdd qui ne possèdent jamais les bonnes versions des données. De plus, quand on souhaite mettre en production, il est difficile de faire la mise à jour des données de production en passant plein de scripts à la main.
Flyway se propose d’uniformiser les pratiques avec une librairie très facile à utiliser, pour faire la migration proche en proche des schémas de bdd !
Flyway permet de garder l’historique des modifications effectuées sur la base de données et de pouvoir les rejouer, ou de faire monter un environnement de version très facilement.
Permet de garder l’état de la base et des différentes migrations qui lui ont été appliqués. Il est très facile de voir, quels scripts sont passés ou non, et quand ceux-ci ont été passés.
Et le tout, avec simplement des scripts SQLLangage permettant de communiquer avec une base de données. horodatés ! On peut donc faire des grosses mises à jour sur la base et utiliser toutes nos compétences en SQL. En plus, on est pas obligé d’apprendre un langage supplémentaire... fantastique non ?
Points forts Flyway | Explications |
---|---|
Plain Old Sql | Les scripts sont écrits en SQL (natif), pas de format propriétaire. |
No limits | Il n’existe pas de limites aux manipulations qu’on peut effectuer sur la bdd. La limite est celle de SQL. On peut donc faire d’importantes mises à jour directement en base pour corriger des données par exemple. |
Zero required dependencies | Pas de besoin spécifique hormis une librairie JDBC... Donc c’est très simple à configurer et peut s’intégrer dans tous les projets. |
Convention Over Configuration | Il suffit à Flyway d’avoir une liste de fichiers à utiliser, pas besoin de configuration particulière. |
Highly reliable | Fonctionne très bien sur cluster. |
Cloud support | Support Amazon RDS, Microsoft SQL Azure, Google Cloud SQL, Heroku... du moment qu’on a une connexion à la bdd |
Auto-migration on startup | La migration de la bdd peut se faire au démarrage de l’application, ce qui permet de mettre les scripts directement dans l’application. On peut ainsi lancer le déploiement qui va lui-même mettre à jour la bdd. |
Fail fast | En cas d’erreur, Flyway bloque le démarrage de l’application. Typiquement, quand dans un merge de branch, un script n’est pas à la bonne date... |
Schema Clean | On peut nettoyer l’intégralité du schéma (vue, table, trigger) sans avoir à tout recréer. |
Concrètement, comment utiliser Flyway | L’installation de Flyway se fait simplement en installant la librairie. Si vous utilisez Gradle ou Maven, ceci ce fait hyper simplement. |
Objectivement, la force de flyway est sa simplicité. Il s’avère particulièrement efficace et on ne se retrouve presque jamais bloqué. Donc, vu de notre fenêtre, pas de gros défaut à déclarer !
Typiquement, les fichiers sont tous horodatés. Ce qui permet à Flyway de les passer dans l’ordre chronologique. A savoir, Flyway utilise aussi un hash des fichiers pour s’assurer que les fichiers ne sont pas modifiés une fois passé en production.
Ici la configuration gradle.properties afin de se connecter à la base de données.
Pour avoir utilisé de nombreux autres outils (on peut citer par exemple Liquidbase, qui objectivement est super pénible à utiliser au quotidien), Flyway remporte la palme d’or de cette catégorie d’outil. Nous le recommandons donc chaudement!
Une agrégation de technologies robustes et packagés de sorte à créer un ESB de premier choix pour un grand nombre d’usages.
La notion de Quality Gate est incontournable lorsqu'il s'agit de garantir la qualité d'un code source. Ces outils permettent de définir des critères précis pour évaluer et maintenir un haut niveau de qualité. Mais qu'est-ce qu'un Quality Gate exactement, et comment le mettre en place efficacement ? Dans cet article, on vous explique tout ce qu'il y a à savoir concernant les Quality Gates et leurs mises en œuvre. Bonne lecture !
Optimiser l’architecture de son SI, ce n’est pas une mince affaire… Vous connaissez peut-être déjà l’analogie qui compare les systèmes d’information à des villes. De la même manière que l’un des enjeux de l’urbanisme réside dans l’harmonie parfois précaire entre les vieux bâtiments et les tours flambant neuves, maintenir un SI est avant tout une question d’équilibre entre l’ancien et le neuf. N’étant pas spécialistes du sujet, on ne saurait pas vous dire à quoi devrait ressembler la ville parfaite. Par contre, on peut vous assurer qu’un bon SI est un SI avec une architecture maîtrisée qui répond aux besoins de l’entreprise, et qui maximise les fonctionnalités tout en réduisant les coûts.