Aujourd’hui, le premier article d’un cycle qui me permettra de parler d’outils logiciels que j’ai eu l’occasion de pratiquer ou d’expérimenter. Précisément, nous allons aborder les avantages procurés par les outils de collaboration proche du code source en nous appuyant particulièrement sur Gogs1 (une alternative open-source aux Github2, Gitlab3, etc.) et comparer les fonctionnalités de ce dernier avec ceux des outils plus traditionnels de bug tracking tels que Mantis4 ou Redmine5.
L’usage des outils de collaboration qui s’appuient sur le versioning de fichiers GIT sont aujourd’hui devenus très populaires auprès des développeurs, ainsi que l’illustre le succès de la plate-forme Github, devenue en quelques années le standard de facto pour tous les projets open-source, d’autant qu’il est gratuit pour un tel usage.
Le bug tracking classique : faisons le bilan
Traditionnellement, les outils de suivi de bug classiques sont redoutés à la fois par les clients (qui les trouvent trop complexes et peu efficaces pour le suivi) et par les développeurs (qui n’y voient qu’une perte de temps et un passage obligé sans réelle valeur ajoutée).
Le résultat est un sous-usage de la solution : les clients envoient des mails — voir directement des documents Word compilant leurs remarques — et les développeurs ne communiquent clairement ni avec ces derniers, ni même avec leurs équipiers … C’est donc bien souvent un échec.
Un outil utile à tous
Le parti-pris des outils de collaboration tels que Gogs est de donner à tous les intervenants différents moyens d’interagir et de collaborer les uns avec les autres, et de devenir ainsi l’élément central de la communication de l’équipe en interne et en externe.
Pour y parvenir, ils intègrent plusieurs fonctionnalités complémentaires.
Échanges avec le client
- le suivi de ticket est réduit à sa plus simple expression, favorisant l’efficacité et la rapidité plutôt que l’exhaustivité du rapport de bug : l’idée étant que chacun s’en empare pour échanger intelligemment ;
- il est possible de faire facilement référence à des tickets qui ont été ouverts depuis le code source en ajoutant des marqueurs aux messages de commit ce qui permet de suivre l’avancement et le travail effectué concrètement par l’équipe ;
- une fonctionnalité de wiki permet de garder la trace de réunions, d’ateliers, mais aussi de la documentation du projet, etc.
Échanges internes à l’équipe
L’utilisation de pull requests (ou merge requests ainsi qu’on les nomme plus fréquemment aujourd’hui) permet aux développeurs d’échanger autour du travail réalisé autour d’une fonctionnalité spécifique en commentant directement le code qui a été commité dans une branche donnée.
Cela permet tout à la fois :
- de surveiller les ajouts de code pour vérifier qu’ils respectent les normes de code ou la philosophie générale de l’architecture du projet ;
- de s’assurer de la relecture par un autre développeur qui verra immédiatement les erreurs les plus grossières (commentaires erronés ou lacunaires, erreurs de syntaxe, etc.).
Une fois que la fonctionnalité a été passée en revue et est validée par l’équipe, un simple clic dans l’interface permet de lui faire rejoindre la branche de développement principale. Néanmoins, l’outil s’assure avant de vous permettre de le faire qu’il n’y aura pas de risque de conflit en amont et vous empêchera de faire une erreur le cas échéant, ce qui est une sécurité supplémentaire.
Enfin, la fonctionnalité de wiki peut naturellement servir à l’équipe pour garder la trace des normes de code, de la documentation du projet et de ses procédures associées, des contacts, etc.
Faut-il sauter le pas ?
L’approche minimaliste de ces outils de collaboration ne conviendra bien sûr pas à l’ensemble des projets, car certains nécessitent par exemple un workflow de suivi et de validation précis, un suivi de temps, ou bien ne peuvent exploiter que des rapports de bugs extrêmement précis et détaillés ; il ne s’agit donc pas d’un choix technique à réaliser à la légère.
Il me semble cependant que pour la majeure partie des usages auxquels j’ai été confronté, cette approche de la collaboration qui permet de rapprocher la vision client de celle de l’équipe de développement ne peut être qu’une bonne chose.
Comme souvent, c’est particulièrement vrai dans le cadre d’une démarche agile, bien entendu, mais il me semble qu’une gestion de projet plus classique peut également tirer avantage des fonctionnalités offertes par ces outils.
Et pourquoi pas un outil en SaaS ?
Avant de finir, j’aimerais faire un point sur l’approche SaaS dans ce contexte spécifique : Gitlab ou Github proposent bien sûr des offres payantes pour héberger de manière privée vos différents projets, et ces dernières sont honnêtement assez compétitives, ce d’autant qu’ils s’occupent également de l’aspect sauvegarde des données, qui n’est absolument pas couvert en standard par les solutions auto-hébergées.
Le fait est néanmoins que leurs serveurs sont souvent placés à l’étranger, ce qui peut représenter un risque potentiel du point de vue de la confidentialité de vos données, surtout à partir du moment où vous commencez à y stocker de la configuration, des identifiants ou des informations sensibles.
Dans cette perspective, l’utilisation du système hébergé Gogs peut constituer une réponse intéressante. Fonctionnellement très proche de Github au niveau du service qu’il offre, Gogs est un outil assez facile à installer sur votre propre serveur : cela vous assure d’avoir toujours la main sur votre code.