Au même moment où Git est devenu populaire, la tendance à écrire des applications Web à l’aide de bibliothèques ORM (object-relational mapping) est également devenue bien connue. L’idée clé était la suivante: puisque les développeurs peuvent apporter des modifications de code faciles à restaurer à l’aide de Git, pourquoi les développeurs ne peuvent-ils pas faire la même chose en ce qui concerne les modifications de schéma? Après tout, toute nouvelle fonctionnalité raisonnable implique des modifications de code et de schéma. Des frameworks si populaires comme Rails et Django ont ajouté la migration de l’ORM et de la base de données (également connue sous le nom de migration de schéma) dans le cadre de leurs offres. Mais la migration de base de données en tant que concept ne se limite pas aux frameworks Web populaires. Il existe même des bibliothèques logicielles de migration de bases de données autonomes comme Flyway et Liquibase. Pouvez-vous imaginer pouvoir annuler des modifications granulaires au schéma lorsque vous écrivez votre code? Trop souvent, je trouve que les articles sur la migration des bases de données ne discutent pas de ce que signifie en faire activement, en tant que développeur. Je veux corriger cela ici. Dans cet esprit, je vais aujourd’hui vous donner une vue d’ensemble de ce qu’implique la migration de bases de données et comment le faire dans un environnement de développement actif. Je vais diviser cela en trois sections, couvrant ce qui se passe pendant le processus de migration, les outils courants utilisés et les pièges qui peuvent surgir lors de la migration de la base de données. Cela devrait donner à un développeur débutant les outils pour apprendre rapidement les idées clés derrière la migration des données et également apprendre les pièges potentiels à éviter lors de l’utilisation de la migration de base de données dans le cadre de sa boîte à outils de développement.
Que Se Passe-T-Il Pendant La Migration De La Base De Données ?
Maintenant que vous savez comment les migrations de bases de données se sont produites, laissez-moi vous expliquer ce qu’elles impliquent réellement.
Les modifications granulaires Sont Générées sous forme de Fichiers Scriptés individuels
J’ai mentionné comment les migrations de bases de données suivent essentiellement les modifications granulaires de votre schéma de base de données (et parfois également de vos données). Ces modifications granulaires sont généralement reflétées sous forme de fichiers scriptés séparés. De cette façon, vos modifications de schéma granulaires sont reflétées sous forme de code pouvant être capturé avec n’importe quel logiciel de contrôle de version. Ceci est un exemple de fichier de migration dans Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
Non seulement vous pouvez avoir des migrations en tant que fichiers autonomes, mais vous pouvez également avoir le schéma de base de données actuel comme son propre fichier. En règle générale, cela est connu sous le nom de fichier de schéma.
Les scripts de migration de base de données Dépendent de l’outil
Rappellent le script de migration de base de données dans Ruby de notre exemple précédent. Voici un autre fichier de migration de base de données du contrôle de source indépendant pour le logiciel de base de données Liquibase.
<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <changeSet author="bob"> <createTable tableName="department"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false"/> </column> <column name="name" type="varchar(50)"> <constraints nullable="false"/> </column> <column name="active" type="boolean" defaultValueBoolean="true"/> </createTable> </changeSet></databaseChangeLog>
Cette fois, le fichier est au format XML. En réalité, Liquibase peut produire des modifications de migration (ou des ensembles de modifications, comme ils aiment les appeler) dans plusieurs formats tels que XML et JSON. Ainsi, à moins que vous ne souhaitiez écrire manuellement la migration de votre base de données au format SQL, il n’existe pas de normes réelles sur la façon dont les fichiers de migration sont créés. Bien sûr, vous pouvez écrire vos propres scripts de migration de base de données personnalisés dans les fichiers SQL. Mais pourquoi écrire à la main et introduire accidentellement des bogues lorsque vous pouvez utiliser des outils pour générer automatiquement les migrations de base de données?
Comment Effectuez-Vous une Migration de base de données ?
Maintenant, vous savez ce qu’est une migration de base de données. Vous devez également savoir (au moins conceptuellement) comment effectuer une migration de base de données. Malheureusement, il n’existe aucune norme pour les fichiers de migration de base de données, ce qui signifie que nous ne pouvons pas entrer dans trop de détails sur la façon de les créer. En d’autres termes, la façon dont vous effectuez une migration de base de données dépend fortement de l’outil spécifique que vous utilisez pour la tâche. Dans cette section, je vais couvrir les deux façons les plus courantes d’effectuer une migration de base de données.
Option 1: Utilisez une bibliothèque Dépendante du Framework / du langage
Si vous utilisez un langage populaire (Ruby, PHP, Python, etc.) ou framework (Rails, Django, etc.), puis il existe des bibliothèques bien documentées pour la migration des données dans l’univers du framework / langage choisi. Les frameworks Web populaires seront naturellement livrés avec les fonctionnalités de migration de base de données. Selon la configuration, vous pouvez même échanger la migration de base de données native contre d’autres bibliothèques dans la langue choisie. Généralement, dans ce scénario, vous générez les fichiers de migration à l’aide de la ligne de commande. De temps en temps, vous devrez peut-être écrire à la main le code personnalisé pour certaines modifications, telles que la migration des données ou même la façon d’inverser la modification elle-même. En dehors de cela, la bibliothèque choisie dans le framework / langage s’en occupe à peu près pour vous.
Option 2: Utilisez un logiciel indépendant axé sur la migration des bases de données
Dans certains cas, vous voudrez utiliser un logiciel comme Flyway ou Liquibase qui sert simplement de contrôle de source pour votre base de données. En faisant cela, vous évitez d’être enfermé dans un cadre ou un langage particulier. Cela ne signifie pas que vous avez zéro verrouillage. Prenons, par exemple, Flyway, qui fonctionne bien avec diverses bases de données telles qu’Oracle, MySQL et MariaDB. Si vous n’utilisez pas la migration basée sur Java de Flyway (qui vous verrouille en Java et Flyway), vous pouvez finir par utiliser la migration basée sur SQL (qui vous verrouille à votre choix de base de données et de Flyway). La bonne nouvelle est que Flyway et Liquibase sont relativement faciles à utiliser. Ils fournissent également un moyen en ligne de commande de générer les migrations et permettent un codage personnalisé pour capturer les migrations de schéma de base de données.
Choisir la meilleure option pour vous
Voici mon avis sur le choix entre l’une ou l’autre option. J’ai tendance à voir la plupart des développeurs choisir l’option 1. Habituellement, c’est parce que les développeurs ont déjà un langage / framework préféré, donc sur le plan cognitif, ils n’ont pas l’impression d’apprendre (encore) un autre logiciel. Et le verrouillage (dans le cas de l’option 1, ce serait au cadre et au langage) est entièrement volontaire et souhaité. Vous pouvez plaider en faveur de l’option 2 si votre équipe ne s’est pas entièrement engagée dans un langage ou un framework particulier. Quel que soit votre choix, évitez de changer inutilement votre choix au milieu du développement. La migration des bases de données n’est pas un domaine où la modification des outils vous procure d’énormes avantages. La plupart des avantages proviennent simplement de la configuration de la migration des bases de données en premier lieu.
Les dangers de la migration des bases de données et Comment les éviter
Dans la section précédente, j’ai abordé les deux principaux types d’outils de migration des bases de données : les logiciels framework/dépendants du langage et les logiciels autonomes. Les deux types sont faciles à utiliser. Maintenant, je vais recommander trois bonnes pratiques pour effectuer une migration de base de données. Ces conseils abordent le principal danger de la migration des bases de données: vous voulez éviter d’apporter des modifications irréversibles.
Choisissez Un outil de migration de base de données et Respectez-le
Je l’ai mentionné brièvement plus tôt, mais cela vaut la peine de le souligner: je veux mettre en garde contre les modifications inutiles apportées à l’ensemble d’outils simplement parce que c’est cool. Rappelons que les scripts de migration de base de données dépendent de l’outil que vous utilisez pour les générer. Il n’y a pas de normes appropriées pour ces scripts. Si vous le souhaitez vraiment, vous pouvez même écrire les vôtres dans des instructions SQL. Cela introduit son propre ensemble de problèmes ; par exemple, vos scripts SQL peuvent probablement dépendre de la base de données. Les requêtes MySQL peuvent ne pas fonctionner dans PostgreSQL, et vice versa. Donc, soit vous êtes verrouillé dans votre outil de migration de base de données, soit vous êtes verrouillé dans la base de données de votre choix — ou dans certains cas, même les deux. Il n’y a aucun avantage évident à changer souvent de jeu d’outils, donc ma suggestion est de choisir un outil de migration de base de données et de s’y tenir. Il y a de meilleures choses à faire avec votre temps que de faire tourner inutilement vos roues.
Supprimer des Lignes ou des colonnes Uniquement Lorsque Vous êtes Absolument Certain de le Faire
En ce qui concerne les migrations, vous pouvez les inverser lorsque vous en avez besoin. Les outils de migration de base de données typiques peuvent gérer des modifications réversibles simples. Et même lorsqu’ils ne le peuvent pas, vous pouvez facilement ajouter votre propre code personnalisé pour vous aider à inverser. Par exemple, dans Rails, vous ajoutez simplement le code sous réversible.
class ChangeProductsPrice < ActiveRecord::Migration def change reversible do |dir| change_table :products do |t| dir.up { t.change :price, :string } dir.down { t.change :price, :integer } end end endend
Les modifications les plus difficiles à inverser ont tendance à impliquer la suppression de choses: en particulier, la suppression de colonnes ou de lignes de données. Si votre base de données contient beaucoup de données, vous devrez peut-être écrire une quantité importante de code personnalisé pour essayer d’inverser vos modifications. Donc, si vous envisagez de supprimer des données de votre base de données, soyez très prudent. Ces types de changements sont difficiles à annuler. D’autres modifications difficiles à inverser incluent le renommage des colonnes et la modification du type de données d’une colonne qui contient déjà des données. Une règle empirique que j’aime suivre est la suivante: vous ne devriez presque jamais supprimer de colonnes avant la prochaine majeure (vous connaissez semver, n’est-ce pas?) publier. Cette règle s’applique même si j’ai des colonnes que je veux arrêter d’utiliser. Au lieu de supprimer des colonnes, j’annoncerai dans les versions mineures quelles colonnes seront obsolètes à l’avenir. Quand viendra le temps d’une version majeure, je supprimerai ensuite entièrement ces colonnes. De cette façon, je réduit les chances d’effectuer un changement accidentel et indésirable qui sera un processus horrible à inverser à la main.
Implémenter des drapeaux de fonctionnalités
Une autre excellente stratégie pour la migration de bases de données consiste à implémenter des drapeaux de fonctionnalités, en particulier lorsque vous avez une grande équipe et que plusieurs personnes essaient d’implémenter différentes fonctionnalités pour la même base de code. Selon Martin Fowler, les drapeaux de fonctionnalités sont « une technique puissante, permettant aux équipes de modifier le comportement du système sans changer de code. » En fait, plus votre équipe est grande et plus votre base de code est complexe, plus les drapeaux de fonctionnalités brillent. Les indicateurs de fonctionnalité aident à atténuer les risques liés aux migrations de bases de données. Essayer de démêler les changements lorsque vous devez annuler certaines fonctionnalités peut être un véritable cauchemar. Les indicateurs de fonctionnalité fonctionnent tout aussi bien que vous souhaitiez apporter des modifications de schéma de base de données petites ou grandes. Lorsque vous utilisez des indicateurs de fonctionnalité, je vous recommande de viser des changements plus fréquents et granulaires dans l’ensemble. Et vous pouvez vraiment voir comment les indicateurs de fonctionnalité aident votre processus de développement lorsque vous effectuez un changement de schéma massif. Veuillez toujours viser à diviser ce changement de schéma massif en tranches plus petites et minces. Vous n’avez pas besoin d’impressionner qui que ce soit avec combien vous pouvez presser en un seul changement. Mieux vaut ajouter des garanties à vos pratiques de développement en mettant en œuvre les trois recommandations dont j’ai parlé dans cette section.
Conclusion
Les développeurs ont besoin de tous les outils qu’ils peuvent obtenir pour leur faciliter la vie. La migration des bases de données est l’un de ces outils indispensables à la boîte à outils du développeur. À l’avenir, je prévois que l’utilisation de migrations de bases de données évoluera d’une meilleure pratique de développement à une pratique standard de développement. Les gens vous regarderont drôle pour ne pas utiliser du tout la migration de base de données. Néanmoins, il est important de garder à l’esprit que les migrations de bases de données peuvent se retourner contre vous, en particulier pour les modifications de schéma difficiles à inverser. Soyez absolument certain de ces changements avant de les mettre en ligne. Si vous n’utilisez pas déjà la migration de base de données dans votre processus, qu’attendez-vous ? Il est facile à démarrer et vous pouvez même l’ajouter au milieu de votre cycle de développement. Vous serez reconnaissants de l’avoir fait. Parce que lorsque le jour viendra où vous devrez annuler vos modifications et que celles-ci impliquent la base de données, vous souhaiterez avoir quelque chose pour vous aider à le faire en quelques secondes. La migration de base de données est quelque chose que vous souhaiterez avoir.