Version de la base de données avec DBV

Les plats clés

• DBV est un système de contrôle de version de base de données basé sur PHP pour les bases de données MySQL. Il n'est pas autonome et nécessite un système de contrôle de version tel que Git, Mercurial ou SVN pour synchroniser les modifications avec votre équipe.
• DBV permet aux développeurs de suivre les modifications apportées à une base de données, de partager ces modifications avec les membres de l'équipe et de s'assurer que tout le monde travaille avec la dernière copie de la base de données. Il peut suivre les modifications comme les nouvelles tables, les tables renommées ou supprimées, les champs nouveaux ou mis à jour, les lignes de table neuves ou mises à jour, et plus encore.
• Le flux de travail DBV consiste à créer une copie locale de la base de données, à apporter des modifications, à exporter ces modifications au disque, à les engager dans le contrôle de la source et à les pousser vers un référentiel central. Les membres de l'équipe peuvent ensuite tirer ces modifications à leur copie locale.
• DBV prend également en charge les révisions, permettant aux développeurs de modifier la structure de plus d'une table. Cependant, il est bon à apporter des modifications à une seule table et à en faire une révision, à moins que les modifications ne soient liées les unes aux autres.

Il est bonne pratique de toujours utiliser un système de contrôle de version dans l'un de vos projets. Que ce soit un projet latéral dans lequel vous êtes le seul développeur ou un projet d'équipe où cinq personnes ou plus y travaillent ensemble. Mais l'idée de mettre votre base de données dans le contrôle de version n'est pas vraiment répandue. Souvent, nous tenons la base de données pour acquise.

Mais comme les fichiers source de notre projet, la base de données change constamment en constante évolution. C’est pourquoi nous avons également besoin d’un moyen de suivre les changements que nous avons apportés et de le partager facilement avec d’autres membres de notre équipe.

Dans cet article, nous examinerons DBV, un système de contrôle de version de base de données écrits en PHP pour les bases de données MySQL, vous devez donc installer PHP et MySQL avant de pouvoir l'utiliser, ainsi qu'un serveur Web comme Apache ou Nginx.

Une note importante sur ce logiciel est qu'il ne s'agit pas d'un système de contrôle de version de la base de données autonome, car il a besoin d'un système de contrôle de version tel que GIT, Mercurial ou SVN pour synchroniser les modifications avec votre équipe.

Installation de dbv

Pour commencer à travailler avec DBV, vous devez d'abord télécharger le programme d'installation à partir de leur site Web, l'extraire dans votre répertoire de projet, puis renommer le dossier résultant à DBV. Cela vous donnera le chemin suivant:

<span>my_project/dbv</span>

Une approche alternative ne fait que le clonage de GitHub.

Configuration DBV

Vous pouvez commencer à configurer les options de DBV en créant une copie du fichier config.php.s échantillon et en le renommant sur config.php.

Les choses les plus importantes à mettre à jour ici sont les deux premières sections. Remplacez simplement les valeurs de My_Username, My_Password, My_Database pour les valeurs de votre configuration de base de données actuelle:

<span><span><?php </span></span><span><span>/**
</span></span><span><span> * Your database authentication information goes here
</span></span><span><span> * <span>@see http://dbv.vizuina.com/documentation/
</span></span></span><span><span> */
</span></span><span><span>define('DB_HOST', 'localhost');
</span></span><span><span>define('DB_PORT', 3306);
</span></span><span><span>define('DB_USERNAME', 'my_username');
</span></span><span><span>define('DB_PASSWORD', 'my_password');
</span></span><span><span>define('DB_NAME', 'my_database');
</span></span><span>
</span><span><span>/**
</span></span><span><span> * Authentication data for access to DBV itself
</span></span><span><span> * If you leave any of the two constants below blank, authentication will be disabled
</span></span><span><span> * <span>@see http://dbv.vizuina.com/documentation/#optional-settings
</span></span></span><span><span> */
</span></span><span><span>define('DBV_USERNAME', 'my_username');
</span></span><span><span>define('DBV_PASSWORD', 'my_password');
</span></span><span><span>?></span></span></span>

La première section du fichier de configuration ci-dessus concerne les détails de la base de données MySQL dans votre machine.

La deuxième section est les détails de connexion pour DBV lui-même.

Ouvrez ensuite le fichier .gitignore. Par défaut, il contient ce qui suit:

<span>my_project/dbv</span>

Ce sont les fichiers qui seront ignorés par GIT. Mais si vous savez que vous avez les mêmes informations sur la base de données (utilisateur, mot de passe, nom de base de données) que vos coéquipiers, vous pouvez supprimer config.php du fichier .gitignore. Sinon, ils devront créer leur propre fichier de configuration et l'exclure du contrôle source.

Ensuite, vous devez également ajouter le fichier de données / méta / révision à .gitignore car c'est là que DBV met des informations sur votre copie locale de la base de données. Cela peut être différent pour vos coéquipiers, il doit donc être exclu du contrôle des sources.

Une fois que vous avez terminé la configuration, vous pouvez maintenant ajouter DBV dans le contrôle de la version:

<span><span><?php </span></span><span><span>/**
</span></span><span><span> * Your database authentication information goes here
</span></span><span><span> * <span>@see http://dbv.vizuina.com/documentation/
</span></span></span><span><span> */
</span></span><span><span>define('DB_HOST', 'localhost');
</span></span><span><span>define('DB_PORT', 3306);
</span></span><span><span>define('DB_USERNAME', 'my_username');
</span></span><span><span>define('DB_PASSWORD', 'my_password');
</span></span><span><span>define('DB_NAME', 'my_database');
</span></span><span>
</span><span><span>/**
</span></span><span><span> * Authentication data for access to DBV itself
</span></span><span><span> * If you leave any of the two constants below blank, authentication will be disabled
</span></span><span><span> * <span>@see http://dbv.vizuina.com/documentation/#optional-settings
</span></span></span><span><span> */
</span></span><span><span>define('DBV_USERNAME', 'my_username');
</span></span><span><span>define('DBV_PASSWORD', 'my_password');
</span></span><span><span>?></span></span></span>

puis le pousser vers votre référentiel central pour que les autres membres de votre équipe puissent tirer:

<span>config.php
</span><span>.buildpath
</span><span>.project
</span><span>.settings</span>

De quels changements pour garder une trace?

avant de passer à l'utilisation de DBV. Je voudrais toucher un peu les changements à suivre. Dans le monde de la base de données, presque tous les changements peuvent être mis dans le contrôle des sources. Cela comprend ce qui suit:

• Nouvelles tables
• Renommé Tables
• Tables supprimées
• Nouveaux champs
• Field mis à jour
• champ supprimé
• Nouvelle ligne de table (données de table par défaut)
• ligne de table mise à jour
• ligne de table supprimée
• vues
• Procédures stockées
• déclenche
• Fonctions (fonctions définies par l'utilisateur)

flux de travail DBV

Vous pouvez tirer DBV à partir de votre navigateur en accédant à l'URL suivante:

<span>git add dbv
</span><span>git commit -m "add dbv into project"</span>

ou si vous avez défini un hôte virtuel, en accédant à son URL.

Cela vous donnera une interface similaire à ce qui suit:

À partir de la capture d'écran ci-dessus, vous verrez les tables qui sont actuellement dans la base de données que vous avez fournies dans la config.php plus tôt. Il existe également un champ in DB qui affiche si une table spécifique est actuellement dans la base de données et le disque ON qui affiche si le tableau actuel est enregistré dans votre système de fichiers. Avec ces informations, vous savez à peu près si vous avez actuellement la dernière copie de la base de données.

Une chose importante à retenir lorsque vous travaillez avec DBV est que toutes les modifications que vous apportez à votre copie locale de votre base de données devraient avoir une copie locale que vous pouvez engager dans votre contrôle source.

Cela signifie que si vous créez une nouvelle table dans la base de données, vous devez l'exporter en disque. Toutes les tables qui sont exportées vers le disque sont enregistrées dans le répertoire des données / schéma de votre installation DBV. Vous pouvez voir dans la capture d'écran ci-dessous que nous n'avons actuellement pas la table TBL_LEADINFO dans notre système de fichiers:

Après avoir exporté la table nouvellement créée vers le disque, vous devez le valider dans le contrôle de la version:

<span>my_project/dbv</span>

Ensuite, vous pouvez simplement le pousser vers votre référentiel central:

<span><span><?php </span></span><span><span>/**
</span></span><span><span> * Your database authentication information goes here
</span></span><span><span> * <span>@see http://dbv.vizuina.com/documentation/
</span></span></span><span><span> */
</span></span><span><span>define('DB_HOST', 'localhost');
</span></span><span><span>define('DB_PORT', 3306);
</span></span><span><span>define('DB_USERNAME', 'my_username');
</span></span><span><span>define('DB_PASSWORD', 'my_password');
</span></span><span><span>define('DB_NAME', 'my_database');
</span></span><span>
</span><span><span>/**
</span></span><span><span> * Authentication data for access to DBV itself
</span></span><span><span> * If you leave any of the two constants below blank, authentication will be disabled
</span></span><span><span> * <span>@see http://dbv.vizuina.com/documentation/#optional-settings
</span></span></span><span><span> */
</span></span><span><span>define('DBV_USERNAME', 'my_username');
</span></span><span><span>define('DBV_PASSWORD', 'my_password');
</span></span><span><span>?></span></span></span>

À ce stade, vous pouvez simplement dire à vos coéquipiers que vous avez créé un nouveau tableau dans la base de données et que vous l'avez déjà poussé au dépôt central. Maintenant, ils peuvent simplement le tirer sur leur copie locale.

<span>config.php
</span><span>.buildpath
</span><span>.project
</span><span>.settings</span>

Ensuite, dites à votre coéquipier de visiter la page DBV (http: // localhost / your_project / dbv).
Votre coéquipier aura probablement un écran similaire à ce qui suit:

À ce stade, il peut simplement cocher la case à côté de la table TBL_TASKS et cliquer sur le bouton "Puster to Database". Cela créera la table TBL_TASKS dans la base de données.

Et c'est le flux de travail pour travailler avec DBV. Assez facile, n'est-ce pas? Mais que se passe-t-il si vous devez apporter des modifications au schéma de base de données actuel? Peut-être que vous avez manqué un champ ou oublié de l'ajouter sur une table spécifique avant de la distribuer à votre équipe. C'est là que les révisions entrent en jeu.

révisions

Si vous êtes comme moi et que vous avez essayé de mettre à jour le schéma (ajouté un nouveau champ, supprimez un champ, mis à jour le type de données, etc.) pour un tableau spécifique que vous avez peut-être remarqué que DBV n'en est pas au courant défaut. Pour les modifications, vous devez créer un fichier de révision. Vous pouvez le faire en créant un nouveau dossier dans le répertoire des données / révisions dans votre installation DBV. La convention pour nommer le dossier utilise un nombre. Donc, la première fois que vous effectuez une révision, le nom du dossier serait 1, puis la prochaine fois, ce serait 2 et ainsi de suite. Notez que les révisions sont des modifications qui peuvent être appliquées à l'ensemble de la base de données. Cela signifie que vous avez la liberté de modifier la structure de plus d'une table, mais sa bonne pratique pour ne modifier qu'une seule table et en faire une révision. C'est pour vous et votre équipe de gérer facilement les changements et de le comprendre plus tard. La seule exception à cette pratique est lorsque les changements sont liés les uns aux autres. Dans ce cas, il serait logique de rassembler ces changements dans une révision.

Essayons de créer un nouveau champ à l'intérieur de la table TBL_USERS et de le nommer Email:

<span>git add dbv
</span><span>git commit -m "add dbv into project"</span>

Ensuite, créez un nouveau fichier dans le répertoire Data / Revisions / 1 dans votre installation DBV et mettez la requête que vous venez d'exécuter comme contenu. Nommez le fichier tbl_users.sql. La convention ici utilise le nom de la table modifiée comme nom du fichier de révision.
Si vous apportez des modifications à plus d'une table, créez un fichier séparé pour chaque table.

Après cela, vous pouvez engager le nouveau fichier dans votre contrôle source:

<span>git push</span>

puis le pousser vers votre référentiel central:

<span>http://localhost/your_project/dbv</span>

Encore une fois, vous pouvez informer vos coéquipiers du changement particulier. La communication est essentielle lors des modifications à la base de données. Vous voulez vous assurer que tout le monde dans votre équipe est sur la même longueur d'onde que vous.

Maintenant, s'ils accèdent à DBV depuis le navigateur, ils peuvent maintenant voir la révision. Tout ce qu'ils ont à faire maintenant est de cocher la case à côté de la révision, puis de cliquer sur le bouton «Exécuter les révisions sélectionnées». Cela consacrera vos modifications à leur copie de base de données locale:

Conclusion

DBV est un bon moyen de gérer facilement les besoins de contrôle de la version de la base de données. Il vous permet à vous et à votre équipe de suivre facilement les modifications apportées dans votre base de données. Il permet également un partage facile de vos modifications avec le reste de votre équipe grâce à l'utilisation de GIT. Cela garantit que tout le monde a toujours la dernière copie de la base de données.

Dans cet article, nous avons examiné l'utilisation de DBV avec GIT, mais vous pouvez à peu près utiliser n'importe quel système de contrôle de version de votre choix. Retour? Veuillez le laisser dans les commentaires ci-dessous!

Des questions fréquemment posées sur le versioning de la base de données

Quels sont les principaux avantages du versioning de la base de données?

Le versioning de base de données offre plusieurs avantages. Premièrement, il fournit un enregistrement historique de toutes les modifications apportées au schéma de base de données, qui peuvent être utiles à des fins de débogage et d'audit. Deuxièmement, il permet un recul facile des modifications en cas d'erreurs ou de problèmes. Troisièmement, il facilite la collaboration entre les membres de l'équipe en s'assurant que tout le monde travaille avec la même version de la base de données. Enfin, cela aide à maintenir la cohérence et l'intégrité de la base de données, en particulier dans un environnement de développement distribué.

Comment fonctionne le versioning de la base de données dans la pratique?

Dans la pratique, le versioning de la base de données implique le maintien d'une histoire de version du schéma de base de données. Cela se fait généralement à l'aide d'un système de contrôle de version comme Git. Chaque modification du schéma de la base de données est engagée comme une nouvelle version dans le système de contrôle de version. Ces versions sont ensuite utilisées pour mettre à jour le schéma de base de données dans différents environnements (développement, test, production, etc.) selon les besoins.

Quels outils peuvent être utilisés pour le versioning de base de données?

Il y en a plusieurs Outils disponibles pour le versioning de base de données. Certains des plus populaires incluent Liquibase, Flyway et DBMaestro. Ces outils fournissent des fonctionnalités telles que les mises à jour de schéma automatisées, les capacités de recul et la prise en charge de plusieurs types de bases de données. Le choix de l'outil dépend des exigences et des préférences spécifiques de l'équipe de développement.

Quels sont les défis dans la mise en œuvre du versioning de la base de données?

La mise en œuvre du versioning de la base de données peut être difficile pour plusieurs raisons. Premièrement, cela nécessite un changement dans le processus de développement, qui peut être difficile à gérer. Deuxièmement, cela nécessite une manipulation minutieuse des migrations de la base de données pour éviter la perte de données ou la corruption. Enfin, cela nécessite une bonne compréhension du schéma de base de données et des modifications qui y sont apportées.

Comment le versioning de base de données peut-il aider dans le développement agile?

Dans le développement agile, les modifications sont apportées fréquemment et rapidement. Le versioning de la base de données peut aider à gérer efficacement ces changements en fournissant un enregistrement historique de tous les changements, en facilitant le retrait facile des changements et en garantissant la cohérence dans différents environnements. Cela peut améliorer considérablement l'agilité et l'efficacité du processus de développement.

Comment le versioning de la base de données est-il lié à DevOps?

Le versioning de la base de données est un composant clé de DevOps, car il permet une intégration continue et un déploiement continu (CI / CD) des modifications de la base de données. En maintenant un historique de version du schéma de base de données, il permet un déploiement automatisé de modifications dans différents environnements, améliorant ainsi la vitesse et l'efficacité du processus DevOps.

Les versioning de la base de données peuvent-ils être utilisés avec des bases de données cloud?

Oui, le versioning de base de données peut être utilisé avec des bases de données cloud. La plupart des outils de versioning de base de données prennent en charge une large gamme de types de bases de données, y compris les bases de données cloud. Cependant, les fonctionnalités et capacités spécifiques peuvent varier en fonction de l'outil et du type de base de données cloud.

Quel est le rôle du versioning de base de données dans la gouvernance des données?

Le versioning de la base de données joue un rôle crucial dans Gouvernance des données en assurant l'intégrité et la cohérence du schéma de la base de données. Il fournit un enregistrement historique de tous les changements, qui peuvent être utiles à des fins d'audit et de conformité. Il facilite également la collaboration et la communication entre les membres de l'équipe, ce qui est essentiel pour une gouvernance efficace des données.

Comment le versement de la base de données peut-il améliorer les performances de la base de données?

Alors que le versioning de la base de données lui-même n'améliore pas directement les performances de la base de données, elle, il Peut aider à identifier les problèmes de performance en fournissant un enregistrement historique des changements de schéma. Cela peut être utile pour le débogage et le réglage des performances. De plus, en garantissant la cohérence et l'intégrité du schéma de base de données, il peut indirectement contribuer à de meilleures performances de base de données.

Quelles sont les meilleures pratiques pour le versioning de la base de données?

Inclure: Utilisation d'un système de contrôle de version pour maintenir un historique de version du schéma de base de données; commettre chaque changement comme une nouvelle version; tester chaque version à fond avant le déploiement; Utilisation d'outils automatisés pour les mises à jour du schéma et les reculs; et maintenir une bonne communication et une bonne collaboration entre les membres de l'équipe.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!