Comment faire du développement dans l'industrie avec SGVD ?

• [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

  Posté par gS () le 21/03/2008 à 18:28. (lien). Évalué à 3.

  Chez nous le passage de CVS s'est fait sans douleur. Nous étions habituée a avoir un serveur central, une branche de dev, des branches pour les releases avec des tags (beta, rc et stables).
  
  Bzr peut s'utiliser de cette façon, nous avons un repository central qui comme sous CVS, contient un cerrtain nombre de branches, tags, bref, c'est la référence. Au quotidien, les devs on des checkouts fait a partir du repo central et font un 'bind' sur ce dernier.
  Cela permet de faire des commits en meme temps sur sa branche locale et sur la base centrale.
  C'est le meme fonctionnement que CVS, tres simple.
  
  Si un dev travaille en déplacement ou qu'il n' a pas acces a la base centrale, il fait un unbind et bosse localement.
  Lorqu'il revient, il synchronise sa branche locale avec la base centrale, on reste en permanence synchronisé avec les autres via un bzr update (comme CVS), bref tres simple, et les conflits sont notifiés et doivent êtres résolus avant de commiter.
  Il arrive aussi que des devs sur des truc expérimentaux se détachent de la base centrale et ne se synchronisent qu'entre eux (un unbind pour se détacher et re-bind avec l'autre dev, c'est pratique).
  
  Bref, je ne sais pas trop si ca répond a ta question mais c'est un exemple d'utilisation qui fonctionne très bien en entreprise (ou le cycle de dev est rigoureux, on travaille dans le biomedical).

  [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

  Posté par Bozo le Clown () le 21/03/2008 à 22:37. (lien). Évalué à 3.

  Ce qui me semble difficile à implémenter c'est un cycle de développement avec des branches/streams de développement, d'intégration, de test, de release et de maintenance.
  
  Peux-tu préciser ta question ?
  Ce que tu souhaites c'est avoir si UCM peut être mis en oeuvre avec un DVCS ou savoir quel processus appliquer pour un projet ?

  [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

  Posté par Raphaël SurcouF (Jabber id, page perso, ) le 22/03/2008 à 00:37. (lien). Évalué à 3.

  Je ne suis certes pas, de curusu, un développeur mais j'ai du mal à saisir ce qui est tellement intéressant dans les SGVD par rapport aux SGVC, à plus forte raison pour une entreprise.
  Les cas exposés par « gS » sont extrèmement révélateurs de cas particuliers. Et, pour ces cas particuliers, il faudrait revoir la base (passer d'un SGVC à un SVGD) de toute l'artillerie habituellement déployée pour conduire des projets ?
  Pourtant, que ce soit avec giT ou bzr, on voit toujours revenir le principe d'un référentiel central qui, finalement, définit les sources officielles d'un projet. Les SGVD ne sont finalement que des outils facilitant les travaux dérivés ou encore trop expérimentaux pour être intégrés dans le référentiel central officiel.
  Est-ce que giT, bzr ou Hg apportent plus de conforts aux développeurs que CVS ? Assurément, mais il faudra bien publier un jour ce projet, de façon officielle. Et si j'ai volontairement omis SVN, c'est parce qu'il suffit d'utiliser SVK pour obtenir un SVGD à moindre coût (par rapport à une migration vers un autre outil). Maintenant, je n'ai peut-être pas l'expérience nécessaire pour savoir si c'est un mauvais choix ou non mais je ne vois pas de raisons manifestes pour motiver un tel changement.
  Par exemple : le suivi par « changeset », concrètement, ça donne quoi ? Quand est-ce un avantage par rapport à un suivi par fichier ? N'est-ce pas là une application logicielle d'une méthode de travail qu'on pourrait très bien appliquer sous SVN ?

  • [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

    Posté par Antoine () le 22/03/2008 à 00:58. (lien). Évalué à 1.

    Par exemple : le suivi par « changeset », concrètement, ça donne quoi ? Quand est-ce un avantage par rapport à un suivi par fichier ? N'est-ce pas là une application logicielle d'une méthode de travail qu'on pourrait très bien appliquer sous SVN ?
    
    SVN fonctionne déjà par « changeset » sauf que le terme utilisé est révision.

    • [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

      Posté par Raphaël SurcouF (Jabber id, page perso, ) le 22/03/2008 à 13:19. (lien). Évalué à 2.

      C'est bien ce qu'il me semblait, parce qu'il m'arrive souvent de faire un commit pour plusieurs fichiers, qui auront tous la même révision. Il est alors facile de retrouver les fichiers modifiés par cette révision.

    [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

    Posté par Xavier Verne (page perso, ) le 22/03/2008 à 10:56. (lien). Évalué à 2.

    
    Pourtant, que ce soit avec giT ou bzr, on voit toujours revenir le principe d'un référentiel central qui, finalement, définit les sources officielles d'un projet.
    
    
    Il me semble qu'il y a deux notions mélangées : d'une part le fait qu'un projet finit par livrer une unique version à ses utilisateurs (firefox 3.0, ou bzr 1.3, etc.). Ce sont effectivement, in fine, les sources officielles du projet.
    
    D'autre part, et c'est très différent, les modalités pour y parvenir. A ce titre, un système décentralisé peut apporter beaucoup plus de flexibilité : tests de nouvelles fonctionnalités dans une branche à part, plus de souplesse sur les modes connectés/déconnectés, et donc sur l'organisation des équipes de développeurs (extreme programming ou autre). Toutes ces choses sont possibles, mais plus difficiles à mettre en oeuvre, il me semble, via SVN et consort.
    
    Après, clairement, dans une organisation projet informatique "traditionnelle", les développeurs ne sont pas loin géographiquement les uns des autres, le "chef de projet" est pas loin pour décider de comment faire les choses, les développeurs travaillent sur des parties assez différentes ce qui peut faciliter les "merge" sans conflit....
    
    C'est la différence entre interface/implémentation. Le résultat c'est l'interface que tu proposes, l'API, l'implémentation c'est la manière.

    • [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

      Posté par zul (Jabber id, page perso, ) le 22/03/2008 à 12:13. (lien). Évalué à 4.

      Je pense que Linus dans son speech pour Google a aussi cité pas mal de cas intéressant.
      
      Je reprends quelques points :
      - dans la majorité des entreprises, avant de commiter des choses dans le dépôt central, il faut passer un tas de tests de non-regression (ce qui est long et chiant). L'effet pervers de la chose dans un système centralisé, c'est que les gens tendent à commiter d'enormes changeset à chaque fois, et pas forcement des trucs atomiques. dans un système décentralisé, tu continue de faire tes commits atomiques dans ta branche locale, et quand tu veux pusher tes changements dans le dépôt central, tu passe les tests de non-regression ( et git-bissect t'aide à retrouver pourquoi ca foire, soit dit au passage)).
      
      - si deux développeurs travaillent sur une partie de code commun, tu peux soit créer une branche sur le dépot central (avec les problèmes que ca a, dans le namespace commun, et puis la facilité de merger des branches dans cvs/svn, n'en parlons pas), soit ils travaillent sur une branche local, et se pull/push les patchs
      
      enfin je laisse linus faire sa pub, il est plus percutant et drole que moi.
      
      Quand au confort d'utiliser git par rapport à cvs/svn, c'est sans commune mesure. Les opérations communes sont bien plus rapides et donc transparentes (opération de diff, opération de commit (vu que c'est local), visionnage de l'historique, merge de branches, tag, ...)

    [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

    Posté par gS () le 25/03/2008 à 08:54. (lien). Évalué à 1.

    Le suivi par changeset nous facilite grandement la vie. Par exemple, en ce moment, nous finalisons une version de l'un de nos softs dans une branche. L'equipe QA nous envoie des bug reports. Nous corrigeons chacun de ces bugs et donc nous 'commitons' :) un patch, ou 'changeset' de quelques fichiers.
    Par exemple dans la branche beta, le patch 7300 corrige le bug 120 et le changeset concerne 5 fichiers.
    Il est tres simple dans la branche pricipale, de demander a bzr d'appliquer juste ce patch, sans tous les précédents, ou d'appliquer une liste de patch qui modifie des fichiers qui n'ont pas trop divergés , ce qui représente la majorité des cas sur une appli de la taille de la notre (sinon, de toute façon, il faut résoudre les conflits).
    Cette operation se nomme 'cherrypicking' dans le vocabulaire des systemes de gestion de version distribués et représente un progrès dans notre façon de gérer nos sources et nos versions.
    
    a++
    Guillaume.

    • [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

      Posté par imalip (page perso, ) le 25/03/2008 à 10:12. (lien). Évalué à 7.

      Tu vas rire, hein, mais je fais exactement la meme chose avec subversion au boulot. Les changeset et le cherrypicking n'ont rien de spécifique aux systemes distribués.

      --
      "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

      • [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

        Posté par Raphaël SurcouF (Jabber id, page perso, ) le 25/03/2008 à 13:59. (lien). Évalué à 2.

        Je suis en effet d'accord avec ce constat : le cherry picking n'a rien de spécifique ni à bzr ni aux autres DCVS. Quant aux changeset, les révisions de SVN semblent répondre à peu de choses au même besoin.

        [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

        Posté par gS () le 26/03/2008 à 10:11. (lien). Évalué à 1.

        Nous sommes d'accord. Je tente juste une explication sur la difference entre les changesets et le systeme de revisions par fichiers.
        C'est quelque chose qui peut dérouter au début et c'est une notion fondamentale.
        Je n'affirme a aucun moment que seuls les systemes distribuée en sont dotés. Je ne mentionne meme pas SVN.
        Je ne saisis pas pourquoi je devrais rire de mon explication.
        
        a++
        Guillaume.

        • [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

          Posté par Raphaël SurcouF (Jabber id, page perso, ) le 27/03/2008 à 11:47. (lien). Évalué à 2.

          Tu ne mentionnes pas SVN mais la question qui était posée et à laquelle tu réponds le mentionnait. En outre, la dernière phrase laisse penser que le « cherry picking » est l'apanage des systèmes distribués de gestions de versions alors que ce n'est pas le cas. Ensuite, entre changeset et revision, il n'y a globalement qu'une différence de noms.

          • [^]Re: Comment faire du développement dans l'industrie avec SGVD ?

            Posté par gS () le 28/03/2008 à 09:07. (lien). Évalué à 2.

            Je parle de systeme de révision *par fichier*, du type de celui présent dans CVS (il y a peut être un terme plus consacré), que nous utilisons également pour notre systeme qualité (ou chaque document est indépendant et dispose de son propre numéro de version, indépendament des autres, parfait pour la doc reglementaire).
            
            Je conviens que ma dernière phrase pourrait être équivoque, ce n'était pas mon intention. J'essayais juste de fournir une explication qui m'aurait été utile quand je suis passé de CVS à un aute systeme.
            Je ne comprends toujours pas pour quoi ca prête à rire.
            
            a++
            Guillaume.