Utilisons github de manière plus propre

Bonjour,

ZdS est un gros projet aujourd'hui, vraiment trop gros, et force est de constater que nos outils de travail sont des outils de mauvaise qualités. J'ouvre ce topic afin qu'on essaye de trouver des outils adéquats (sans non plus sortir la grosse armada) pour un projet tel que ZdS.

La situation aujourd'hui

Les problèmes qu'ont a avec GitHub

La Gestion des tags

A l'heure ou j'écris ces lignes nous avons au sein du projets les 15 tags suivants : Bug, Back, Bloquant, Difficile, Documentation, Encours, Évolution, Facile, Front, Infra, Markdown, Pages Statiques, Questions, Régression, Validation.

Ces tags posent tout un tas de problème.

Personne ne sait, et personne n'a le même discours concernant la signification des tags. Ce n'est documenté nul part, ce qui fait que tout le monde colle des tags presque au doigt mouillé, et donc les tags sont inexploitable.

Les tags peuvent être regroupés ainsi : - Difficulté : Facile, Difficile - Nature : Documentation, Infra, Front, Back, Pages Statiques - Type : Bug, Évolution, Régression - Priorité : Bloquant - État : Encours, Validation

On arrive ici à la limite d'un outil de ticketing comme GitHub. Car on mélange dans les tags, la gestion du workflow, la gestion du projet et ses priorités, et l'attribution des taches. Il est donc impossible d'avoir une gestion des priorité plus fine que "bloquant ou non" par exemple.

Les issues

On n'a aucun moyen d'assurer le suivi d'une issue. Zds a un workflow qui fait que quand une issue est corrigée elle n'est pas tout de suite poussée en production. Or aujourd'hui les issues sont fermées quand le la pull request est mergée dans la branche de développement, et après ça, impossible de savoir ou en est l'issue en question, on en arrive à des trucs mystérieux comme ici.

On a un workflow et le cycle de vie des issues doit coller au plus près à notre workflow. Si on tente de le faire avec GitHub, on va juste finir par avant un nombre incalculable de tags qui serait contre-productif.

Les Milestones

Déjà, là aussi je ne suis pas sur que ma définition des milestones colle avec celle des autres dans le projet, mais aujourd'hui on les utilisent surtout pour regrouper les issues dans des versions. Sauf qu'elles tournent à deux vitesses. On a les Milestone "Version 1.x" et les Milestones "Futurs proches", "Futur lointain".

On utilise donc les Milestones en mode scotch pour palier au problème de fin de workflow vu qu'on range les issues dans une Milestone quand l'issue est fermée. On arrive donc pas à exploiter au final nos milestones.

La gestion des utilisateurs est très limitée

Aujourd'hui, un utilisateur qui ne fait pas parti de l'organisation github ne peut pas être assigné à un issue. On se retrouve donc avec tout un tas d'issue déjà prises et on est donc obligé de se taper la discussion parfois pour savoir si quelqu'un a dit "je prend". Parfois quelqu'un de l'organisation va se mettre en placeholder pour réserver l'issue, mais pour savoir qui bosse sur une issue c'est pas évident.

Idem au niveau de l'issue, le dev qui ne fait pas partie de l'orga ne pourra pas mettre à jour l'issue qui lui est assignée pour indiquer son évolution.

L'interface de GitHub n'est pas User-friendly

L'interface de GitHub est surtout fait pour le dev, ce qui a pour conséquence que l'on ne peut pas la personnaliser et donc brute de pomme, quand on arrive sur la page d'issue, c'est présenté de manière à faire fuire le premier venu.

La gestion de l'Infra

Aujourd'hui on se retrouve a mêler dans les issues du dépôt, les issues liées à l'infrastructure qui sont censée être propre au site qui déploie le logiciel zestedesavoir. Si je veux ré-utiliser le code de ZdS pour faire mon site, je m'en fou un peu que sur les serveurs de zestedesavoir.com ils n'ont pas alloués assez de mémoire à LaTex.

On a donc besoin d'un espace propre à zestedesavoir.com ou répertorier les taches à faire coté Infra.

Que pouvons nous espérer ?

Un vrai bugtracker assez user-friendly et utilisable par tous (le dev, le noob, etc.) et ouvert.

J'ai pensé à JIRA parce qu'il corrige les problèmes ennoncés ci-dessus, pour sa myriade de plugins et parce qu'on est un projet OpenSource (donc on pourrait avoir une offre cloud gratuite), mais n'importe quel autre outil qui fait le boulot serait intéressant à regarder.

De mon point de vue, tout ce que tu présentes ici est pertinent, modulo ce point :

On utilise donc les Milestones en mode scotch pour palier au problème de fin de workflow vu qu'on range les issues dans une Milestone quand l'issue est fermée. On arrive donc pas à exploiter au final nos milestones.

En fait, le comportement fonctionnel sous-jacent est parfaitement voulu et maîtrisé : contrairement à la plupart des projets, dans notre organisation, le contenu d'une release n'est pas fixé à l'avance.

Une issue n'est donc rattachée à une version spécifique (représentée ici par une milestone) que lorsqu'elle est réalisée et qu'elle a passé la QA - et donc qu'elle est mergée. D'où le comportement observé en terme de gestion des milestones.

Qui donc ne sont pas des milestones au sens où on les entend habituellement dans un projet. D'où cette impression que tu peux avoir qu'elle ne sont pas exploitées : en fait, si.

Pour utiliser Jira au boulot et Redmine pour les projets persos, l'interface de Redmine me semble moins lourde. Je ne connais pas d'offre Cloud gratuite pour héberger un Redmine, mais du coup si vous auto-hébergez votre Redmine, vous pouvez facilement intégrer les comptes utilisateurs du site à ceux de Redmine.

Je suis aussi moyennement fan de Jira pour l'avoir utilisé un temps au boulot (pour info apres plusieurs tests on est maintenant sur Youtrack de Jetbrain) mais soyons honnête, l'auto-hebergement est une contrainte forte "contre" Redmine, d'autant plus si faut faire un dev.

On est déjà pas assez nombreux pour gérer le developpement et la gestion de l'infra du site, la gestion par l'asso de la preprod et d'un système de backup va venir s'ajouter au serveur de prod, je ne suis pas persuadé qu'un outil supplémentaire à administrer, qui possède des alternatives "dans le cloud", soit tres pertinent.

J'ai bien conscience que ce n'est pas spécialement grand chose à administrer, mais je pense qu'on a déjà assez de truc à gérer comme ça.

edit: A noter que youtrack possède aussi une licence gratuite et complète dans le cloud pour les projets open sources

Je regarde ça depuis ce matin, mais je n'ai pas encore trouvé un moyen d'importer les issues existantes de github dessus. Sais-tu si c'est faisable ?

Je regarde ça depuis ce matin, mais je n'ai pas encore trouvé un moyen d'importer les issues existantes de github dessus. Sais-tu si c'est faisable ?

A priori pas directement, cf cette page qui liste les import mais ne mentionne pas github.

http://blog.jetbrains.com/youtrack/2011/10/streamlining-issue-management-with-github-and-youtrack/ ?

C'est plus au niveau de l'import de l'existant que je ne trouve pas. J'ai déjà trouvé pour la partie streaming.

Pendant qu'on parle des outils, je rappel (ou apprend ?) aux dev back qui nous ont rejoint récemment que vous pouvez obtenir une licence complète de PyCharm pour le développement du site. Il faut demander à SpaceFox pour ça.

Il est evident que ces licences ne seront pas distribués à des non-contributeurs mais si vous faites parties de l'équipe de dev, n'hésitez pas.

Bon, nous en sommes déjà à 179 issues ouvertes coté github et ça devient de moins en moins pratique pour suivre. Ce qui fait qu'on en arrive a crée pas mal de doublons dans les issues si on n'a pas tout suivi depuis un moment.

On se décide a tester autre chose ou on attend la catastrophe ? Parce que, perso, je dois avouer que je m'y perd totalement dans la lecture des issue actuellement. Et on dirait que je ne suis pas le seul.

Comment font les gens qui ont des projets plus gros et qui utilisent Github ?

Le seul exemple qui me vienne à l'esprit est Julia, où il y a 826 issues ouvertes (et presque 5000 de fermées) sur Github. Et le projet est public depuis 2012.

Comme ils ont l'air de s'en sortir pas trop mal, il faudrait voir quelles sont leurs méthodes et à quel point c'est applicable à ZdS. Le premier point qui me frappe est un très grand nombre de labels, mais plutôt descriptif de la catégorie d'issue, plutôt que des labels facile, difficile, …

Ou comme la plupart des projets open-sources (synfony, …). Pour un projet moindre, au taff, on s'en sort assez bien aussi, alors que comme ZdS c'est une sorte de web-app.

Après pour les autres liés (infra des serveurs, ..) ils ont en effet rien à faire sur le dépot du code-source du site. La solution serait d'ouvrir un autre répo qui ne fait que contenir des issues (ca existe) ou de les balancer autre part en effet (dans la maintenance d'un charriot, on va pas devoir maintenir le cheval ou l'ane qui va avec… bah là c'est la même chose ; osef des dépendances)

Voila, comme le dit Talus, les autres projet ne sont pas pollués par l'infra et tout.

Et n'oublions pas qu'ils ont quand même une plus grosse équipe qui disposent de plus de temps que la notre. Dans le cas de Julia par exemple les issues sont fermées en 2 jours en moyenne, là ou chez nous ça prend 4 jours en moyenne (et encore c'est biaisé par les issues qui sont crées juste pour les PRs).

Et encore pour Julia je vois que leur process/workflow n'est pas aussi lourd que le notre (QA, etc.) donc on n'est pas vraiment dans le même cas.

Soyons sérieux avec l'infra : il y a quelques tickets qui la concernent, mais ça reste très minime. On ne peut décemment pas prétendre que c'est sa présence qui gène le fonctionnement global.

PS : mais le fonctionnement actuel est à améliorer, je suis 100% d'accord.

Julia est aussi un outil pointu (langage spécialisé vers le calcul numérique) développé majoritairement par des personnes du domaine. Le niveau moyen des contributeur doit être assez élevé là ou sur zds on se veut ouvert aux contributeurs amateurs dans une certaine mesure. Sur Julia plus de 50% des contributeurs doivent être docteur ou en passe de l'être…

Ce qui me gene encore et toujours avec la comparaison avec des projets comme synfony ou les projets de la boite de Talus c'est que ce sont des projets en grande majorité developpé dans le cadre d'une entreprise par des gens qui l'utilisent a temps plein.

Je ne veux pas dire par là que ça justifie de passer par autre chose que GH, mais il nous faudrait des comparaisons plus proche. Typiquement si quelqu'un sait comment est organisé LinuxFr, ce serait un bon point de comparaison.

Après, pour reciter les projets web open source, je pense aussi à Doctrine qui lui utilise un mix de Jira et de Github. En gros Github est utilisé pour les PR, alors que Jira est utilisé pour les tickets… C'est un peu chiant comme workflow je trouve (pour contribuer, faut d'abord s'inscrire sur leur Jira, puis envoyer via Github), mais ca a l'air de faire ses preuves aussi.

D'autres projets, type PHPUnit, Behat, … etc passent completement sur les issues Github et s'en sortent bien aussi (bien que ce soit des outils devs, et pas une web-app comme la notre).

Je me répond à moi même, ils ont un bug tracker dédiés intégré au site.

Django utilise Trac. J'ignore si ça apporterait quelque chose à ZdS.

Je fais un petit up pour faire le point.

Des solutions existent :

• Jira
• Youtrack
• Redmine
• Trac
• GitHub

Des contraintes existent aussi

• Simple d’accès a un utilisateur externe ;
• Interconnecte avec Github ;
• Interconnecte avec ZdS (soyons fous !) ;
• Pas besoin d'autoheberger ;
• Interface comprehensible.

Et il faut des fonctionnalites au minimum equivalent a GitHub :

• Tickets (evidemment)
• Label
• Milestones
• Espace de discussion
• Assignement des personnes ?
• (Idealement) gestion des PR

Partant de ca, pourriez vous proposer vos outils favoris qui pourrait etre adapte et mettre en evidence ce qui est possible ou pas en fonction de cela ?

Sinon, pour parler des soucis avec Github : Un souci qui m'ennuie c'est le manque d'une vision "timeline". Actuellement on a des bugs qui doivent etre traites en priorites (ceux lie a la release), d'autres rapidement, d'autres sans urgence puis enfin les evolutions qui viendront tot ou tard. Mon probleme c'est qu'il est tres difficile de reperer les premiers cas, les bugs a traiter en release, car ils n'ont aucun statut particulier.
Situphen propose l'ajout d'un label "beta" pour prevenir que le bug est actuellement en beta, semantiquement je prefererais que le bug soit ajoute a la milestone. Comme ca on verrais si une milestone est propre ou non pour un passage preprod->prod rien qu'en regardant si des tickets sont ouverts dessus.

Moi j'ai surtout utilisé redmine. C'est un outil vraiment génial. L'administration par contre est plus complexe, je n'ai jamais réussi à installer un plugin du premier coup (ruby aux chiottes !).

Par contre pour des devs, c'est à la fois plus complet, plus efficace et plus modulable que github.

Surtout qu'avec les ZEP, on pourrait carrément les passer en "sous projet" et ça donnerait une belle visibilité.

Redmine est bien évidemment gratuit mais les offres SaaS ne le sont pas.

Pour utiliser Youtrack au boulot, je pense qu'il répond un peu toutes les exigences. Il est tres complet, on peut configurer le workflow comme on le veut avec plus ou moins d'états, de sous sytèmes, de sous tickets, etc.

Son principal défaut est celui de tous les outils Jetbrains, il est tellement complet et plein d'options qu'on si perd dans la configuration tellement il y a de possibilités. Donc si on l'utilise, bonne chance à celui qui va l'administrer.

Cependant une fois réglé, il y a pas grand chose à en dire.