Frameworks PHP : Travailler sous Subversion (SVN) avec Symfony
Proposé depuis le blog Symfolive
Le 2010-05-29 18:40:46, par symfolive, Nouveau membre du Club
Permettre un travail collaboratif sur un grand framework si puissant tel que le framework Symfony est essentiel dans un projet complexe. Dans cet article, nous allons donc voir comment travailler avec le système de versionnage Subversion (svn).
Les avantages sont importants:
Créer un dossier de stockage partagé (repository)
Un « Repository » ou dossier de stockage partagée , c’est le dossier où va être stocké l’ensemble des modifications et ajouts apportés par les acteurs du projets.
Nous allons donc créer ce répertoire :
Création de la structure de notre projet
Un projet SVN se doit de comporter 3 dossiers principaux:
Créons donc cette structure dans un dossier temporaire, pour l’intégrer au Repository:
On obtient donc la structure arborescante suivante:
Une « copie de travail« , c’est une copie intégrale de votre projet que vous allez pouvoir modifier, enrichir, recréer, tout en étant certain que chacune des modification sera bien enregistrée dans le Repository. Il doit donc exister autant de copies de travail que de personnes qui interviennent sur votre projet.
On a donc un répertoire qui contient nos trois dossiers: branches, tags et trunk. Nous allons rajouter un nouveau répertoire: vendor.
Ajoutons-le donc avec:
Il nous reste donc plus qu’a connecter ce répertoire à une copie distante de Symfony. Cette manipulation permettra de récupérer automatiquement les nouvelles mises à jour du package
Dans la fenêtre qui s’ouvre on rentre simplement le nom du package, puis l’adresse SVN correspondant à la version que l’on souhaite récupérer.Dans notre exemple, c’est la version 1.0
Nous allons donc envoyer nos changements aux repository :
Une fois les changements effectués, faite un simple update de votre copie de travail et le tour est joué
Et la lumière SVN fut Le système récupère tout seul l’ensemble de l’arbre de Symfony. L’avantage, c’est qu’à chaque correction de bug sur la branche que vous avez choisie, votre version locale sera immédiatement modifiée, à chaque fois que vous ferez un update.
Création du projet Symfony
Dans Symfony, toutes les lignes de commandes se font via l’intermédiaire du fichier symfony.bat. Dans notre arborescence, l’executable symfony se trouve dans le répetoire vendor/data/bin/. Pour créer un projet, on va donc simplement se rendre dans le répertoire cible (trunk/ dans notre cas), puis ajouter un nouveau projet à partir de l’executable.
Quelques réglages
Une simple commande permet d’ajouter tous les nouveaux fichiers en une seule passe:
Ensuite on intègre les changements au repository
Et voila! Le tour es joué
Je finirai par vous montrer que tous ces lignes de commandes peuvent se fair graphiquement via le logiciel Toirtoise SVN:
!
Billet original
Les avantages sont importants:
- Travailler avec confiance en manières collaborative
- Pouvoir revenir à une version précédente
- permettre à plusieurs personnes de travailler efficacement sur le projet
- Un accès à toutes les versions successives de l’application
Créer un dossier de stockage partagé (repository)
Un « Repository » ou dossier de stockage partagée , c’est le dossier où va être stocké l’ensemble des modifications et ajouts apportés par les acteurs du projets.
Nous allons donc créer ce répertoire :
Code : |
1 2 | mkdir /home/projects/sfProjectSymfolive svnadmin create /home/projects/sfProjectSymfolive |
Un projet SVN se doit de comporter 3 dossiers principaux:
- tags
- branches
- trunk
Créons donc cette structure dans un dossier temporaire, pour l’intégrer au Repository:
Code : |
mkdir /tmp/project /tmp/project/trunk /tmp/project/tags /tmp/project/branchessvn import /tmp/project/ file:///home/projects/sfProjectSymfolive -m "Import de la structure"
- root
- branches
- tags
- trunk
Une « copie de travail« , c’est une copie intégrale de votre projet que vous allez pouvoir modifier, enrichir, recréer, tout en étant certain que chacune des modification sera bien enregistrée dans le Repository. Il doit donc exister autant de copies de travail que de personnes qui interviennent sur votre projet.
Code : |
cd /home/domains/sfProjectSymfolive svn co file:///home/projects/sfProjectSymfolive ./
Ajoutons-le donc avec:
Code : |
svn add vendor
Code : |
svn propedit svn:externals ./vendor
Code : |
symfony http://svn.symfony-project.com/branches/1.0/
Code : |
svn commit
Code : |
svn up
Création du projet Symfony
Dans Symfony, toutes les lignes de commandes se font via l’intermédiaire du fichier symfony.bat. Dans notre arborescence, l’executable symfony se trouve dans le répetoire vendor/data/bin/. Pour créer un projet, on va donc simplement se rendre dans le répertoire cible (trunk/ dans notre cas), puis ajouter un nouveau projet à partir de l’executable.
Code : |
cd /home/domaines/sfProjectSymfonylive/trunk // toujours notre copie de travail php5 /home/domaines/sfProjectSymfolive/vendor/symfony/data/bin/symfony init-project sfProject
Code : |
sfProjectSymfonylive
Une simple commande permet d’ajouter tous les nouveaux fichiers en une seule passe:
Code : |
svn add * --force
Code : |
svn commit
Je finirai par vous montrer que tous ces lignes de commandes peuvent se fair graphiquement via le logiciel Toirtoise SVN:
Billet original
-
Sylvain__A_Membre régulierCool ! Merci à vous
Je connaissais pas propedit
Je n'ai pas bien compris ce que c'est que ce dossier tmp ? Pourquoi temporaire ? Pour moi au contraire, SVN c'est construit pour durer ...
Pour élargir la discussion, je me demande quelle solution choisir pour synchroniser trunk avec le webroot d'Apache. J'ai 2 versions, prod et preprod. Uploader les fichiers vers la prod manuellemnt, je trouve ça rassurant, ça me va bien. Mais ça pourrait être pratique, si lorsque tu comittes vers la preprod, les fichiers se mettent à jour dans le webroot du projet. J'ai un peu étudié phing :
phing
C'est vraiment génial, ça me fait penser à Ant ou Maven, mais je me demandais si personne n'avais une idée plus ... simple, instantanée, un genre de lien symbolique.le 02/06/2010 à 13:08 -
fanto30Nouveau membre du Club@Sylvain : bienvenu dans le monde l'intégration continue
En gros si tu commites dans pré-prod (en fait non, mais je développe juste après), pour de suite copier dans prod, tu peux m'expliquer l'utilité de pré-prod ?
En gros :
- commit dans ton espace de versionnage
- update de pré-prod
- lancement des tests unitaires dans cet environnement
- si c'est bon, intégration (note bien ce mot) dans prod
Sinon, tout le reste c'est un peu que des procédures qui alourdissent la chose, sans t'amener aucun confort.
Pour l'intégration, un rsync peut suffire.
Mais des choses comme hudson par exemple, sont là pour ça.
Avec update/tests/intégration pris en charge par un process.
Et surtout toute la métrique qu'on peut avoir besoin derrière.
En gros, pour moi, c'est un peu tout ou rien.
Soit tu fais l'effort d'une chaine d'intégration complète, soit tu te donne l'impression/fais croire que tu "maitrises".
[apparté : SVN c'est sympa, mais dès que le projet vit pas mal, avec plusieurs intervenants, ca devient vite un truc qui fait juste de la sauvegarde, autant regarder du coté de GIT ou Mercurial]le 02/06/2010 à 14:44 -
Sylvain__A_Membre réguliertu peux m'expliquer l'utilité de pré-prod ?
Pour moi la prod correspond à un build, c'a'd une livraison, un état stable du code, le résultat d'une phase de tests / retake ...
Par contre, la preprod, c un environnement d'expérimentation. C'est un clone de la prod, coté configuration, mais sur lequel on upload du code très régulièrement, à des fins de validation par exemple...
J'ai regardé Hudson, c vrai que ça à l'air d'être intéressant, mais il faut un serveur EE (sauf erreur), et on s'éloigne de Symfony.
La méthode que tu proposes est intéressante, mais PHING permettrait de faire un export journalier du SVN, quand un simple update, oblige à synchroniser directement celui-ci.
Pourquoi parles tu d'intégration ? ça a l'air important pour toi, pourquoi ?
A propos de GIT, c vrai que sur le papier ça a l'air Tip Top, mais j'avoue qu'à l'installation, j'ai été un peu dérouté ...le 02/06/2010 à 19:06 -
kershinMembre du ClubPas vraiment en rapport avec le sujet, mais plutôt avec symfolive...
L'idée du site est très bonne et il y a beaucoup de bonne volonté derrière, de plus les tutos sont bien faits.
Une seule chose que je déplore et qui est un gros inconfort pour moi, et sans doute pour d'autres aussi: ce sont les fautes, y en a quand même pas mal, et même en page d'accueil, ca pique aux yeux.
Please un petit effort et ce site deviendra incontournable !le 04/06/2010 à 14:08 -
seb012007Membre du ClubBonjour,
Pas mal comme tuto mais il manque la partie svn:ignore. C'est important car elle permet que certains fichiers soient modifiés sans être inclus dans un commit. C'est particulièrement utile pour les fichiers qui vont être générés par Symfony.
Basiquement il faut ajouter cette propriété aux répertoires suivants :
- cache
- log
- data
- web/uploads (le cas échéant)
Et il n'est pas mauvais de compléter cela par un nouveau svn:ignore dans les répertoires /lib/model/doctrine, /lib/filter/doctrine et /lib/form/doctrine :
- svn:ignore Base*.class.php
Cette dernière commande permet de ne pas inclure dans le référentiel les fichiers de Base du modèle générés par le framework. Donc lorsqu'un commit est effectué seul le fichier shéma.yml est remonté, ce qui permet d'utiliser doctrine:migrate pour migrer sa base de données sans avoir à la régénérer et donc sans perdre les données.
Un autre tuto bien fait sur le même sujet :
http://www.lelio.fr/blog/2010/01/cre...rojet-symfony/
[edit] J'explique pour la commande doctrine:migrate :
En fait il faut utiliser doctrine:generate-migrations-diff, cette commande va calculer les différences entre le fichier schema.yml et les classes Base* du modèle afin de produire un script qui va migrer la database et les classe avec la commande doctrine:migrate sans perdre les données de la database.le 06/06/2010 à 8:57 -
mantexMembre régulier
Envoyé par fanto30
Tu utilises toi fanto30 GIT sous symfony ?le 18/11/2011 à 16:05