La fin du bricolage
Par Mathieu Nebra le dimanche 3 mai 2009, 13h56 - Technique - Lien permanent
Un mois s'est écoulé depuis le précédent billet. Ce silence s'explique avant tout pour 2 raisons :
- La sortie du nouveau design New Wave, qui, comme toute mise en production qui se respecte, a demandé de nombreuses petites corrections de bugs dans les semaines qui ont suivi. On n'a pas fini, il reste toujours des choses à faire, mais au moins ça s'est calmé de ce côté-ci.
- L'arrivée de 2 stagiaires, Willy et Nicolas, qui travaillent sur le développement du site : améliorations et corrections de bugs. Ils seront rejoint dès demain par Mathias, ce qui fait que nous serons 4 au bureau pendant les 2 mois à venir. J'aurai l'occasion de parler plus en détail de ce qu'on fait et de ce en quoi consiste mon / leur travail.
Des développeurs
Aussi étonnant que cela puisse paraître, le Site du Zéro a vu son trafic grossir ces dernières années, mais pas son nombre de développeurs. A temps plein, pour s'occuper du code, il y avait en moyenne entre 0 et 1 développeur, selon les jours. Or, on ne peut pas croire qu'un site comme celui-ci se suffit à lui-même : il y a tous les jours des problèmes différents à régler, de nouvelles fonctionnalités et des améliorations à effectuer que nous aimerions faire depuis un moment.
Pour le SdZ, je ne pense pas qu'il soit non plus nécessaire de lever une armée de développeurs. Mais il est clair que n'avoir personne, ou presque, pour s'en occuper est inadéquat. A l'heure actuelle, je pense qu'entre 2 et 3 développeurs (à temps plein) conviennent. C'est de toute façon difficile actuellement pour moi d'en manager plus que ça.
Des rapports de bugs
Où je veux en venir ? Quel rapport avec le titre "La fin du bricolage" ?
Justement, si j'estime que l'on faisait du "bricolage" avant, c'est précisément parce que n'avions pas vraiment évolué depuis les tous débuts de la version 3 du site. Un serveur de développement, un serveur de production. On teste les fonctionnalités sur la "copie" du site en développement, et dès que c'est bon on passe en production en copiant les fichiers.
Globalement, ça, c'est le B.A.-BA. Mais ce n'était plus suffisant. Nous avions toujours une gestion anarchique des rapports de bugs et des améliorations. Aujourd'hui, nous utilisons comme je l'ai déjà mentionné un bug tracker qui nous permet de mieux suivre ce qui se passe, de gérer les priorités et de savoir "qui est en train de faire quoi". Ca peut paraître bête, mais parfois on ne savait pas toujours bien ce qui était en train d'être développé sur le site. Aujourd'hui heureusement, on a une meilleure visibilité.
Concernant le développement, il a été ces dernières semaines décentralisé. Nous avons certes gardé le serveur de développement, mais nous travaillons avant tout en local.
Des branches
Enfin, et c'est ce qui m'a occupé ces 2 dernières semaines (et qui m'a rendu quasiment invisible) : nous avons changé de logiciel de versionnement. Nous sommes passés de SVN à GIT. Autant dire que le passage s'est un peu fait dans la douleur, tant ces outils (qui ont pourtant le même but en théorie) s'utilisent différemment. Il a fallu nous réhabituer et nous défaire de certaines habitudes.

Git est, en quelques mots pour ceux qui ne connaissent pas, un système qui nous permet de garder une version de chaque fichier. Chaque modification est enregistrée, et si on veut retrouver le fichier tel qu'il était il y a 6 mois, on peut. On peut savoir qui a modifié le fichier quand, et pour quelle raison. On peut savoir quelles lignes il a ajoutés ou retirées. SVN fait pareil. La différence essentielle à nos yeux qui a justifié la transition, c'est que Git gère les branches de manière beaucoup plus fine.
Une branche est une évolution en parallèle du code source du site. C'est un moyen de tester de nouvelles fonctionnalités, de nouvelles idées, sans risquer de casser la branche principale "qui marche". C'est seulement une fois que la branche est stable que l'on décide de la fusionner avec la branche principale.
Regardez par exemple l'image ci-contre. Elle se lit de bas en haut et représente l'évolution du code. Chaque point est un état à un moment donné du site. La ligne tout à gauche représente la branche principale. C'est le site dit stable, celui que vous voyez quand vous visitez le SdZ. Parfois, on fait dériver en parallèle le site pour tester d'autres fonctionnalités dont on n'est pas sûr du temps qu'elles peuvent prendre à être réalisées : ce sont les branches. Le site évolue en parallèle et, au bout d'un moment, cette évolution est fusionnée avec la branche principale car on la considère utilisable. C'est alors que vous voyez ces changements en production, sur le SdZ.
Il y aurait beaucoup à dire sur Git, le fait notamment qu'il soit décentralisé et ne nécessite pas de serveur. Ou le fait qu'il se soit révélé extrêmement rapide. Ou encore le fait que ce soit un outil vraiment tourné vers les utilisateurs Unix et, bien que ça fonctionne, ce n'est pas encore vraiment la joie sous Windows. Ca reste un outil délicat, très délicat à manipuler. Comme tout bon programme sous Unix, ça fait ce qu'on lui dit, même si on lui dit de faire n'importe quoi. On l'a découvert à nos dépens.
Git a été conçu notamment par Linus Torvalds et est utilisé pour le développement du Kernel de Linux. Pour le moment, ce n'est quand même pas un outil grand public car il expose aux utilisateurs des concepts relativement avancés. En clair, je n'en recommande pas l'usage pour un débutant, mais si votre équipe est constituée de bons développeurs qui ont l'habitude d'utiliser des commandes Unix, alors vous finirez par beaucoup y gagner.
Du temps libre, peut-être ?
Il y avait un temps où on ne savait pas qui faisait quoi, où on ne savait pas où en étaient les résolutions de bugs, où deux personnes pouvaient difficilement travailler en même temps, où il était difficile de tester une nouvelle idée sans risquer de la mettre en production par inadvertance. Ca, c'est ce que j'appelle le bricolage.
L'évolution en interne a été un peu dure, mais elle était nécessaire. Il valait mieux le faire maintenant que de traîner de toute façon.
Paradoxalement, ça m'a mangé à peu près tout mon temps depuis 2-3 semaines. J'espère commencer à pouvoir respirer un peu et pouvoir à nouveau m'occuper du coeur du site : son contenu. J'ai commencé la rédaction du prochain chapitre Linux et j'ai commencé à effectuer des corrections globales - mais ennuyeuses - sur le tutoriel de C. Rien de tout cela n'est encore visible, mais ça ne saurait tarder.

Commentaires
La complexité de Git fait quand même que j'ai encore du mal à le conseiller aux développeurs venant de SVN (ou même CVS, ça existe encore, sisi). Du coup, je suis plutôt axé Mercurial, c'est un DVCS lui aussi très simple à utiliser et pas forcèment plus limité. Pas mal de docs sur les différences entre les DVCS ont été faites par des projets libres qui hésitaient, on peut noter par exemple la PEP 374 de Python (http://python.org/dev/peps/pep-0374...) ou l'analyse des DVCS de Google Code (http://code.google.com/p/support/wi...). J'aimerais bien avoir ton avis sur les trucs les plus durs à manier sur des DVCS comme Git par rapport à des VCS centralisés comme SVN, ça pourrait être intéressant :) . Également, Git fonctionne t-il mieux sous Windows qu'avant ? Je sais que le mauvais support de Windows avait été un élément bloquant pour certains projets, qui ont donc préféré passer à Mercurial (Tremfusion par exemple).
À part ça, tu dis qu'avec toi et les trois autres stagiaires vous serez 4 au bureau, mais où est donc passé Kara ?
Bonne chance vieux ;)
Bon courage à vous !
En fait Mercurial est aussi complexe en interne que Git, mais il masque en partie cette complexité à l'utilisateur.
Git est supporté sous Windows avec msysgit, qui marche pas mal, mais honnêtement y'a encore du chemin à faire. On peut installer tortoise git aussi, qui a besoin de msysgit pour fonctionner néanmoins.
Kara est en stage à Lyon, il me semblait qu'il l'avait déjà dit lui-même dans un précédent billet. Il finit ses études fin juin / début juillet.
Bon couraaaaaaage !!
Bon courage !!!
Et la refonte de l'organisation de la partie "Cours", c'est dans les futurs projets ? :)
Bonjour à toute l'équipe,
ça fait plaisir d'avoir des nouvelles comme cela et de voir que la révolution entamée lors de mon stage continue.
Je vois que les grands esprits se rencontrent puisque nous avons nous aussi choisi Git et Redmine dans notre boite a peu prêt en même temps que vous mais dans le sens inverse.
C'est peut-être dommage de laisser mercurial sur le côté Delroth, mais git a tout pour lui. Codé par Linus Torvald comme un système de fichier, impressionnant de rapidité, ... et le fait qu'il soit utilisé pour gérer les sources du kernel est un gage de qualité plus qu'important.
Je ne dis pas que Mercurial n'est pas rapide ou autre, car je ne l'ai utilisé que pour pygments et pas en tant que contribueur.
Il serait intéressant que vous publiez la documentation interne, en wiki, sur l'utilisation de Git car elle doit être assez similaire selon les projets et ça ferait gagné du temps.
ça m'intéresserait aussi que vous mettiez en ligne les roadmaps des objectifs de chaque stagiaire.
Bonne continuation à vous tous.
Natim
Je compatis, pour git, on est également en train de le mettre en place de notre côté, et ça se fait également dans la douleur... :D
Mais bon, on ne désespère pas, on va y arriver! ^^
En fait, je n'ai pas fait de documentation (même en interne) pour git. Si je l'avais fait, j'en aurais évidemment fait profiter tout le monde, que ce soit en créant un topic plus ou moins bien présenté, ou en l'adaptant en tuto (difficile) pour tous les motivés qui passeraient par là. Pour l'instant, je n'ai pas eu le temps.
@Natim, en vrai Mercurial est aussi rapide que Git si tu regardes les tests qui ont été faits par Google (j'ai filé le lien plus haut), et il est utilisé sur tous les projets de la MoFo, ce qui fait en soit une codebase probablement plus grande que le kernel Linux :) . D'ailleurs en HTTP Git est particulièrement lent d'au moins un facteur 10 (tiens, j'offre un mars à celui qui me trouve comment exprimer « an order of magnitude » en français).
@Mathieu, Mercurial cache bien entendu les choses difficiles derrière une couche d'abstraction supplémentaire, et c'est ce qu'on appelle dans le langage courant « simplifier les choses ». De toute façon, vu la similarité des structures interne de Git et Mercurial, ils sont presque identiques (ou du moins asymptotiquement) au niveau des fonctionnalités.
Le seul vrai avantage de Git que je vois est le fait que tout soit builtin (pas besoin d'extensions comme pour Mercurial, des trucs comme shelve sont par défaut), et sa gestion des branches locales qui est vachement cool (mais encore une fois utilisable avec Mercurial via une extension :P ).
Git est plus en plus plébiscité, mais pour un petit projet (pas le SdZ ;) ), je trouve SVN largement suffisant.
Pour Git, si tu pouvais indiquer quelques bons liens que tu as utilisé ca serait vraiment pratique pour permettre à tous de savoir par où commencer pour essayer Git.
Même à 5 développeurs, c'est relativement peu par rapport à de gros sites. Mais c'est vrai qu'à 2 ca devait être très dur de gérer.
Pour git je me suis basé sur la doc et les tutos sur le site officiel (notamment SVN Crash Course) : http://www.git-scm.com
J'espère que le troisième stagiaire est ausi déjanté que les deux autres, c'est qu'on s'amuse bien sur la dev ! :P
Bon courage aux 3 stagiaires (n'oubliez pas de prendre des gillets, il fait un poil humide dans la cave) et à toi Mathieu, le tout c'est de savoir doser son travail pour éviter de s'en lasser (et l'envie peut revenir des mois après seulement, malheureusement ><).
J'espere que ça améliorera votre productivité :-)
J'aimerai bien voir à quoi ressemble la doc interne (si elle existe un jour ;)), sur le fonctionnement interne, la gestion des branches, etc.
Je comprend le principe des branches, mais j'ai du mal à visualiser comment le mettre en application à un projet comme le SDZ.
Une technologie très intéressante !!
Plus qu'a attendre un super tuto pour tous les unix user :)
c'est une bonne suite, un bon décrochage en même temps
en tant que débutant je me pose seulement une question:
où peut-on apprendre le postgresql
où peut-on apprendre à gérér son site comme vous le faites?
o_O :-°