Discussion :

[max-mag]

Bonjour,

J'ai un problème d'outillage pour devenir un peu plus agile ...

Prenons l'exemple d'un développement basé sur un CMS php/mysql (Drupal, Joomla, Prestashop, etc ...).

Pour livrer une Vn à une Vn+1 d'un site en production, un graphiste peut être amené à modifier la configuration du CMS (par exemple : changer les dimensions d'images générées à la volée, dans le back-office du logiciel).

C'est un graphiste, il n'aura pas les compétences pour écrire une requête SQL faisant la même chose. Il n'est donc pas possible qu'il utilise un outil comme DBDeploy pour gérer les configurations modifiées en base de données.

Il n'est pas non plus envisageable d'écraser la base de production par la base de données de travail du graphiste.

Une solution que je vois est qu'un développeur compare les base de données avant / après les modification pour rédiger les requêtes à utiliser par DBDeploy par exemple.
Je trouve cela vite complexe je trouve.

Autre solution, le graphiste peut enregistrer ses modifications (avec une outil comme Selenium par exemple), pour les rejouer sur le site de production. Je pense que la robustesse risque d'être le point faible.

Et vous, comment gérez vous cela ?
Avez vous des outils à conseiller, une organisation particulière ?
Merci de vos retours.

[Luckyluke34]

Je sais que des outils comme Apex permettent de faire des diff sur la structure de bases de données et de générer des scripts de migration.

Maintenant si ce ne sont que des changements de paramétrage d'un CMS (donc simple modification de données et non ajout de colonnes, de tables...) je ne sais pas si ça le gère...

Les CMS ne proposent pas d'outils d'export/import de paramétrage ? Ca vaudrait peut-être le coup d'explorer de ce côté-là aussi.

[max-mag]

Apex ne fonctionne pas avec MySQL, dommage

En l'état les CMS n'utilisent pas d'export de configuration dans l'esprit pre-prod / prod.
On peut faire des sauvegardes de configuration pour une url donnée par exemple. Ce qui posera problème pour les urls de pre-prod et de prod.

Cela reste cependant la piste la plus pratique me semble-t-il en faisant pour chaque CMS un filtre des données spécifiques.

[montesq]

Apex ne fonctionne pas avec MySQL, dommage

En l'état les CMS n'utilisent pas d'export de configuration dans l'esprit pre-prod / prod.
On peut faire des sauvegardes de configuration pour une url donnée par exemple. Ce qui posera problème pour les urls de pre-prod et de prod.

Cela reste cependant la piste la plus pratique me semble-t-il en faisant pour chaque CMS un filtre des données spécifiques.

Effectivement c'est un problème bien connu des CMS où le contenu et la configuration se trouvent tous les 2 dans la base de données.
En ce qui concerne Drupal, la "bonne" nouvelle est que cela fait l'objet d'une attention particulière pour Drupal 8 (http://groups.drupal.org/build-syste...management/cmi), la mauvaise nouvelle c'est que Drupal 8 n'est pas prévu avant septembre 2013 (de mémoire).
En attendant, regarde peut-être du côté du module "features" (je ne suis pas fan mais bon...)