Journal Gestion de version pour applis web

Posté par (page perso) .
Tags : aucun
0
20
avr.
2005
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 .
  • # Plusieurs applis

    Posté par (page perso) . Évalué à 4.

    En fait, l'idéal pour moi, et si cela est possible pour toi, c'est que chaque développeur ait sa copie de l'application dans un répertoire du serveur de test pour développer.
    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 (page perso) . Évalué à 3.

    Je ferais comme ceci :

    - 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 (page perso) . Évalué à 2.

      en fait, je viens de me rendre compte : faut faire comme ce qu'on fait sur les projets opensource hebergé sur sourceforge, gna, devlibre &co :-)

      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 (page perso) . Évalué à 1.

        Je répond à tous ici...

        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 (page perso) . Évalué à 2.

          Pour la répartition de ton appli, c'est ce que je craignais, et je n'y vois pas de solution sauf des tests unitaires en local, et encore.

          Pour GForge et le bugtracker, regarde du coté de trac...
          ( http://linuxfr.org/2004/04/21/16054.html(...) )
        • [^] # Re: idées

          Posté par (page perso) . Évalué à 3.

          Bonsoir/bonjour,

          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 (page perso) . Évalué à 2.

            Le fait d'êter prévenu est pas trop mal. Par contre, est-ce que ça permet de résoudre les conflits ?
            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 (page perso) . Évalué à 1.

              Heu non je ne pense pas que ça règle les conflits, c'est la même chose que d'être à deux sur la même machine et d'editer le même fichier :).


              @+
              --
              clemux
        • [^] # Re: idées

          Posté par . Évalué à 1.

          Est-ce que vous n'avez pas la possibilité d'utiliser chacun un espace de travail dédié sur vos postes qui seraient montés via NFS sur le serveur

          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 . Évalué à 1.

        trac fait tres bien l'affaire avec subversion:
        http://www.edgewall.com/trac/(...)
  • # Commit CVS

    Posté par . Évalué à 1.

    Sinon il est possible de dire à CVS d'effecteur une action à chaque commit. Moi je l'utilise pour envoyer un mail aux développeurs avec les noms et versions des fichiers modifiés, mais tu peux aussi imaginer que cela copie ces fichiers quelque part...
    • [^] # Re: Commit CVS

      Posté par (page perso) . Évalué à 3.

      Par exemple, ce que je fais sur certains projets :

      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 (page perso) . Évalué à 2.

        Pour le moment c'est vers ce genre de solution que je pense me tourner (update lors du commit) car c'est celle qui est le moins contraignante, sauf pour les tests qui ne sont pas immédiats et le risque de casser tout...

        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 (page perso) . Évalué à 1.

          Si tu as les moyens tu peux utiliser ClearCase de Rational^W IBM.

          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 . Évalué à 2.

    Pour moi, cette catégorie de soft fait habituellement 2 choses distinctes :
    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 (page perso) . Évalué à 2.

      Le point 2 ne me gène pas.
      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.