Premier sujet de cette première partie, les DVCS. Ça sonne un peu comme un titre de Justice, mais ça veut dire Distributed Version Control System ou en français Gestionnaires de Configuration Logicielle Distribués.

Ces outils permettent de gérer plusieurs dépôts de code que l’on peut synchroniser avec d’autres dépôts en push (j’envoie mes mises à jour sur un dépôt distant) ou en pull (un dépôt distant vient chercher les mises à jour chez moi).

DVCS

Onon Palui, aussi connu sous le nom Sébastien Douche, nous a fait un retour d’expérience très enlevé sur sa vie avant les DVCS et avec les DVCS, supporté par une présentation très graphique à la typographie très travaillée.

Onon Palui, un expert Python, qui ne fait pas de Java mais vient régulièrement au JUG !

Petit sondage à main levée pour commencer : qui utilise SVN, CVS, ClearCase, Perforce ? On peut constater qu’une majorité de personnes dans la salle utilisent Subversion (SVN).

A son arrivée comme Technical Leader dans une startup SecurActive en 2007, Sébastien avait son kit de survie. Pour lui, la gestion de version du code source est le premier filet de sécurité. Les tests sont le second. Il transportait ses deux outils fondamentaux avec lui de société en société : Trac et Subversion.

Ils fabriquent un logiciel à partir d’une page blanche. On ne sait pas quelle direction prendre, on prend des culs de sac, fait beaucoup de refactoring, des POC.

En un an et demi Subversion est devenu synonyme de souffrance. Jusqu’au jour fatal où il a été impossible de faire une démo. Et là, Onon Palui s’est dit : ça ne peut pas continuer comme ça ! Pourquoi ?

Pourquoi tant de souffrance ?

Le processus classique d’un développeur c’est checkout – code – commit. Ce qu’il a constaté en observant les développeurs avec qui il travaillait c’est qu’il passaient beaucoup de temps dans des micro-merges.

Les développeurs font des commits très souvent pour livrer le moindre changement : une correction de faute d’orthographe, une modification mineure. Ces commits fréquents obligent les autres à prendre constamment en compte les modifications des autres sur des fonctions qui ne sont pas encore finalisées.

Il peut même se développer une course qui consiste à commiter le plus vite possible, avant les autres pour ne pas avoir à merger les modifications des autres dans son code. Et encore plus de commits, encore plus de merges …

Mais pourquoi ces micro-merges ?

Les développeurs livrent souvent pour historiser leur code et avoir un backup. Mais lorsqu’ils le font ils sont confrontés au merge. Plus il y a de changements à merger, plus c’est compliqué. Donc fragmenter et merger souvent permet de réduire la douleur.

Mais normalement les branches devraient permettre à chacun de travailler en isolation et en sécurité sur sa branche de code. Les branches seraient la solution ?

Qui fait des branches sur Subversion ? (Silence dans la salle). Personne ne fait de branches sur Subversion car les merges de branches SVN sont un cauchemar.

Donc pas de branches. Finalement Subversion est fait pour faire de l’historisation et pas de la gestion de configuration.

Trouver autre chose ?

Sébastien Douche: "Je ne suis pas un numéro !"

Sébastien est un coach Agile. Son objectif est de supprimer le passage développement – livraison pour avoir un environnement stable sur lequel on peut faire des démos tout le temps, et surtout faire des démos de fonctions en cours d’élaboration et pas encore intégrées.

La clé : l’isolation. Sébastien a donc commencé à étudier les DVCS. L’année clé a été 2005, l’année où Linus Torvald a créé Git.

Subversion reprend en les améliorant les principes de CVS qui date des années 80. Il faut changer de point de vue. Nettoyer le cerveau. Repenser les choses.

1ère notion a revoir : comment travaille-t-on ?

Un développeur est confronté à 3 workflows :

- un workflow organisationnel : la réalisation du produit dans sa globalité impose une gestion de repository qui peut se faire sur plusieurs modes : dépôt centralisé, existence de dépôts privés intégrés en pull par des intégrateurs dans le dépôt officiel, dépôts pyramidaux à la Linux, dépôts multiples resynchronisés sous contrôle pour les projets délocalisés.

- un workflow personnel : comment on travaille tout seul. Une branche par fct, par bug fix, par patch …

- un workflow inter-personnel : comment on travaille avec les développeurs autour de soi, échange par le dépôt central, échange de patch, cherry picking

Application concrète : le dépôt central n’autorise parfois pas les mises à jour. C’est le cas de la plupart des projets OpenSource où l’intégration des modifications se fait par échange de patch. Faute de pouvoir, faire un commit sur ces patchs, les développeurs doivent faire des copies de sauvegarde du code manuellement. Avec Git, les développeurs peuvent faire un commit sur leur dépôt local, même s’ils ne font pas un push de ces modifications vers le dépôt central.

2ième notion à revoir : la nature des objets manipulés

Les DVCS sont orienté contenu et non change set.

Les VCS (ou gestionnaire de configuration logicielle) classiques , sont orienté ChangeSet. Ils identifient des changements apportés à des fichiers. Lorsqu’un de ces fichiers a été modifié depuis le commit précédent, le VCS stocke un diff entre les deux états successifs du fichier. Il ne connait jamais vraiment l’état complet d’une version, il ne connait que des états successifs d’un fichier. Lorsque les noms changent, le VCS supprime un fichier et crée un autre fichier.

Les DVCS (ou gestionnaire de configuration logicielle distribués) identifient des contenus. Un contenu à une position dans l’arborescence, une nom et une empreinte (un checksum MD5 de son contenu). Au commit, le DVCS fait un snapshot de tous les fichiers de la version. Si le fichier n’a pas changé, la version pointera sur l’ancienne copie, si  le contenu du fichier a changé, la version pointera sur le nouveau contenu. Comme les noms sont dissociés des contenus, lorsque les noms changent, seuls les index sont modifiés.

Application concrète : le renommage massif. Il est très très lourd sous Subversion, car il implique la suppression et la création de nouveaux fichiers. Avec un DVCS, les fichiers changeront seulement de noms.

Quels bénéfices ?

Les DVCS permettent de gérer une branche par fonction développée. Pas de mélange des fonctions et donc un code plus stable. Il est également possible de faire des validations supplémentaires fonction par fonction (revue de code, démo)

Dans sa société, 1 – les développeurs se concentrent sur leur code 2 – flexibilité : ils choisissent les outils qu’ils veulent 3 – push par fonction 4 – revue de code systématique par fonction livrée 5 – phase de démo avant push par fonction livrée 6 – moins de stress ! 7 – projet beaucoup plus stable

Conclusion : SVN est une torture, Libérez vous ! Tentez Git

Dans le cas où votre infrastructure n’aurait pas l’esprit aussi ouvert que Sébastien Douche, Git permet des bindings vers Subversion pour avoir un workflow personnel en amont du workflow organisationnel.

Nicolas Martignole présente l'eXpress Board et le sponsoring du buffet pendant qu'Antonio aide David Gageot à équiper son micro

Sébastien Douche organise également Agile France 2010 le 31 mai et 1er juin.

Annonce du sponsoring du buffet par l’eXpress Board

Un petit speech de Nicolas Martignole (aka Le Touilleur Express) sur l’eXpress Board, le site d’annonce d’emploi qu’il vient de créer. Pour fêter son 10ième client, il nous offre le buffet. Il a aussi fait un compte rendu de la soirée qui se trouve là.

Mais avant, on enchaîne avec Git, il n’est que 20h !

Précédent : l’Avant JUG et la présentation W3CSuivant : la présentation Git

Les photos sont de José Paumard et Claude Falguière.