Discussion :

[Denis Dee Jay]

Bonjour à tous,

Ca fait plusieurs semaines que ce problème me trotte dans la tête et maintenant plusieurs jours que je m'acharne a essayer de trouver une solution.

Je suis en train de passer nos développeurs sur Git pour que tout le monde travaille uniquement sur une version de développement de nos applications web. Grosso modo, c'est du 85/15 (85% backoffice, outil métier etc et 15% de frontoffice) utilisant plusieurs bases de données (toutes sous mysql 5).

Auparavant, c'était un peu "a l'ancienne". Chacun bossait "en live" sur le FTP avec Dreamweaver et resynchronisait sa copie locale pour éviter d'écraser les corrections faites par un autre ... Concernant la base de données, ça a toujours été le point central que tout le monde "peut toucher" et dans certains cas ça peut être du haut vol ... (genre on change la clé primaire d'une table, faut que tous les fichiers .php contenant des requetes sql vers cette table soit ouverts et corrigés et on fait un gros "crtl+s" d'un coup sur tous les fichiers pour éviter que ça plante ...)

Bref, c'était la préhistoire et je voudrai les tourner vers un environnement de ce genre :
- développement sur sa copie locale
- versionning avec git
- développement uniquement sur les branches de développement
- merge des branches puis push sur serveur de test/dev
- si tous les tests sont bon, on push sur le serveur de prod
- rollback si un problème en prod

Tout ce qui est "fichiers", c'est parfait. J'en suis encore au bon vieux "git diff" + ftp pour la partie mise en production mais avec notre nouveau serveur de prod, tout sera fait directement via git.

Mon problème c'est les bases de données (enfin, une en particuliers, les autres étant plus pour de cas précis).
Je voudrai savoir comment je pourrai faire pour que chacun puisse travailler "dans son coin", qu'il puisse modifier les schémas de la bdd (ajout de table, ajout de champs, renommage de champ etc.) sans que ça vienne impacter les autres développeurs.

J'ai bien pensé à un système conjugant un serveur de bases de données uniquement destiné au développement et une synchronisation avec les bases de données de production mais cette solution ne me convient pas car, par exemple :
- l'action de renommage d'une table par un développeur cassera la version que les autres ont
- obligation d'une connexion internet juste pour ça (donc soumis aux aléas de bande passante ...)
- impossible de tester des évolutions de bases de données sans que ça ne dérange les autres développeurs

Je cherche désespérément a faire un système de versionning de bdd avec par exemple, un répertoire "up" et un autre "down" contenant chacun les corrections a faire pour la version en cours ... c'est là que ça bloque.

J'ai pensé aussi à faire un simple dump de la structure des tables et de le placer dans notre répo git. Git nous indiquera les modifications sur le schémas mais on ne sera pas capable de savoir si on a modifié un champs existant (et donc conservé les données) ou supprimé un champ et ajouté un autre a sa place (et donc perte des données) ...

Bref, vous l'aurez compris, je m'arrache les cheveux sur ce problème. Que me conseillerez-vous pour gérer les évolutions de nos bdd ?

Merci à tous ceux qui répondront

[LeGnome12]

Bonjour Dennis,

Je rencontre le même problème. Dans la société où je travaille depuis 4 ans on a suivi le même cheminement. On est parti du développement de haut vol sur le serveur de prod pour en arriver à un gestionnaire de version (GIT) avec un développement en local sur nos postes.

Le problème de la base de données est donc remonté. En effet, GIT permet de très bien gérer les versions des fichiers, mais pour la base de données c'est un gros problème.


Voici la solution qui est en place :
- Chaque nuit, le serveur de production génère un Dump complet de la base avec le contenu. (c'est un serveur intranet donc personne connecté la nuit)
- Chaque matin, ma station récupère le Dump qui est exécuté pour remettre à plat ma base de données locale sur mon poste.

Cette configuration permet d'avoir une structure et des données de test toujours à jour.

Voici la technique utilisé pour les évolutions de structures :
J'ai créer un fichier .sql qui contient le script de migration de la base de données pour toutes les évolutions (ex : changement de statut des clients). Ce fichier est exécuté chaque matin après la remise à plat de ma base locale.
Ce système me permet de tester efficacement mes scripts de migrations.
Dans la même idée, je peu ajouter aussi un script de création d'un jeu de test.

C'est une organisation correction, mais il me manque la gestion des versions.

Si quelqu'un a une idée pour gérer les versions / évolutions de BDD, je suis preneur. En attentant, je pense que l'organisation que j'utilise est plutôt efficace.

LeGnome12

[Marco46]

Le problème de la base de données est donc remonté. En effet, GIT permet de très bien gérer les versions des fichiers, mais pour la base de données c'est un gros problème.

Normal GIT n'est pas prévu pour gérer les bases de données, seulement du code source.

Voici la solution qui est en place :
- Chaque nuit, le serveur de production génère un Dump complet de la base avec le contenu. (c'est un serveur intranet donc personne connecté la nuit)
- Chaque matin, ma station récupère le Dump qui est exécuté pour remettre à plat ma base de données locale sur mon poste.

[...]

Cette configuration permet d'avoir une structure et des données de test toujours à jour.

Ton poste de développement n'a pas besoin d'avoir des données à jour avec la prod.
Pareil pour la structure.

Tu as besoin d'une installation locale de ton SGBD, et d'un ou plusieurs set de data pour les dev puis les tests.

Voici la technique utilisé pour les évolutions de structures :
J'ai créer un fichier .sql qui contient le script de migration de la base de données pour toutes les évolutions (ex : changement de statut des clients). Ce fichier est exécuté chaque matin après la remise à plat de ma base locale.
Ce système me permet de tester efficacement mes scripts de migrations.
Dans la même idée, je peu ajouter aussi un script de création d'un jeu de test.

C'est grosso modo la gestion faite dans le framework Play.

C'est une bonne solution, les merges de structure de la db entre dev sont gérés via git sur les scripts sql.

Je comprends pas l'utilité d'avoir une tache quotidienne qui remet ta db à plat chaque matin. Tu dois pouvoir reset ta db en un clic via une tache ant (ou autre) et injecter un jeu de test avec une autre tache automatisée. Le tout exécutable n'importe quand manuellement au cours des dev.
C'est le système le plus souple.

C'est une organisation correction, mais il me manque la gestion des versions.

Si quelqu'un a une idée pour gérer les versions / évolutions de BDD, je suis preneur. En attentant, je pense que l'organisation que j'utilise est plutôt efficace.

LeGnome12

Tu veux versionner quoi ? Les différents commit de chaque membre de ton équipe ?

Pour moi le n° de version de ta DB est celui de ton appli. Je veux dire, tu fais la livraison de la version 1.1.1 de ton appli, ben le n° de version de ta DB c'est 1.1.1.
Faire des n° de version pendant les dev entre la 1.1.0 et la 1.1.1 n'a pas de sens, cela n'apporte rien.