|
deblok
|
Modérateur
Inscrit le : 09/05/2005
|
# Le 09/02/2007 à 15:19
J'ai 3 developpeurs php qui travaillent parfois sur des projets commun.
Comment vous faites pour qu'ils se marchent pas dessus ?
- 1 serveur local que tout le monde utilise ?
- chacun sur son poste ?
- 1/des serveurs online ?
- 1 logiciel de versionning ? (subversion ?)
- 1 logiciel de gestion de projet ?
Merci de vos avis John VIDOR
Président JVWEB
Liens Sponsorisés - Référencement Naturel - Ergonomie |
|
erwinol
| Erwin
Membre
Inscrit le : 09/05/2005
|
# Le 09/02/2007 à 16:38
Avec un serveur CVS mais parfois c'est le bordel tout de même.
Récemment on a eu des soucis de versionning et mes développeurs se sont tous renvoyé la balle avant de se concerter pour rejetter la faute sur subversion ... mais je soupçonne un peu de mauvaise foi.
Résultat : 2 jours de travail perdu (mais ça aurait pu être pire).
Quelle que soit la méthode utilisée, il faut veiller à ce que tout le monde respecte la procédure établie.
Ce type d'infrastructure n'est utile que lorsque tu as au moins 3 dev sur un même projet. Lorsque tu n'en as que 2, tu peux facilement diviser le travail.
(Message édité le 09-02-2007 à 17h59 par erwinol) |
|
superfc
| Florent
Membre
Inscrit le : 01/07/2006
|
# Le 09/02/2007 à 21:35
CVS/SVN c'est plus pratique pour du code compilé mais ça peut être utilisé avec des scripts. A noter que SVN est nettement plus au point par pas mal d'aspect que CVS. Déjà le versionnage est global (et non pas par fichier). Le renommage de fichier n'est pas possible sous CVS. Et SVN est environ 10x plus simple à installer et gérer que CVS. Les deux fonctionnent très bien pour les merges.
Une petite note, à la création du serveur SVN, pensez bien à préciser "--fs-type=fsfs" sinon vous risquez de hurler lors d'une corruption de base de données.
Soit tu choisis que tout le monde bosse sur le même serveur (distant ou local, on s'en fout), et dans ce cas là, SVN n'est pas trop adapté. Mais tu peux toujours lancer une sauvegarde toutes les 4h (ou un svn add recursif puis svn commit).
Soit tu choisis que tout le monde bosse en local et dans ce cas là un serveur SVN est très bien (mais pour la base de données, il faut à nouveau se concerter). A mon avis, c'est la meilleur méthode.
D'autant que l'origine des problèmes peut facilement être trouvée (quand on sait qu'on peut être accusé, on fait moins de conneries). Et on peut aussi réaliser des stats de commit et voir les changements fait par chaque utilisateurs, bref un suivi parfait.
Les logiciels de gestion de projets, c'est optionnel. C'est pas mal pour prévoir le timing et répartir les tâches. Mais finalement, vous risquez de passer plus de temps à rentrer les données que à vraiment l'utiliser (surtout pour un petit projet).
Maintenant, si il y a des mecs qui ont du mal à se gérer, ça permet de les stresser si ils dépassent le temps qu'ils s'étaient imposés.
Et sinon, les forcer à bien communiquer entre eux pour qu'ils sachent exactement où en sont les autres et qu'ils exposent au mieux leur besoins, c'est peut-être le plus important. Florent Clairambault - http://florent.clairambault.fr
Gtalk : superfc@gmail.com |
|
tonguide
| Jeremy
Modérateur
Inscrit le : 09/05/2005
|
# Le 09/02/2007 à 22:50
Tu as une adresse ac des tutoriaux sur SVN ou CVS ? (si possible en français) histoire de voir comment ça marche
J'ai déjà entendu parlé vite fait, mais jamais testé, et c'est vrai que dès qu'on dépasse les 2 developpeurs, c'est très dure à tout suivre. |
|
erwinol
| Erwin
Membre
Inscrit le : 09/05/2005
|
# Le 09/02/2007 à 23:27
Personnellement j'ai utilisé les deux et aucun ne m'a complètement satisfait.
Dans mon ancien job, on utilisait "Tortoise SVN" et dans mon job actuel, j'ai mis en place un serveur CVS ... et je suis bien tenté de travailler à nouveau à l'ancienne. C'est juste une question d'organisation. |
|
superfc
| Florent
Membre
Inscrit le : 01/07/2006
|
# Le 10/02/2007 à 07:37
SVN est nettement plus au point que CVS. Ca a été fait pour combler la lacunes de SVN. On ne peut quasiment pas les comparer.
Les deux seuls avantages de CVS c'est ses fichiers générés simple (mais ça créé des contraintes sur le système) et son grand âge.
Donc, "l'ancienne", c'est normal que tu veuilles y revenir, puisque SVN est une amélioration de CVS. Ce système beaucoup moins de contraintes et est bien mieux construit.
Un exemple tout simple, sachant que les numéro de versions sont globaux, quand on veut revenir en arrière c'est simple. Avec CVS, il faut restaurer chaque fichier à une date spécifique (qu'il faut déterminer soit même). Heureusement TortoiseCVS permet de le faire automatiquement, mais ça reste tout de même beaucoup plus lourd que consulter le suivi de version de SVN.
http://fr.wikipedia.org/wiki/Subversion_%28logicie...
D'autre part, le logiciel de gestion SVN sous Windows, TortoiseSVN, est bien plus abouti que TortoiseCVS.
Florent Clairambault - http://florent.clairambault.fr
Gtalk : superfc@gmail.com |
|
JeromeF
| Jérôme
Membre
Inscrit le : 10/05/2005
|
# Le 10/02/2007 à 09:33
Je pense que vous n'exploitez pas toutes les possibilités de CVS.
Il est tout à fait possible de redescendre une version de la conf sans problème.
Quaned tu changes de version, tu mets un tag (syumbolique) sur tous tes fichiers et quelque soit leur révision : cvs rtag <v1.5> * (pour la version 1.5)
A tout moment tu peux redescendre cette version : cvs co -r <v1.5> <nomdesmodules>
Et les accents concurrents sont bien gérés, les merges sont bien effectués pour la plupart.
Il y a aussi WinCVS (gratuit) pour ce qui préfère un outil graphique ;) |
|
erwinol
| Erwin
Membre
Inscrit le : 09/05/2005
|
# Le 10/02/2007 à 12:00
superfc : si tu relis mon post plus haut, tu verras que j'ai déjà touché à TortoiseSVN (pas Tortoise CVS) et que je n'en ai pas totalement été satisfait.
Le produit me conviendrait si mes développeur avaient un peu plus de discipline. Mais quand ils oublient régulièrement de faire un checkout au début de la journée et qu'ils oublient de mettre à jour la version commune à la fin d'une tâche, ils travaillent sur une ancienne version, ils écrasent des versions valides avec des version plus anciennes qui comportent des bugs qui avaient pourtant été corrigés.
Je me souviens encore de nombreuses prises de têtes :
- c'est de ton coté que ça foire, ça bugge de partout
- mais non j'avais déjà corrigé tout ça, c'est toi qui a écrasé ce que j'ai fait avec SVN
- t'es de mauvaise foi là, on est en retard sur le projet par ta faute
- c'est toi qui nous fait perdre des demi-journées de boulot, tu dois faire un checkout avant de commencer à dev
Bref, je suis rapidement revenu à l'ancienne. Les fichiers sur le serveur et ils travaillent tous sur la même version ... si 2 personnes travaillent sur le même fichier, ils le savent rapidement. |
|
superfc
| Florent
Membre
Inscrit le : 01/07/2006
|
# Le 10/02/2007 à 17:02
Ok JeromeF, mais c'est pas vraiment simple. Ca fait pas partir de l'idée de départ de CVS (qui fait bien un versionnage par fichier et non d'ensemble). D'autre part, CVS ne peut pas faire déplacement/renommage de fichier. C'est un peu contraignant.
Sinon erwinol, ouais je disais juste que SVN était plus au point que CVS.
Par contre pour tes développeurs, ils sont un peu graves. Avant chaque début de programmation, on faire un "update", et à chaque changement (fonctionnel) un "commit". C'est la rêgle de base de CVS/SVN.
Perso, j'utilise CVS/SVN depuis 3 ans pour tous les projets que j'ai à faire avec d'autres mecs de mon école et on a rarement eu des problèmes de version.
Le vrai problème vient peut-être d'un mauvais découpage des tâches. Parce que c'est vrai que quand on est plusieurs à bosser sur les même parties, ça fout le bordel.
Même si on sait comment corriger l'erreur, il faut que ce soit l'autre qui le fasse pour éviter de rentrer en collision avec les changements qu'il était en train de faire.
Sinon, tu devrais regarder du côté de Microsoft Office Groove 2007. Tu peux partager un répertoire entre plusieurs personnes et les changements sont appliqués aux autres immédiatement (c'est un système en P2P).
Par contre groove, ne supporte pas le versionnage, mais Vista permet de revenir en arrière très très facilement (on peut ouvrir n'importe quel répertoire à une date antérieure comme si il existait toujours sur le disque dur).
Florent Clairambault - http://florent.clairambault.fr
Gtalk : superfc@gmail.com |