J'ai hésité un moment entre faire un journal ou un forum, mais je pense que ce sera mieux ici.
J'ai, depuis un moment, l'habitude de bosser avec des systèmes de version (cvs, snv) et j'en étais satisfait, y compris quand je suis seul sur un prog.
Mais je me retrouve pour le moment dans une impasse...
Je bosse pour le moment sur une assez grosse appli web, en fait on est 3 dessus.
Ils ont pour habitude de ne pas utiliser de système de gestion de version, ce que je ne trouve pas génial et qui a souvent tendance à rendre le code et les fichiers plus crade (comme on ne peut pas revenir en arrière, on supprime pas toujours le code, les fichiers et de nombreuses copies fleurissent un peu partout en sauvegarde "sauvage")
Je pensais installer svn mais je me heurte à un problème.
L'appli tourne sur un serveur de test, et on est donc amené à modifier les mêmes fichiers (ou en tout cas les fichiers de la même appli).
L'utilisation de svn reviendrait à avoir une copie locale des fihciers (normal), commiter les fichiers une fois modifiés (régler les conflits s'il faut)
Mais pour tester il faut alors copier les fichiers entre le repository et le serveur de test, ce que je trouve plutôt lourd. En fait, lourd dans le sens ou on est obligé de copier tout le temps et surtout le fait de ne pas pouvoir tester / debugger / corriger en direct sur le serveur
Une solution évidemment serait d'avoir (dans la copie locale en quelque sorte) l'appli, de la tester et ensuite propager les modifs.
Mais on est à un stade ou les modifs de l'un se répercutent sur le boulot des autres et donc tester sans avoir la version à jour tout le temps est très génant puisque double le débuggage (local + distant)
Avez-vous des astuces / retour d'expérience / logiciels / techniques qui pourraient faciliter la gestion de ce type de dev .
Journal Gestion de version pour applis web
20
avr.
2005
# Plusieurs applis
Posté par niol (site web personnel) . Évalué à 4.
Chaque fois que çà marche, chaque dével commit ses changements.
Il faut juste prendre l'habitude de se synchroniser régulièrement avec le dépot.
chezmoicamarche!
# idées
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
- chacun a son petit serveur web en local, avec son propre repertoire local de l'appli. Il test en local sans risquer de tout casser pour les autres developpeurs.
- Il y aurai un serveur qui fait serveur web de test global et repositorie svn
- une fois bien testé en local, on commit sur le serveur svn.
- là, je suppose que ça doit être comme dans cvs, il doit être possible d'éxecuter un script sur le serveur à chaque commit. Ce script serait chargé de copier le fichier commité sur le site de test global. (au pire, si cette mise à jour n'est pas possible comme cela, un cron fera bien l'affaire, mais c'est pas top)
Et voilà.
Donc on fait un update, on modifie, on test en local, on commit, on test sur le serveur global.
c'est pas parfait mais je pense que c'est déjà pas mal.
[^] # Re: idées
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
D'ailleurs, installer un gforge en interne dans ta boite, ça peut être sympa pour bien suivre les projets (système de suivi des bugs, organisation des taches, etc..)
[^] # Re: idées
Posté par CrEv (site web personnel) . Évalué à 1.
Les solutions présentées marchent en général pas mal (j'ai déjà bossé sur sourceforge, et sur qq projets et c'est vrai que ça marche bien)
Le problème en fait est au niveau de la synchro entre dev car on travail sur des parties séparées mais on doit assimiler le boulot des autres (en gros ce que je code dépend de ce que code les autres) et donc c'est pour ça qu'il faudrait pouvoir synchroniser tout le temps sur le serveur (mais le déboggage est moins simple) ou alors que chacun ait une version tout le temps synchronisée
Ha oui, j'oubliais un truc...
Le code qu'on fait n'est qu'une partie de l'appli au complet, et donc cette dernière solution n'est pas envisageable. En effet, le code est réparti sur 3 (ou plus) machines distantes, chacune s'occupant d'une partie mais toutes interagissant les unes avec les autres... ce qui donne une préférence pour un serveur de test et non test sur chaque machine...
L'idée d'installer GForge ou un équivalent s'il y en a est pas bête, j'essai aussi de les faire utiliser un bugtracker mais c'est pas gagné (mais ceci est une autre histoire :) )
[^] # Re: idées
Posté par niol (site web personnel) . Évalué à 2.
Pour GForge et le bugtracker, regarde du coté de trac...
( http://linuxfr.org/2004/04/21/16054.html(...) )
[^] # Re: idées
Posté par xumelc . Évalué à 3.
pour être synchronisé en permanence, la solution est sans doute d'éditer les fichiers directement sur le serveur distant, par exemple avec les kiosolaves ftp:// et fish:// (ssh) de KDE.
J'ai deja participé à un site internet (qui est rapidement décédé ^^) comme ça, et ça marche très bien, si deux personnes travaillent sur le même fichier on est prévenu, etc.
Tous les éditeurs de texte ou les IDE de KDE supportent ftp:// , fish://, enfin les kioslaves quoi :). Par exemple l'IDE Quanta+, qui est orienté web, gère des projets dont les fichiers sont distants, par ssh, ftp, nfs, webdav(sécurisé ou non), ...
P.S. : vous l'avez compris, je suis légerement pro-KDE ;-)
---
clemux
[^] # Re: idées
Posté par CrEv (site web personnel) . Évalué à 2.
Car le plus gros problème est là en fait. Si on est informé c'est bien mais ce n'est qu'un premier pas...
Mais il faudrait quand même que je regarde ça...
[^] # Re: idées
Posté par xumelc . Évalué à 1.
@+
--
clemux
[^] # Re: idées
Posté par golum . Évalué à 1.
Lorsque quelqu'un veut tester , il fait un update et un merge si necessaire.
Ensuite il fait pointer la racine du serveur web sur le montage qui lui correspond au moyen d'un lien symbolique.
Dans ma boîte on pratique comme ca (sauf qu'on utilse samba)
Tu as aussi la possiblité de décomposer ton serveur en 3 sous-répertoires
http:\\myserveur\dev1
http:\\myserveur\dev2
http:\\myserveur\dev3
(un par espace de travail) et chacun de ces sous-repertoires est en fait un lien symbolique sur chacun des espaces de travail.
Comme ca tout le monde peut tester en même temps et pour se tenir à jour il suffit d'updater régulièrement.
[^] # Re: idées
Posté par botio2 . Évalué à 1.
http://www.edgewall.com/trac/(...)
# Commit CVS
Posté par calvin2001 . Évalué à 1.
[^] # Re: Commit CVS
Posté par Benjamin (site web personnel) . Évalué à 3.
sur le serveur de dev (distant) chaque développeur a un compte AlternC (http://www.alternc.org)(...) à la racine duquel il y a une copie locale des modules du CVS.
Quand un développeur fait un commit dans un module, le commit fait AUSSI un "update" dans son dossier web à lui pour ce module là. Ainsi, il peut tout de suite voir ce que cela donne en live en ligne
Mais sinon, l'idée d'un serveur web local sur la machine sur laquelle chacun développe est pas mal aussi : cela permet de tester AVANT de faire le commit et donc de ne pas commiter qqchose qui casserait tout ...
[^] # Re: Commit CVS
Posté par CrEv (site web personnel) . Évalué à 2.
Le problème du test local c'est qu'il ne permet pas de tout tester puisque l'appli est dispersée sur 3 serveurs qui communiquent entre eux, et il devient peut envisageable que chaque dev ait une copie des trois en local (en plus certains prog spécifiques utilisés ne sont pas dispos / utils à tous)
En fait ce que je me rend compte c'est que pour des applis qui peuvent être testées en local, les scm sont très bien foutu et faciles à utiliser, mais quand plusieurs personnes travaillent simultanément sur le même projet distant (sur les mêmes fichiers quand il n'y a pas de scm, d'où le prob) ça devient moins évident et pour le moment je ne vois pas de solution "parfaite"
[^] # Re: Commit CVS
Posté par vieuxshell (site web personnel) . Évalué à 1.
Comme ca tout le monde travail dans la même vue et les modifs de chacun sont disponibles immédiatement aux autres développeurs.
Ceci dit, ca ressemble quand même au débarquement pour tuer une mouche.
# Utilisation partielle
Posté par Seazor . Évalué à 2.
1) historique des versions
2) réservation du fichier à une personne qui travaille en local.
si j'ai bien compris, le point 2 te gene.
Pour n'utiliser que le 1, il suffit que tout le monde fasse les check out au même endroit (un partage réseau par exemple).
p-ê même à l'endroit où tu travailles actuellement sur tes sources.
Conséquences : tout le monde travaille sur les dernières versions (même parfois les versions en chantier des autres, ce qui est moins bien mais si j'ai bien compris, c'est deja comme ca maintenant)
et les check in ne servent alors plus qu'à l'historique.
avec l'inconvénient final que la tentation est grande de le garder en check out indéfiniment. solutionné partiellement par un check in/out consécutif à chaque version "stable".
Pour tout ceci, n'importe quel gestionnaire devrait faire l'affaire...
[^] # Re: Utilisation partielle
Posté par CrEv (site web personnel) . Évalué à 2.
Je ne veux justement pas que ça ne serve que d'historique.
Le problème c'est qu'actuellement il y a le risque que deux personnes travaillent sur le même fichier et donc écrasent le boulot des autres. Et j'ai pas envie de passer mon temps à gueuler dans la pièce que je bosse sur tel ou tel fichier.
Et dans tous les cas, je trouve que c'est une manière crade de bosser quand il n'y a pas un minimum d'organisation au niveau des fichiers, de leurs modifs, de leur historique, ... (et pour le moment il y a seulement des sauvegardes de temps en temps...)
Ce qui me gène c'est la plupart des scm sont très bien quand on peut tester en local sont boulot un minimun avant de commiter surtout quand le travail est simultané.
Mais dans ce cas précis ce n'est pas possible de fait de l'archi spéciale qu'on a sur l'appli...
Mais bon, je m'oriente sur svn avec update automatique du serveur + intégration du scm dans l'éditeur (ou éditeur en fonction) pour que ce soit le plus transparant possible
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.