Version imprimable
Bonjour,
Il me reste quelque jours avant la fin de mon projet et j'aimerais vous poser une question.
Comment fait-on un upgrade de la base de données ? je m'explique, j'ai une table, je souhaite rajouter un champs sans modifier les données dedans mais toujours en profitant des avantages de Symfony.
J'ai pensé à ajouter le champs dans le schema. Generer le modèle, form, filtre et ajouter le champs dans MySQL. Mais je pense que Symfony intègre un système non ?
Merci d'avance,
Je suppose que tu développes sur la base de production ?
La méthode "normal" pour symfony est d'avoir deux environnements distinct, un de développement, où l'on peut faire ce que l'on veut et l'autre de production.
L'environnement de développement est lui même divisé en trois sous ensemble, un pour le développeur et le débug (frontend_dev), un pour le développeur en situation client (le chemin "nu") et le dernier pour les test, en principe chacun des trois environnement devrait avoir sa propre base de donnée, il arrive que les deux base test de développement et test partagent la même.
L'environnement de production lui, doit être protégé de tous ces aléa et jamais touché (quoique, une fois tous les développement terminés)...
Il existe un outils qui génère des fixatures pour les changements de la base de données (ajout et/ou suppression de champs, tables, liens,...). Il part du schema.yml nouveau et d'une base ancienne et génère (plus ou moins bien) des procédures permettant d'y arriver.
Il ne reste plus qu'à appliquer sur la base de test "nu" puis en production.
Est-ce ce type d'outil que tu recherches ?
Oui c'est ce principe. Mais j'ai pas autant de serveur. J'en ai un en prod. Et un en dev.
Du coup, si une modification du schema est faite, il faut modifier celui en prod sans perdre les données.
Tu as un notion de "migration" qui permettent de générer du code passant de la base actuel en base définie dans le shema.yml.
Le principe est d'avoir, dans sur ton poste de dev, un environnement avec l'ancienne structure de la base et ton nouveau shema.yml NON ENCORE CONSTRUIT.
La commande "symfony doctrine:generate-migration... " va générer des commandes de migration. Pas de doc pour la 1.3/1.4 la seul que j'ai trouvé est pour la 1.2, mais, à priori, il n'y a pas de changement entre les version.
Ok merci, je vais lire cette commande afin de pas me planter XD et je reviendrais si j'ai d'autre question.
[édition] Les étapes sont-elles bonne:
puisCode:php symfony doctrine:generate-migrations-diff
enfinCode:php symfony doctrine:build --all
Code:php symfony doctrine:migrate
En principe, sur la base de prod, tu ne va pas faire un php symfony doctrine:build --all qui commence par effacer la base de donnée existante...
D'où l'utilisation du php symfony doctrine:migrate
ok donc il faut que je fasse un build --all-classes un --forms et un --filters ?
Il faut que tu génères ce qu'il te faut sur la version dev.
Ensuite tu recopie les fichiers généré sur le serveur de prod et tu appliques les modifications de la base (je te conseil fortement de tester avant). Sur le serveur de prod il n'y a donc aucun build a mettre en œuvre.
cette situation risque de pas tarder à m'arriver. Cool pour l'explication.
En ce qui concerne les fichiers modifiés, j'utilise la technique suivante.
Je compare (Sous Eclipse ou TextMAte, dépend de l'humeur), mon file system de projet avec la version Svn et les mise à jour en serveur de qualité ou en serveur de prod deviennent plus agréables.
ok donc je récapitule:
* En phase de DEV
- Tout généré. OK
- Modifier les fichiers nécessaires (templates). OK
* En phase de PROD
- Uploader les fichiers sur le serveur de prod
- Modifier la base de donnée à la main ?
Où intervient la commande migrate ?
- Sur environnement de dev modifier le shema.yml, build à gogo, modifier les modules, actions, template, tous ce qu'il faut. Tester et faire approuver...
- Sur un environnement intermédiaire (peut être un des environnements de dev) avec l'ancienne version de la base (important) et la nouvelle application, on va générer les fichiers de migration.
- Sur le même intermédiaire (ou un autre (deux essais, c'est un minimum) ) on va appliquer les migrations et vérifier que tous tourne correctement.
- Une fois l'application validée et les migrations testées, on va copier les fichiers de l'application sur le serveur de prod (auparavant sauvegardé, la base aussi). Et on applique les modifications.
M'a l'aire bien comme méthode, non ?
Je suis d'accord.Citation:
Sur environnement de dev modifier le shema.yml, build à gogo, modifier les modules, actions, template, tous ce qu'il faut. Tester et faire approuver...
Ok, je suis d'accord aussi, mais je ne sais pas encore comment faire ces fichiers ^^ la seul commande doctrine:generate-migrate puis une doctrine:migrate ou quelque chose comme ça suffit ?Citation:
Sur un environnement intermédiaire (peut être un des environnements de dev) avec l'ancienne version de la base (important) et la nouvelle application, on va générer les fichiers de migration.
Du coup oui, si on les génère, autant les tester.Citation:
Sur le même intermédiaire (ou un autre (deux essais, c'est un minimum) ) on va appliquer les migrations et vérifier que tous tourne correctement.
C'est juste un copie massif des fichiers (apps + lib + css) ?Citation:
Une fois l'application validée et les migrations testées, on va copier les fichiers de l'application sur le serveur de prod (auparavant sauvegardé, la base aussi). Et on applique les modifications.
Pour la db, il faut export donnée courante + import base de l'intermediaire + import donnée ? mais si on supprime une colonne faut supprimer aussi dans celle courante, donc ces c'est modifications que je ne sais pas dans quel ordre les faire ^^.
generate-migrate crée un fichier vierge où il faut rajouter des lignes ->addColumn ou ->removeColumn à la main.Citation:
Envoyé par butters
Il semblerait (mais je n'ai pas testé) que doctrine:migrate-db génère une partie des commandes. Il convient dans tous les cas de vérifier le fichier dans : lib/migration/doctrine et, le cas échéant de le compléter ou de le corriger.
A priori, il est possible d'y inclure des commande DQL pour peupler les nouvelles colonnes, si elle peuvent être peuplées à partir des données existantes.
Il faut copier tous ce qui est fichier applicatif (ton dossier projet) comme pour une nouvelle installation. Puis appliquer les migrates up. C'est ces fichiers qui vont créer les tables colonne ou les supprimer. Et éventuellement changer les données de tables ou de colonne ou les remplir, ou sauver les données...Citation:
Envoyé par butters
ma question rejoignant un petit peu ce thread, je préfère ne pas en ouvrir un nouveau.
J'ai 3 environnement différents :
-développement
-preview
-production
pour chaque environnement j'ai des nom de base et des login/pass différents.
quand l'on configure le database.yml, on peut indiquer des config différentes pour "all", "dev" et "prod" (comme pour pas mal de fichiers de config).
Mais si j'ai bien compris:
"dev" correspond à monsite.com/frontend_dev.php/
"prod" correspondant à monsite.com
"all" correspond à tous.
il y a aussi test je crois.
ce qui veut dire que je dois avoir 3 fichiers database.yml différents dans mes 3 environnements ? Ou est-ce qu'il y a un truk que j'ai loupé ?
Sur un poste de dev, il convient d'avoir au moins deux bases, une pour all et un pour test. Normalement, le poste de dev ne doit pas être celui de production (mise en ligne). Le all correspond aux deux modes de test du développeur le debug et le dev. La base peut-être la même les tests étant similaires.
La base pour les test (automatiques) à elle intérêt à être à part, de manière à permettre de la recharger régulièrement (une bonne séquence de test peut entrainer plusieurs dizaine de rechargement de la base).
Il peut être possible de différentier la base de test et la base de prod (qui n'est en fait qu'un environnement de test plus étendu)(la production réel étant sur un serveur dédié), surtout si des utilisateurs font des tests depuis cet environnement.
Il peut être nécessaire de créer d'autre environnement de base, sur de grosses applications, dans le cadre de long cycles de vie, pour permettre de générer des migrations et de les tester. Mais, c'est plus rare.
Il convient donc de rajouter dans le fichier database.yml des zones complémentaire, notamment une zone test:.
ok, je pense que j'avais compris un peu de travers.Citation:
Envoyé par mimi68
tu défini dans chaque environnement (dev, preview, prod) un fichier databases.yml qui va spécifier une série de database.
Dans le cas très répandu ou les nom de base et les login/password ne sont pas les même dans les différents environnement, tu auras un fichier databases.yml par machine (dev, preview et prod par exemple).
database.yml de dev
all :
database1
test :
database2
database.yml de preview
all :
database1a
test :
database2a
database.yml de prod
prod :
database 1b
test :
database 2c
En fonction de la taille du développement cela peut varier.
Tu n'es pas obligé d'avoir trois machine, généralement tu en auras deux, une de production, avec un seul environnement et une de développement (sauf si tu fais partie d'une équipe, mais alors, on va en reparler différemment) avec trois environnement le plus souvent (test, dev et preview qui est un excellent nom).
Si tu es seul développeur, mais que le développement doit être validé par un comité de testeurs, tu peux prévoir une troisième machine pour les testeurs.
salut,
alors dans mon cas j'ai 2 machine de dev.
Une au job et une chez le client. Je suis le seul développeur.
J'ai une machine de preview chez le client.
Et pour finir une machine de prod chez le client à laquelle je n'ai aucun accès.
C'est le service IT de l'entreprise qui s'occupe de tout.
On est dans un environnement presque classique, juste les deux machines de dev... je ne sais pas comment tu gères (svn ? cvs ? mercurial ? ou autre ?).
Pour les machine de dev j'utiliserais deux environnement, un pour le dev et le preview et un pour les test donc niveau database.yml
Les deux autres machines ont chacune un environnement.Code:
2
3
4
5
6
Vu que tu développes sur une application en exploitation, tu pourras être amené à créer des bases et des environnement complémentaires pour les éventuels migration de la base et leurs tests.
hello,Citation:
Envoyé par mimi68
je gère avec SVN. Merci pour tes explications.
Ca confirme, si j'ai bien compris, que je peut pas avoir le même fichier databases.yml dans tout les environnements (je parle ici d'environnement physique (dev,preview et prod)).
j'ai souvent utilisé le HTTP_HOST pour changer dynamiquement mes valeurs pour la bd selon l'environnement.
Concernant la partie test, je m'y suis mis tout récemment. Puissant comme système.