Discussion :

[symfolive]

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:

• 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

C’est parti!




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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 mkdir /home/projects/sfProjectSymfolive
svnadmin create /home/projects/sfProjectSymfolive

Création de la structure de notre projet

Un projet SVN se doit de comporter 3 dossiers principaux:

• tags
• branches
• trunk

Le tronc (trunk) étant la version actuelle, et les branches/tags des versions de développement ou des versions passées qui continuent néanmoins à être maintenues.

Créons donc cette structure dans un dossier temporaire, pour l’intégrer au Repository:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mkdir /tmp/project /tmp/project/trunk /tmp/project/tags /tmp/project/branchessvn import /tmp/project/ file:///home/projects/sfProjectSymfolive -m "Import de la structure"

On obtient donc la structure arborescante suivante:

• root
• branches
• tags
• trunk

La copie de votre projet

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

 cd /home/domains/sfProjectSymfolive svn co file:///home/projects/sfProjectSymfolive ./

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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

svn add vendor

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

svn propedit svn:externals ./vendor

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

symfony http://svn.symfony-project.com/branches/1.0/

Nous allons donc envoyer nos changements aux repository :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

svn commit

Une fois les changements effectués, faite un simple update de votre copie de travail et le tour est joué

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

svn up

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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 cd /home/domaines/sfProjectSymfonylive/trunk // toujours notre copie de travail php5 /home/domaines/sfProjectSymfolive/vendor/symfony/data/bin/symfony init-project sfProject

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sfProjectSymfonylive

Quelques réglages

Une simple commande permet d’ajouter tous les nouveaux fichiers en une seule passe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

svn add * --force

Ensuite on intègre les changements au repository

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

svn commit

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:
YouTube- Installing and using TortoiseSVN!

Billet original

[Sylvain__A_]

Cool ! 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.

[fanto30]

@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]

[Sylvain__A_]

tu peux m'expliquer l'utilité de pré-prod ?

Oui, c sur que vu comme ça 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é ...

[kershin]

Pas 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 !

[seb012007]

Bonjour,

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.

[mantex]

[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]

Tu utilises toi fanto30 GIT sous symfony ?