Les fichiers de base de données (scripts, etc.) doivent-ils être sur le contrôle de source? Si tel est le cas, quelle est la meilleure méthode pour le conserver et le mettre à jour?

Est-il même nécessaire que les fichiers de base de données se trouvent sur le contrôle de source puisque nous pouvons le placer sur un serveur de développement sur lequel tout le monde peut l'utiliser et y apporter des modifications si nécessaire. Mais alors nous ne pouvons pas le récupérer si quelqu'un le gâche.

Quelle approche est la mieux utilisée pour les bases de données sur le contrôle de source?

Oui. Vous devriez pouvoir reconstruire n'importe quelle partie de votre système à partir du contrôle de source, y compris la base de données (et je dirais aussi certaines données statiques).

En supposant que vous ne souhaitiez pas disposer d'un outil pour le faire, je suggérerais que vous souhaitiez inclure les éléments suivants:

• Scripts de création pour les structures de table de base, y compris les schémas, les utilisateurs, les tables, les clés, les valeurs par défaut, etc.
• Mettre à niveau les scripts (en modifiant la structure de la table ou en migrant les données d'un schéma précédent vers le nouveau schéma)
• Scripts de création pour les procédures stockées, les index, les vues et les déclencheurs (vous n'avez pas à vous soucier de la mise à niveau pour ceux-ci, vous écrasez simplement ce qui était là avec le script de création correct)
• Scripts de création de données pour faire fonctionner le système (un seul utilisateur, des données de liste de sélection statiques, ce genre de chose)

Tous les scripts doivent inclure les instructions de dépôt appropriées et être écrits de manière à pouvoir être exécutés comme n'importe quel utilisateur (incluant donc les préfixes de schéma / propriétaire associés, le cas échéant).

Le processus de mise à jour / marquage / branchement doit être identique au reste du code source. Il est inutile de le faire si vous ne pouvez pas associer une version de base de données à une version d'application.

Incidemment, lorsque vous dites que les gens peuvent simplement mettre à jour le serveur de test, j'espère que vous parlez du serveur de développement. Si les développeurs mettent à jour le serveur de test à la volée, vous vous retrouvez face à un monde de souffrances lorsqu'il s'agit de déterminer ce dont vous avez besoin.

Oui.

Quelle est la meilleure méthode pour le conserver et le mettre à jour?

Hum Écrivez un script générateur de schéma. Enregistrez-le après avoir apporté des modifications. Vérifiez-le avant de l'exécuter.

Il est difficile de déterminer ce que vous demandez.

Écrire des scripts de migration de schéma formels. Vérifiez-les après les tests. Vérifiez-les avant de les exécuter.

Qu'y a-t-il de plus?

Ce qui se passe, c'est que les modifications de schéma se transforment en problèmes épineux, car le schéma évolue de manière organique à travers une série de modifications non documentées.

Cette évolution organique rend la migration de schéma plus difficile car il n’existe aucune source "faisant autorité" pour ce qui est censé être là. Il existe deux versions de production légèrement différentes, une version intermédiaire, une version d'assurance qualité et huit versions de développement. Tous légèrement différents.

S'il existe une seule source faisant autorité, la migration de schéma correspond simplement au delta entre la dernière version et cette version.

Oui

Les scripts de base de données (ddl, dml) sont du code. Tout le code doit être dans un système de contrôle de version.

Migrations

• Utiliser les migrations de bases de données

Vous permet d'utiliser les mêmes fichiers de base de données en développement, en exécution et en versions.

• Libérer dans la base de données avec un numéro de version

Stockez le numéro de version quelque part pour l'audit, beaucoup le stockent même dans la base de données. Chaque version sera composée de migrations qui amèneront la base de données à la version correcte.

Il existe des outils tels que liquibase qui sont destinés à fournir un contrôle de source pour les bases de données. Il est difficile de gérer les scripts de modification / mise à jour dans votre outil de contrôle de code source comme le font de nombreuses entreprises et vous ne pouvez pas toujours redéployer la base de données à partir de zéro.

Nous avons également essayé d'automatiser cela avec des outils de comparaison de base de données (comparer la base de données maître à la base de données client) et cela nous a aidé, mais vous ne pouvez pas faire confiance à ces outils à 100%, vous avez certainement besoin d'un processus de révision également.

Oui

Et de plus, vous voudrez des branches .

J'utilise Git pour les branches:

• pour le développement par fonctionnalité (comme pour le développement régulier du reste de l'application)

• et un pour le serveur de production également parce que les clients utilisant l'application créent également du contenu.

De cette façon, vous bénéficiez des avantages du contrôle de source et de la création de branches pour les codes sources et la base de données (ainsi que tout autre fichier que vous avez).

Je n’ai pas encore trouvé de système tout-en-un [pour PostgreSQL], j’ai donc dû écrire des fonctions / scripts pour réindexer correctement lors de la fusion de branches (par exemple, aucun index de la branche de production ne devrait être modifié car les clients les utilisent alors que les index + les clés étrangères de la branche de développement qui recoupent le contenu de la production devraient être réindexés: cela ne fonctionnerait pas pour toutes les applications, mais cela couvre tous les cas de notre application, donc c'est assez bon).

Mais l’idée générale est que le contenu de la base de données est une partie essentielle de l’application, et que toutes les ressources doivent être en contrôle de source , mais oui, vous devez également utiliser le contrôle de source pour la base de données.

Pour Java, notre équipe utilise Flyway , que nous trouvons vraiment facile à utiliser et puissant.

Si vous travaillez dans Ruby, Rails propose des migrations qui constituent également un moyen puissant de résoudre ce problème.

Liquibase a déjà été mentionné - c'est une bonne solution, mais je l'ai trouvée plus lourde que des alternatives comme Flyway.

En outre, le logiciel RedGate offre un produit appelé contrôle de source SQL conçu pour SQL Server. Je ne l'ai pas utilisé moi-même, mais l'un de mes collègues me dit que c'est génial.

Voici le problème que j'ai souvent vu lorsqu'il n'y avait pas de contrôle de version ou de gestion des modifications sur les bases de développement. Le programmeur A modifie une table, une vue ou une proc. Le programmeur B apporte un changement à la même chose et écrase ce que le programmeur A a fait. Ou bien, DBA restaure une base de production en développement et écrase les modifications. J'ai vu ce genre de choses causer beaucoup de chagrin tant de fois ce n'est pas drôle. Et ce n'est que sur les systèmes de développement. La mise en scène / le test peut être très compliqué et même les serveurs de production sont pris au piège.

Le contrôle de la version de la base de données ne doit pas nécessairement être identique au contrôle de la version du code habituel pour être efficace. Cependant, un certain type de contrôle des modifications et des sauvegardes de l'historique éviteront de nombreux problèmes.

Considérez-le comme "Contrôle de version" plutôt que "Contrôle de source". Cela implique que vous pouvez voir l'historique complet de ce script particulier. Que vous puissiez ou non reconstruire la base de données à sa forme actuelle dépendra davantage de vos pratiques en ce qui concerne ces scripts et les infrastructures utilisées pour les créer.

Pour nos projets PHP / MySQL, nous utilisons un (une fois) petit outil appelé Ladder . Il est conçu pour faciliter la croissance organique d'une base de données au fil du temps. Toutes les migrations d'un projet sont stockées dans le contrôle revision / source / version et font l'objet d'un suivi avec le code.

Il prend en charge l'ajout / la modification / la suppression de colonnes, l'exécution de requêtes, l'ajout / la suppression d'index, de contraintes, etc., etc. Il permet de suivre l'état de la base de données et d'appliquer les migrations manquantes. Il vous permet également de "remonter dans le temps" en spécifiant la migration à laquelle vous devez être. ( php ladder.php migrate 15)

Oh, et le dernier ajout est la base de données diffing. Exécutez la diff-savecommande, ajoutez et supprimez des colonnes de la base de données, puis exécutez sa diffcommande. Vous verrez le code de migration généré automatiquement en fonction de l'état de la base de données.

DataGrove résout certains des problèmes mentionnés ici (par jfrankcarr , par exemple).

Il suit toutes les modifications apportées à une base de données et vous permet d'enregistrer une version de l'état complet de la base de données dans un référentiel. Il vous permet ensuite de générer plusieurs copies virtuelles de la même base de données afin que chaque développeur ou chaque administrateur de base de données puisse disposer de sa propre copie (chaque copie virtuelle peut être générée à partir d'une version différente). Cela garantira que personne ne remplace le code / les modifications de quelqu'un d'autre. Chacune des copies virtuelles est également suivie dans les mêmes référentiels afin que tous les états de base de données puissent être facilement partagés et recréés.

J'aimerai aussi apporter un outil de surveillance qui peut également être utilisé comme outil de gestion de versions de données. L'outil dont je parle est MONyog. En fait, il s'agit d'un outil de surveillance MySQL, mais avec un petit bidouillage, nous pouvons facilement l'utiliser comme versioning de données.

Mais avant d’aller plus loin, je citerai qu’il ne sera pas conseillé de mettre en place toute la base de données pour la gestion des versions. C’est un vrai tueur de suivre les changements pour un ensemble de données particulier.

MONyog possède une fonctionnalité appelée CSO (Custom SQL Objects), qui permet de surveiller les modifications apportées à un ensemble de données particulier. L'ajout d'un CSO est décrit ici . Maintenant, dans la section historique de MONyog, vous pouvez obtenir les modifications sur une période donnée. Mieux, il donne un rapport visuel en page HTML. Le rapport ressemblera à quelque chose comme ça