Ingénierie et développement chez Pandora FMS

Pandora FMS a commencé comme un projet open source totalement personnel en 2004. Je n’étais même pas un programmeur professionnel, je faisais du conseil en sécurité Unix. En fait, j’ai choisi PHP mais Pandora FMS était ma première application avec PHP, j’avais des connaissances sur ASP et mon langage de programmation préféré était C.

Un projet avec un seul développeur et aucun utilisateur professionnel de leur logiciel est pourtant très différent d’un projet avec plusieurs dizaines de développeurs et des centaines de clients utilisant le logiciel dans des environnements critiques. L’évolution qu’a connue Pandora FMS de 2004 à 2021 est un cas réel d’amélioration continue du processus d’ingénierie logicielle.

Heureusement, je n’ai pas fait attention à cette matière dans mon degré, parce que la plupart des choses qui fonctionnent et que j’ai appris avec pratique ne sont pas dans un livre, ni sont expliquées à l’université, parce que chaque projet logiciel et chaque équipe de personnes est très différent. Cela peut paraître cliché, mais c’est la réalité, et il vaut mieux l’accepter et éviter les formules, car construire un logiciel solide qui peut évoluer avec le temps n’est pas banal.

Dans cet article, je vais parler de notre expérience, de notre évolution au fil du temps, mais surtout de la façon dont nos processus d’ingénierie fonctionnent aujourd’hui. J’ai toujours pensé que la partie la plus importante d’open source est la transparence, et que cela devrait s’appliquer à tout, non seulement aux logiciels, mais aussi aux processus et aux connaissances en général.

Système de contrôle de version

C’est une partie essentielle de tout projet logiciel. Aujourd’hui, GIT est presque omniprésent (d’ailleurs, tout le monde ne sait pas que Git est l’œuvre de Linus Torvalds, auteur original du noyau Linux). Un système de contrôle de version sert, en bref, à ce qu’un groupe de développeurs puisse travailler sans chevaucher le travail.

Lorsque le projet Pandora FMS a démarré, je travaillais sans contrôle de version, car il n’y avait personne d’autre. Lorsque certaines personnes ont commencé à collaborer dessus, nous avons réalisé qu’un simple répertoire partagé n’en valait pas la peine, car nous étions en train de chevaucher le code et, oui, faire des sauvegardes pour enregistrer les anciennes versions n’était pas une méthode très efficace.

Le premier système de contrôle de version que nous avons utilisé était CVS, que nous utilisons depuis huit ans ou plus. Vers 2008, nous avons commencé à utiliser SVN (Subversion) un autre système légèrement plus efficace et ce n’est qu’en 2013 que nous avons commencé à utiliser GIT et ouvert notre référentiel officiel sur Github.

Référentiel public de Pandora FMS sur Github

Puisque Pandora FMS a une partie open source et une partie entreprise – avec code propriétaire et licence commerciale – nous avons deux projets GIT, l’un public dans GitHub et l’autre privé, que nous gérons avec GitLab. La version GitHub est synchronisée avec notre copie privée sur GitLab dans nos bureaux. Certains partenaires avec lesquels nous développons ensemble ont accès à ce référentiel privé, et via une extension de notre application de support (Pandora ITSM) nous partageons tous les tickets de planification de développement par versions avec certains de nos partenaires, afin qu’ils puissent voir en temps réel, le planning de développement basé sur les « releases » et tous les détails de chaque ticket.

Vue de ticket GitLab dans Pandora ITSM

Vie de tickets pour une mise à jour

Méthodologie de développement utilisée dans Pandora FMS

Chez Pandora FMS, nous utilisons notre propre méthodologie depuis le début, bien que nous ayons emprunté de nombreuses idées aux méthodologies agiles, en particulier à SCRUM. Du point de vue du cycle de vie, nous utilisons une adaptation de la méthodologie Rolling Release.

Voici quelques définitions importantes pour définir notre façon de travailler, certaines sont typiques de Scrum, d’autres d’autres méthodologies.

Objectifs de la méthodologie de travail de Pandora FMS

Les objectifs incluent non seulement les membres du développement, mais aussi QA, l’équipe de documentation et une partie de l’équipe marketing :

• Visualisation maximale : Toute l’équipe doit voir les mêmes informations, et elles doivent circuler de bas en haut et de haut en bas. En partageant les objectifs, nous pourrons faire un travail plus efficace.
• Ce que l’on ne voit pas n’existe pas, ce qui implique que toutes les informations pertinentes pour le projet doivent être reflétées dans la gestion, implémentée avec Gitlab. Ce qui n’est pas vu n’existe pas et ce qui n’existe pas ne sera pris en compte à aucune fin. Suivre strictement cette méthodologie permettra à chacun d’être très conscient du planning :-Respect strict des dates.-Planification à l’avance sans modifications de dernière minute.-Des informations plus claires et en temps voulu.-Élimination des pics de travail et une longue etc.
• Intégrité, avec un projet de plus en plus vaste et complexe, il est impératif de maintenir l’intégrité pendant le développement. Tout le code doit suivre les normes.

Ticket

Le ticket est l’unité minimale de travail. La personne responsable de son achèvement est une seule personne et il est prévu de le réaliser dans un jalon (mise à jour de version).

Un ticket est la manière dont le travail de développement est décomposé, de sorte qu’une grande fonctionnalité sera composée de différents tickets, ce qui peut idéalement être effectué entre plusieurs personnes.

Le ticket doit contenir une fonctionnalité ou une description des exigences, qui peut inclure des diagrammes, des spécifications, des schémas d’interface (mockup), des ensembles de tests, des exemples, etc. Dans certains cas, il peut même contenir l’analyse et la conception de la solution entière.

Un ticket complété doit se comporter comme spécifié dans le document fonctionnel (ticket) et les modifications apportées à ces spécifications doivent être reflétées dans le ticket.

Le fonctionnel est la clé pour que QA puisse valider un ticket ou non. QA devra ouvrir un ticket à nouveau s’il ne répond à aucun des aspects fonctionnels.

Membres et groupes de travail

Product Owner (PO)

Le PO définit où Pandora FMS doit aller, en contact avec les clients, le support et
la situation de marché « réelle », fournissant des orientations techniques et fonctionnelles mais sans s’impliquer dans le développement en tant que tel.

Comité des produits

Groupe de personnes qui rencontreront en permanence le PO pour s’entendre sur la destination du produit, en essayant de s’assurer que toutes les décisions du PO sont collégiales. Il est composé du responsable de chaque équipe Développement, QA, Support, Projets et Documentation.

Development Manager (DM)

Gérer l’ensemble du cycle de développement : définir les jalons, les priorités, gérer individuellement tous les membres et prendre des décisions opérationnelles. Il rend compte exclusivement à PO et est le chef de l’équipe de développement.

Équipe de développement

Il est chargé du développement des grandes fonctionnalités et des améliorations des produits, des refactorisations complètes du code, du développement des changements (petites fonctionnalités), des corrections de bogues et des améliorations de la maintenance des produits.

Équipe QA

Ils vérifient que chaque unité atomique de développement fonctionne comme défini dans les
spécifications. Il créera et maintiendra également un écosystème de tests automatisés pour le backend et l’expérience utilisateur.

Équipe d’assistance

Ce sont eux qui traitent directement avec le client dans la résolution des incidents. Leur expérience du quotidien du produit signifie que leur voix doit être prise en compte, c’est pourquoi ils font partie du comité produit.

Équipe projet

Ils implémentent sur le client final et sont les plus proches du client, car ils sont souvent là avant que le projet existe, et apportent généralement des idées et des fonctionnalités de toutes sortes par la main, à toutes fins utiles ils sont le « haut-parleur » du département commercial, ils font donc partie du comité produit.

Équipe de formation et de documentation

Responsable de la formation et de la documentation du produit. Ils se coordonnent avec l’équipe marketing et l’équipe de traduction.

Le télétravail

Tous les membres de l’équipe (développement, QA, documentation) télétravaillent librement. En fait, les développeurs d’Europe, d’Asie et d’Amérique participent à Pandora FMS et en Espagne, ils sont distribués sur tout le territoire national. Nous sommes une entreprise 100 % distribuée et décentralisée, bien qu’avec des hiérarchies traditionnelles.

Afin de télétravailler, nous avons besoin que chaque membre assume la responsabilité de son travail, soit autonome et s’engage dans la planification. Le télétravail implique de minimiser le besoin de communication orale et de rencontre personnelle physique, en les remplaçant non pas par des téléconférences, mais par une utilisation précise des outils du processus de développement.

Développement en permanence

Un développeur de l’équipe est particulièrement dédié à la résolution d’incidents impliquant du code, en lien permanent avec l’équipe support (de 8h à 20h, CEST). Cela permet non seulement d’avoir une agilité maximale lors de la résolution d’un problème dans un client, mais aussi les changements de code sont intégrés dans le référentiel de code de manière organisée.

Processus de création et de classification des tickets

Tout membre de l’entreprise (y compris les commerciaux) peut créer un ticket dans GitLab. Cela inclut les clients et les partenaires, bien que dans leur cas, il existe un filtre préalable par l’équipe de support et l’équipe de vente respectivement.

Plus le ticket est détaillé, plus le développement sera sans équivoque. Ajouter des images, des gifs, des animations et toutes les clarifications nécessaires. Ainsi que la manière d’accéder à l’environnement où le problème a été détecté ou aux personnes de contact. Un développeur ne contactera jamais directement un client. S’il a besoin d’interagir avec lui, cela se fera via support ou l’équipe projet.

Personne, sauf le DM ou le PO, ne peut modifier un jalon de ticket. Lors de la création, le ticket n’aura pas de jalon ou d’utilisateur affecté. La tâche de définir dans quelle mise à jour un ticket est alloué est la responsabilité exclusive du PO et DM.

Lorsqu’un ticket est terminé et que le développeur pense qu’il devrait être revu par un collègue, il le mentionne dans la « merge request » via @xxxxx. L’examen doit être nominal. Cette revue est indépendante de la revue de code réalisée par le chef de service.

Flux de travail général avec tickets.

• Le ticket est attribué à un programmeur par le DM. S’il n’a pas de ticket attribué, un ticket lui sera attribué automatiquement. (Voir ci-dessous les conditions qui régissent ce mécanisme).
• Le développeur doit comprendre/résoudre tout doute pouvant survenir après la lecture du document fonctionnel, s’il est nécessaire de consulter le DM ou l’auteur du ticket. Cela doit être fait avant de commencer à se développer. Une fois lu, il faut, dans l’ordre :

1. Évaluer (en attribuant des étiquettes) sa complexité et sa taille, en obtenant un consensus préalable avec le DM
2. Développer la fonctionnalité en suivant les spécifications du ticket.
3. Documenter tout ce qui a été développé dans le même ticket ou, si nécessaire, dans un nouveau ticket de documentation. Ce ticket doit se rapporter au ticket « parent » par #ID du ticket
4. Le développeur doit tester sa fonctionnalité au moins dans :
   -L’environnement de développement standard de docker.
   -L’environnement de développement docker avec des données.

• Lorsqu’il est jugé complet, il sera étiqueté ~ En attente de QA et placé entre les mains de QA.
• Pour chaque ticket FONCTIONNALITÉ il y aura une personne de référence, généralement issue des projets, du support ou encore du PO lui-même. Cette personne sera celle qui définit une partie du fonctionnel (avec DM et PO), mais surtout, elle sera la personne de référence pour que le développeur demande tous les détails lors du développement, et surtout, ce sera lui qui devrait voir la progression, étape par étape, du développement, afin qu’il soit validé.
• Toute modification de la fonctionnalité sera reflétée par la personne de référence dans le ticket sous forme de commentaires, sans altérer le fonctionnel d’origine.
• S’il y a un ticket de documentation enfant, QA valide le ticket en utilisant la documentation générée par la personne de référence, PAS par le fonctionnel du ticket, validant la documentation et la fonctionnalité en même temps.

Planification des versions

Lors de la création d’un ticket, le jalon doit être vide (non attribué) comme l’utilisateur. Les seuls qui peuvent classer un ticket sont : le DM et le PO.

Une série de jalons ont été définis qui servent à soutenir le processus de classification des tickets, dont certains, ceux qui sont datés (les mises à jour) peuvent être considérés comme des jalons, tandis que le reste doit être vu comme de simples conteneurs de tickets.

• (Non alloué) : C’est l’absence de jalon dans un ticket. À toutes fins utiles, ce ticket « n’existe pas encore ». Le DM et le PO valident chacun de ces tickets pour voir s’ils ont un sens dans la feuille de route du produit. Aucun développeur ne doit accepter aucun de ces tickets.
• Backlog de fonctionnalités : Tickets qui seront faits à un moment indéterminé dans le futur et qui devront tôt ou tard être traités. Aucun développeur ne doit accepter aucun de ces tickets.
• Bogues de faible priorité : Bogues signalés par priorité non encore attribués par le PO/DM. Aucun développeur ne doit accepter aucun de ces tickets.
• STAGE: Tickets proposés par chaque département pour la planification dans une mise à jour de produit. À chaque réunion de planification, ces tickets seront discutés et déplacés vers d’autres jalons. À la fin de la réunion de début de cycle, ce jalon doit être vide. Le DM est celui qui a la décision finale quant aux tickets STAGE qui sont ajoutés à une mise à jour et ceux qui ne le sont pas, en s’appuyant si nécessaire sur le comité produit. Aucun développeur ne doit accepter aucun de ces tickets.
• XXX : Mise à jour XXX. Jalon qui regroupe une série de tickets qui sortiront à une certaine date. Un jalon est associé à une échéance. Dans le cas des versions RRR, cette date est mobile, dans le cas du LTS, elle ne l’est pas.

1. Le développement des tickets associés à une mise à jour doit se terminer 5 jours avant le jour prévu pour la sortie. Les tickets non terminés avant cette date seront déplacés vers la prochaine version et le retard devra être justifié auprès du DM.
2. Il existe deux types de jalons de mise à jour :
   -LTS : En avril et novembre. Ils sont séparés les uns des autres 6 mois.
   -Versions régulières (RRR) : Il y aura de 2 à 4 versions régulières entre les versions LTS.

• Un développeur sans tâches attribuées pour une version, tant qu’il n’y a pas de tickets alloués en attente dans les jalons de publication pour son équipe, peut prendre l’un des tickets non attribués de :
  -La mise à jour la plus proche en date.
  -Deuxième mise à jour plus proche en date.

CICD

Les développeurs de Pandora FMS intègrent le code de leurs branches dans un référentiel central plusieurs fois par jour, provoquant l’exécution d’une série de tests automatiques dont l’objectif est de détecter au plus vite les bugs et d’améliorer la qualité du produit.

Ces tests s’exécutent dynamiquement dans une série d’exécuteurs ou « runners », certains d’entre eux spécifiques, pour certaines architectures (par exemple ARM), qui exécutent des analyseurs de code statiques, des tests unitaires et élèvent des conteneurs pour effectuer des tests d’intégration. Dans une installation réelle de l’application.

La génération des packages Pandora FMS est entièrement automatisée. Les packages sont générés chaque nuit à partir de la branche de développement pour des tests manuels. Ils peuvent également être générés à la demande par n’importe quel développeur ou membre des équipes QA ou de support, depuis n’importe quelle succursale via l’interface Web de GitLab.

Lorsqu’une version est faite à partir de la branche stable, en plus de la génération des paquets, une série d’étapes est exécutée pour les déployer sur le serveur de paquets interne d’Ártica, sur SourceForge, dans l’environnement de support client d’Ártica, et qui, de même, mettent à jour Debian, Référentiels SUSE et CentOS ainsi que les images Docker officielles.