Comment gérez-vous les révisions de base de données sur un projet de taille moyenne avec des branches?

Question

Au travail, nous avons 4 personnes travaillant ensemble sur plusieurs projets différents. Pour chaque projet, nous avons chacun une copie locale sur laquelle nous travaillons, puis il y a un développement, une mise en scène et un déploiement en direct, ainsi que toutes les branches que nous avons (nous utilisons subversion). Notre base de données est MySQL.

Ma question est donc la suivante: quel est le bon moyen de gérer les révisions apportées à la base de données pour chaque déploiement (et pour les développeurs, leurs copies locales). À l'heure actuelle, chaque modification entre dans un fichier texte dont le nom est horodaté et placé dans un dossier sous le projet. Pour être honnête, cela ne fonctionne pas très bien. Il me faut une solution qui permette de garder une trace de ce qui a été appliqué où.

Answer 1

Si votre base de données correspond bien à un ensemble d'objets d'accès aux données, envisagez d'utiliser les "migrations". L'idée est de stocker votre modèle de données sous forme de code d'application avec des étapes permettant d'avancer et de revenir en arrière dans chaque version de base de données.

Je pense que Rails l'a fait d'abord .

Java a au moins un projet .

Et voici une bibliothèque de migration .NET .

Pour changer de version, vous exécutez un simple script qui passe en revue toutes les versions montantes et descendantes pour vous amener à la version de votre choix. La beauté de ce logiciel est que vous vérifiez vos migrations dans le même référentiel source que le code de votre application, le tout au même endroit.

Peut-être que d'autres peuvent suggérer d'autres bibliothèques de migration.

A bientôt.

Modifier: voir aussi https://stackoverflow.com/questions/313/net-migrations-engine Synthèse de l'outil de migration de base de données .NET (à partir du message ci-dessus).

Answer 2

http://odetocode.com/Blogs/scott /archive/2008/01/30/11702.aspx

Le blog ci-dessus nous a conduits à notre système actuel de contrôle de version de base de données. En termes simples, aucune modification de base de données n'est effectuée sans script de mise à jour et tous les scripts de mise à jour se trouvent dans notre référentiel de contrôle de source.

Nous ne gérons que les modifications de schéma, mais vous pouvez également envisager de conserver des sauvegardes de vos données disponibles dans le contrôle de version. créer de tels fichiers est un exercice assez trivial avec mysqldump.

Notre solution diffère de la solution présentée dans le blog d’une manière clé: elle n’est pas automatisée. Nous devons également appliquer les mises à jour de la base de données, etc. Même si cela peut prendre un peu de temps, cela a retardé une partie des efforts qu'un système entièrement automatisé aurait requis. Cependant, nous avons automatisé le suivi des versions de la base de données dans le logiciel: c’était très simple et nous nous assurons que notre logiciel est au courant de la base de données sur laquelle il est exécuté et ne sera exécuté que s’il connaît le schéma avec lequel il travaille.

La partie la plus difficile de notre solution a été de savoir comment fusionner les mises à jour de nos succursales dans notre coffre. Nous avons passé un certain temps à développer un flux de travail pour traiter la possibilité que deux développeurs essayent de fusionner des branches avec des mises à jour de base de données simultanément et comment le gérer. Nous avons finalement décidé de verrouiller un fichier dans le contrôle de version (le fichier en question pour nous est en fait une version du logiciel de correspondance de tableau avec la version de base de données qui aide notre stratégie de gestion manuelle), comme vous le feriez pour la section critique d’un thread le verrou concerne leur mise à jour du coffre. Une fois cette opération terminée, les autres développeurs pourraient se verrouiller et il leur incombe d’apporter les modifications nécessaires à leurs scripts pour éviter les collisions de version attendues et d’autres mauvais juju.

Answer 3

Nous conservons tous nos scripts de base de données (données et schéma / ddl) dans le contrôle de version. Nous conservons également un catalogue central des modifications. Lorsqu'un développeur modifie un fichier de schéma / DDL ou ajoute un script modifiant les données d'une manière ou d'une autre, ces fichiers sont ajoutés au catalogue, avec le numéro de validation SVN.

Nous avons créé un petit utilitaire interne qui lit les modifications du catalogue et crée un script de mise à jour volumineux basé sur le contenu du catalogue en récupérant le contenu de chaque révision du catalogue et en les appliquant. Le concept est assez similaire à l'outil DBDeploy , qui, je crois, est originaire de Thoughtworks , afin que vous puissiez l’utiliser. Cela vous donnera au moins un bon point de départ. Vous pourrez ainsi personnaliser une solution plus directement adaptée à vos besoins.

Bonne chance!