Discussion :

[EcureuilMaster]

Bonjour !

Je suis actuellement en train de développer un site sous Symfony en local.
Je sais que la mise en prod se fera sur un hébergement OVH qui ne possède pas de ligne de commande.

Pour le moment, je suis donc obligé d'envoyer tout mon projet avec le FTP (en arrangeant les trucs qui vont bien : suppression du cache, modification des paramètres de la DB, ...).
Pour la DB, je fais un dump de ma base locale et je l'importe dans ma base OVH (préalablement vidée).

Seulement, cette démarche trouvera ses limites lorsque le site entrera en prod.
En effet, lorsque je ferais une mise à jour modifiant le schéma, je devrais alors choisir entre conserver les données de prod ou mettre à jour la structure de la DB.
Dans le 2ème cas, ma mise à jour sera donc entièrement répercutée sur l'environnement de prod, mais j'aurais mes fixtures au lieu des données présentes avant la mise à jour.

Connaissez-vous l'existence d'une procédure qui permettrait de mettre à jour mon application tout en conservant mes données de prod, et sachant que je n'ai pas accès à la ligne de commande sur le serveur de prod ?

Merci d'avance !

[dourouc05]

Une solution un brin bourinne mais fonctionnelle : dans PhpMyAdmin ou équivalent, tu ajoutes les champs qu'il faut dans ta base. Ça ne mettra pas de données dedans, mais ça fera au moins que tout fonctionne. Il doit y avoir mieux, c'est cependant tout ce que j'ai trouvé...

[EcureuilMaster]

C'est bourrin, mais merci, je n'y avait pas pensé

Du coup, as-tu connaissance d'un outil qui pourrait générer, à partir des 2 structures sql (l'ancienne et la nouvelle), les instructions nécessaires au passage de l'ancienne à la nouvelle ?
Si un tel outil existait, ça serait royal
Malheureusement, je n'en ai jamais entendu parler...

[dourouc05]

Ça s'appelle la mémoire (il suffit de faire un diff sur ton schéma et tu vois les nouveaux champs apparaître tout seuls). Sinon, il y a des commandes de mise à jour de la base, il doit y avoir moyen de récupérer ce qu'ils font (ça doit bien être enregistré dans un fichier temporaire ou qqhc du genre).

[EcureuilMaster]

il suffit de faire un diff sur ton schéma et tu vois les nouveaux champs apparaître tout seuls

Je ne te suis pas là
Peux-tu développer un petit peu s'il te plait ?

[dourouc05]

Tu surveilles les modifications de ton schéma, soit à l'aide d'outils comme Subversion, soit avec l'outil diff (soit à la mémoire). C'est-à-dire que tu peux voir très exactement quels ont été les changements dans le schéma et ainsi les répercuter dans la base (à coup de ALTER TABLE).

[Vivian Pennel]

La meilleure solution si utilises doctrine est les migrations :
http://www.doctrine-project.org/proj.../migrations/en

Vu que tu n'as pas d'accès ssh, tu peux rapatrier la base de production en local, appliquer les migrations puis la livrer en production.

Dans le cas contraire, il faut passer par un système de script de mise à jour (équivalent à ceux des migrations) mais en SQL.
Tu écris des ALTER, INSERT etc... dans un fichier sql daté pour chaque mise à jour. L'idéal pour ne pas faire d'erreur est d'avoir une table version, et à chaque mis à jour tu incrémentes le numéro de version, et AVANT chaque mise à jour tu vérifies via une requête que le numéro de version est N-1.

Dans le cas où tu dois repasser les scripts comme ça tu ne peux que les passer dans l'ordre.

[Michel Rotta]

Je préfère la solution de Vivian. Un peu moins bourin (et le système de symfony ne fait pas autre chose).

De toutes les manières, si tu n'as pas d'accès ssh c'est que tu es sur un petit hébergement, donc le site doit avoir un trafic faîble, le fermer pour modification de la base durant 10mn ne doit être très pénalisant.

N'hésite pas a faire plusieurs test avant. Fait et garde une sauvegarde des données ET du site avant d'appliquer les modifications.

De toutes les manières, il ne faut pas se faire d'illusion, si les données peuvent être modifiées en quelques dizaines de seconde par une proc sql, il faudra plusieurs minutes (ou plus) pour charger les fichiers php modifié sur le site en ftp... (vu que tu n'as pas de ligne de commande, impossible de les charger dans une autre arborescence et les copier en local ensuite) et pas question de laisser le site accessible alors que les deux versions vont se partager les dossiers.

Il faut rester réaliste, on ne peut pas demander à un tel hébergement des résultats équivalent à ceux dédiés à de gros sites pro en exploitation, donc, soit on accepte les contraintes mais on est comptent du prix, soit on ne veux pas les contraintes, mais on paye un hébergement pro de qualité (attention, je ne critique pas les hébergements OVH, chez qui j'ai plusieurs sites hébergé).

[EcureuilMaster]

Merci pour vos réponses !

Pour le moment, je vais prendre le temps de faire des essais avec sqlt-diff.
C'est un programme écrit en perl qui semble faire ce dont j'ai besoin.
--> http://search.cpan.org/~jrobinson/SQ...ript/sqlt-diff

On verra bien ce que ça donnera...

[Michel Rotta]

Bonne chance.

Mais je reste convaincu qu'un suivi des modifications et la rédaction régulière des procédures permettant un up et un down de version sont la meilleur manière de procéder.

De plus, un tel outil va te générer les créations et modification de structure, mais que fera-t-il des données ?

Dans ce cas, l'automatisation aveugle me semble bien hasardeux. Fait des sauvegardes, beaucoup de sauvegardes...