La prochaine frontière ? l’ALM

Dans mon message sur le dépôt de bilan, je parlais de

Un truc tout con : pour faire de l’agile, utiliser cinq outils, c’est juste idiot. je vais préciser un peu : on utilise Scrumwise pour le backlog, Google Drive pour les specs, Mantis pour les bugs, Google Spreadsheet pour donner d ela visibilité aux bugfixes …

Je dois dire que ça m’a pas mal travaillé récement. Ca m’a d’autant plus travaillé qu’en raison des contraintes externes, on nous demande ces temps-ci beaucoup de reporting concernant les corrections de bugs (un secteur du développement sur lequel il faudrait aussi que j’écrive quelque chose). Un reporting qui, naturellement, prend la forme d’un tableau Google Drive (parce que quand ton seul outil est un marteau, tous les problèmes finissent par ressembler à des clous).

J’en parlais parce qu’une nouvelle sur LinuxFr m’a récement intrigué  :  La forge libre Tuleap gagne le prix américain InfoWorld Bossie Award 2013. Ca m’avait intrigué parce que, avec Sourceforge, Origo, gitHub, on peut dire que j’ai un peu vadrouillé du côté des forges, et que si certaines fonctionnalités sont sympathiques, ça ne va pas souvent bien loin …

Enfin, pas loin, pas loin, je dois bien reconnaître que GitHub Issues est une sacrément bon sang de bonne idée. Et c’est sans doute à cause de cette bonne idée que je trouve Tuleap aussi bien : parce qu’il pousse cette diée de tracabilité du code bien plus loin. C’est expliqué dans leur doc : on peut lier une user story à un bug report, lui-même lié à un commit (et éventuellement fermé depuis le commit) et à un build du Jenkins embarqué. Et là, comme dans GitHub, il semble possible de fermer (ou tout au moins de référencer) un item dans le commit pour que tous soient liés.

Et à mon avis, c’est ça la prochaine frontière du développement.

Je m’explique.

Vous développiez comment il y a dix ans ?

Moi, je faisais du java dans mon Textpad avec un script Ant qui tentait de faire (mal) des tests. (Bon déja c’était bien j’utilisais Ant pour compiler).

Et puis JUnit est apparu pour mieux qualifier la qualité de mon code.

Et puis Hudson/Jenkins est apparu pour mieux s’assurer de la qualité de tout le code qui pouvait dépendre du mien … et pour faire tout un tas d’autre trucs.

Mais, d’un point de vue traçabilité, il manquait quand même des choses : comment savoir d’où venait – fonctionnellement – telle ou telle ligne de code ?

Rien.

Aujourd’hui, avec Git, on peut un peu plus facilement retracer une ligne de code jusqu’à un commit et – dans GitHub uniquement – à un issue qui a pu être écrit à ce sujet. Mais il manque l’aspect fonctionnel : quel est le besoin utilisateur qui a mené à ce code ?

Et c’est ça à mona vis que peut amener Tuleap : aller de la spec au code en un coup, et d’une façon qui documente clairement le process.

Bon, il y a évidement d’autres avantages, mais celui-là me paraît structurant pour une entreprise.

Oh, j’allais oublier la cerise sur le gateau : il y a un connecteur Mylyn pour que le développeur aie connaissance d’autant d’informations que possible dans son Eclipse !

Autrement dit, j’ai hâte d’essayer cet outil.

 

 

Publicités

Un peu de DevOps à la maison …

A cause de cette histoire de Google Reader, j’installe de plus en plus de petits scripts PHP sur mon serveur (et j’envisage même d’installer … d’autres choses). Et forcément, il y a de l’admin à faire. Comme je n’aime pas ça, j’essaye de faire les choses d’une façon qui m’intéresse … Comme par exemple en faisant du DevOps … Et pour ça, j’ai commencé par me créer un repository GitHub avec les fichiers de configuration des différents programmes que j’utilise (sauf les clés SSH et les fichiers de mot de passe utilisés par le serveur web – à peu près pas fou).

Bon, le plus grand intérêt, c’est quand même de pouvoir utiliser le bugtracker de GitHub pour mieux gérer le bazar … et ce sera par ailleurs une excellente occasion d’essayer Huboard !

Au début, je voulais utiliser un système genre todo.txt synchronisé avec Dropbox mais … je trouve la possibilité de fermer un bug depuis un commit git vraiment géniale. En fait, j’aurais bien aimé pouvoir me connecter au truc via Jabber (qui reste ma technologie inutilisée préférée), malheureusement je n’ai rien trouvé de bien génial. Tiens, par exemple, IFTTT a bien un channel Google Talk, mais je suis extrêmement déçu par la pauvreté du truc à chaque fois que je le regarde. Bon, et la concurrence principale a l’inconvénient majeur pour moi d’être orientée entreprise (et donc massivement payante).

Bon, d’un autre côté (et ça me fera bien plus de boulot) il semble possible d’écrire des bots Jabber en PHP … Mmmh

J’ai quand même du mal avec Git

Parce que bon, github, c’est vraiment un truc bien pensé, mais je comprend même pas comment ils ont pu construire un buisness aussi florissant sur une technologie aussi poussiéreusement foireuse. Un exemple ? J’ai passé deux heures à pester, mais alors vraiment pester, du genre #git, c'est quand même un bordel de SCM qui te […]

Finalement, Github, c’est vraiment bien

Dans mes souvenirs, j’étais assez critique face à Git/GitHub …Seulement, il s’avère que c’est faux, et que mon dernier message à ce sujet était plutôt gentil. Et heureusement, parce que GitHub avec les clients Git des IDEs modernes est assez facilement utilisable. Aussi bien dans Eclipse avec EGit que dans NetBeans (par défaut !), on peut raisonnablement puller,pusher …Et c’est tant mieux, parce que je m’en sers de plus en plus sur deux projets plutôt pas mal :

  • gaedo … eh oui, gaedo a dû quitter Origo, qui s’est éteint brutalement en mai dernier … il a donc trouvé chez GitHub (qui me permet au moins d’avoir toujours le repository complet sur ma machine).
  • agorava-stackoverflow que j’ai créé aprés avoir écouté Antoine Sabot-Durand se faire interviewer chez les castcodeurs, et qui me permet de relancer, sous une forme différente mais que j’espére bien meilleure, ce fameux projet d’aspirateur de site. (et qui en bonus me permet de faire à la fois du GitHub, mais aussi du Weld /CDI ).

D’ailleurs, j’ai découvert grâce à GitHub deux ou trois choses bien sympatoches. Par exemple, je fais maintenant mes sites maven en Markdown, pour pouvoir utiliser les pages dans le site généré (grâce à doxia-module-markdown), dans le site sur GitHub (grâce au rendu Markdown de GitHub et grâce à GitHubpages , qui utilise pour mes projets les mêmes fichiers). Mais la grande force de GitHub, malgré son côté spartiate,c’est GitHub issues , qui intégre complétement le bug reporting au développement. Tenez, regardez comment j’ai fermé le bug #11 de gaedo ! Un simple commentaire dans le commit, et pouf, le bug est fermé. C’est un rêve tellement c’est pratique … Un rêve difficilement atteignableavec SVN (même en utilisant Mylyn , puisqu’il faut ajouter les webservices SOAP à mantis, ce qui n’est pas toujours possible). Et je vous parle même pas de la facilité avec laquelle on intégre les modifications des autres grâce aux pull requests. Autant le dire, je commence à étre convaincu par Git, grâce essentiellement à GitHub et aux plugins des IDE (aussi bien NetBeansqu’Eclipse) qui font de Git un DVCS aussi pratique que SVN (voir même encore plus pratique grâce à la gestion intégrée des issues).

Fork me I’m famous !

J'entends régulièrement parler de Git/GitHub/Mercurial/toussa depuis maintenant environ quatre ou cinq ans.
Depuis toutes ces années, j'en retiens une impression de complexité, sans doute dûe à des à-prioris antérieurs. Cela dit, ces derniers temps, ça a changé.
D'abord, grâce à EGit, le plugin pour Eclipse. Parce que je ne sais pas si vous savez, mais moi, je suis PC, et Eclipse, c'est mon idée … Mais qu'est-ce que je raconte, moi ? Bon, il se trouve en fait plutôt que j'utilise Eclipse depuis … environ … 9 ans. Et depuis toutes ces années, s'il a bien une fonctionnalité qui fait la différence, c'est sa gestion du travail en Eclipse … pardon, en équipe (c'est le soir, j'en ai marre). Tiens, par exemple, vous saviez, vous, qu'Eclipse est sans doute l'un des meilleurs clients Subversion (comble du luxe, en fait, c'est un double client Subversion basé sur deux librairies bas-niveau totalement interchangeables – et si vous voulez tout savoir, j'ai du écrire un bon paquet de code avec SVNKit, et même si c'est assez curieux, ça fonctionne finalement très bien) ? Tout ça pour dire quoi ? Eh bien simplement que EGit est au niveau de Subclipse. C'est un plugin qui s'intègre très bien dans Eclipse et permet de faire la plupart des opérations sans y penser : pas de problème pour faire des push/pull, pas non plus de soucis pour créer des branches, commiter, … Bref, EGit, c'est l'anti-ligne de commande et ça c'est bien !
Seulement, avoir le client, c'est bien, il faut aussi avoir le projet sur lequel travailler … Et il se trouve que, récemment, j'ai dû utiliser plusieurs projets hébergés sur GitHub pour lesquels existaient certains bugs qui m'affectaient particulièrement et qui étaient assez faciles à corriger.
Prenant donc mon meilleur clavier, j'ai entré un bug dans le bugtracker de l'un de ces projets, forké la branche master sur mon compte GitHub, récupéré cette branche sur ma machine, implémenté la feature, commité, pushé, fait la pull request … (dit comme ça, c'est long, et je dois dire que j'ai été impressionné … pas par la complexité, mais par le fait que, justement, avec EGit, c'est aussi facile que du Subversion). Et voilà ! Mon commit a été intégré !
Bon, je sais, pour vous, tout ça, c'est rien. Mais pour moi le monde de Git et de GitHub est longtemps resté très mystérieux. Avec cette expérience, les choses se clarifient notoirement. Et d'autres bugs vont bientôt être corrigés !

Le retour de l’aggrégateur auto-hébergé ?

Il y a peu, j’ai installé dropbox.
Et je dois dire que c’est un logiciel absolument épatant si on veut garder quelques fichiers à portée de main sans même s’embêter à trimballer une clé USB. D’ailleurs, j’ai quelques fichiers critiques qui sont hébergés dans mon dossier dropbox pour être disponibles partout où je vais.
Donc, j’en ai était content.
J’en étais encore plus content quand j’ai commencé à bosser sur une idée que j’avais en tête. Parce que dropbox, avec ses fonctionnalités de partage de fichier, permet le développement quelquesoit la machine sur laquelle on se trouve.
Et puis, ce matin, mon Google Reader m’a sorti, depuis Ruby Inside, un lien vers un framework de génération de site statique : Jekyll. Ce qui m’a aussitôt fait penser à webgen et à mes précédentes tentatives d’aggrégation locale de mes messages sur la toile. Du coup, quand j’aurais le temps, je crois que je jouerais à nouveau un peu avec Ruby (ou peut-être Groovy, tiens) pour récupérer toutes les pages web que j’ai écrites en dehors de mon site. Ca sera marrant (ou pas), et ça me permettra peut-être de mettre à jour ma opage chez free d’une façon enfin propre.