Bases de données et DVCS

Question

J'ai récemment posé une question sur la façon dont un DVCS est adapté à l'environnement de l'entreprise, et cela a déclenché une autre question pour moi. Un des côtés positifs d'un DVCS semble être que vous pouvez facilement vous branchez et essayer de nouvelles choses. Mon problème commence quand je commence à penser aux changements de base de données. J'ai toujours trouvé difficile d'obtenir une DB dans un VCS et il semble que ce sera encore plus difficile avec un DVCS.

Alors, quelle est la meilleure façon de travailler avec des bases de données et un DVCS?

EDIT: J'ai commencé à chercher dans Migrator.NET. Qu'est-ce que les gens pensent des projets comme celui-ci pour passer facilement d'une version à une autre avec des branches expérimentales dans votre DVCS?

Answer 1

Je pense que la meilleure façon de traiter ce problème est de travailler avec DB Schemas, pas les bases de données elles-mêmes. Dans ce cas, chaque développeur aurait sa propre base de données à développer.

Voici quelques-unes des options disponibles:

• cadre dans les migrations Ruby on Rails.
• Sud pour Django, en plus du schéma défini dans les classes du modèle elles-mêmes. .NET: Vous définissez le schéma et l'outil peut faire un schéma et des données diff pour générer des scripts pour passer d'une version à l'autre de la base de données.

Ceci peut vous donner une idée de la gestion d'une base de données dans le contrôle de version. Un autre avantage qui vient quand vous traitez les schémas est que vous pouvez implémenter plus facilement TDD et l'intégration continue (CI). Votre environnement TDD/CI serait capable de créer une nouvelle version de la base de données, puis d'exécuter des tests sur l'environnement nouvellement généré.

Answer 2

Exécutez tous les scripts que vous utilisez pour gérer votre base de données. Si vous devez apporter des modifications «en cours de développement» à une base de données, faites-les sur votre base de données personnelle jusqu'à ce que vous «publiiez» vos modifications.

Answer 3

Le contrôle de version de base de données est toujours la chose la plus difficile dans un environnement multi-développeur.

Typiquement chaque utilisateur aura son propre DB qui est une chimère de certains mais pas de tous les changements de DB. Lorsqu'ils apportent des modifications, ils doivent valider leurs scripts de modification. Cela devient vraiment gênant. Les problèmes de base semblent provenir de modifications de base de données affectant de nombreux aspects du système et de multiples changements de tables dépendant les uns des autres - et comment migrer vers le nouveau schéma à partir de l'ancien schéma. La migration de données vers un nouveau schéma est généralement non triviale. Souvent, vous voulez par défaut une colonne lorsque les données sont copiées dans le nouveau schéma, mais pas par défaut une colonne en général pour INSERT, par exemple. Ils sont généralement déjà difficiles dans les problèmes de déploiement de production et doivent gérer la base de données au cours du développement lorsque la conception de la base de données peut être modifiée de la même manière qu'un déploiement majeur représente beaucoup plus de travail que le développement. Parce que les développeurs sont plus susceptibles de se chevaucher les uns les autres avec des changements de base de données, nous avons toujours eu une base de données chokepoint - les développeurs tous développés contre la base de données de développement SAME et ont fait leurs changements "en direct". Ensuite, la base de données dev a été contrôlée de manière indépendante. Ce n'est pas vraiment facile quand les gens sont hors site ou peu importe. Une autre alternative consiste à avoir des développeurs de bases de données désignés qui coordonnent les modifications dont plusieurs développeurs ont besoin pour la même table - cela n'a pas besoin d'être leur travail entier, mais vous donne une meilleure cohérence de conception de base de données. Vous pouvez également coordonner les révisions de la base de données pour que les utilisateurs soient plus conscients des révolutions de base de données effectuées par les autres utilisateurs et attendent leurs modifications pour attendre qu'un rev de base de données soit disponible auprès d'un autre développeur.

Answer 4

La meilleure façon de ne pas mettre la base de données dans VCS sous forme binaire. Période. Si vous avez une représentation textuelle de votre base de données et que vous disposez d'un outil de fusion spécial pour résoudre les conflits lorsque votre base de données sera modifiée dans différentes branches, vous pouvez commencer à penser aux versions de base de données. Sinon, ce sera une douleur constante dans le cul.