L'assurance qualité dans le milieu du libre et chez Debian

Par Raphaël Hertzog <hertzog@debian.org>

Juillet 2005 à Dijon

dans le cadre des

Rencontres Mondiales du Logiciel Libre

Plan de la présentation

Présentation personnelle

Assurance qualité pour un logiciel

En entreprise

Dans le libre

Problèmes qualité rencontrés chez Debian

Outils et méthodes employés par Debian

Améliorations à venir

Conclusion

Présentation personnelle

Développeur Debian depuis 1997

Membre (entre autres) du groupe debian-qa

Gérant de Freexian SARL, une société de services spécialisée dans Debian

Auteur du livre «Debian GNU/Linux» publié aux éditions Eyrolles dans la collection «Cahiers de l'Admin»

Plus d'infos sur http://www.ouaza.com

La théorie de l'assurance qualité

L'ensemble des méthodes et activités permettant l'obtention de la qualité dans un développement logiciel

Il existe de nombreuses approches de la problématique

Implications dans les différentes phases

Spécifications / Conception

Développement / Documentation

Tests / Validation

Qualité et cycle de développement

L'assurance qualité est donc extrêmement liée au cycle de développement retenu et aux méthodologies employées

Cycle en V (standard, détaillé sur page suivante)

Extreme Programming

Scrum

...

Cycle en V

Fondements de l'assurance qualité traditionnelle

Documents décrivant en détail le logiciel

Tests permettant de vérifier que ce dernier correspond à ce qui était prévu par les documents initiaux

=> Tout ceci est nécessaire parce que le développeur n'est pas l'utilisateur (dans le cadre d'une démarche de satisfaction du client)

Et dans le logiciel libre ?

Particularités

Les développeurs sont les premiers utilisateurs, ils développent pour eux-mêmes

Peu de formalismes

Les documents de spécifications / conception sont rares

Le code source est considéré comme suffisant à lui-même (cf UTSL – Use The Source Luke)

Il y a toujours des exceptions...

Beaucoup de disparités

Les outils "traditionnels" ne sont pas systématiquement employés

Tests unitaires

Tests de non-régression

Programmation par contrat

Chaque projet utilise ce qui lui semble approprié et utile. Ce qui est trop contraignant n'est généralement pas retenu faute de bonnes volontés.

Les points forts récurrents dans le logiciel libre

Historique des modifications via CVS ou Subversion (gestion de configuration)

Implication permanente des utilisateurs (releases fréquentes)

Nombreuses possibilités d'interaction avec les développeurs

Une revue du code produit par les autres développeurs

Des outils d'amélioration (détection fuites mémoire, analyseur de codes, ...)

Conclusion sur l'assurance qualité dans le logiciel libre

De nombreux facteurs contribuent à la qualité des logiciels libres

Mais il n'y a pas systématiquement de politique d'assurance qualité imposée

Seuls certains éléments jugés utiles subsistent

Les parties contraignantes sont supprimées

Leurs absences sont largement compensées par les apports liés au mode de développement libre

L'assurance qualité chez Debian

Cela n'a rien plus rien à voir avec l'assurance qualité au niveau d'un seul logiciel.
Le point de vue change totalement :

L'apport de la distribution est dans l'intégration des différents éléments et dans leur cohabitation

Les bogues des logiciels ne constituent qu'une fraction des problèmes rencontrés par Debian

Équipe responsable de l'assurance qualité :

Liste de diffusion: debian-qa@lists.debian.org

Site web: http://qa.debian.org

Problèmes rencontrés

Assurer une cohérence globale

Garantir le bon fonctionnement des mises à jour

Résoudre les problèmes pour finaliser une nouvelle version (stable)

S'assurer que chaque paquet dispose d'un mainteneur actif

Continuer de réussir tout cela avec toujours plus de monde (>1000 développeurs) et plus de logiciels (>8000).

La cohérence du système

Elle est dictée par la charte Debian

Ensemble de règles techniques que chaque paquet Debian se doit de respecter

Chaque paquet indique quelle version de la charte il respecte

Des outils vérifient la conformité d'un paquet

lintian, linda : ils sont exécutés par les mainteneurs avant d'envoyer un paquet chez Debian

Les utilisateurs se chargent de signaler les manquements non détectés

Garantir le bon déroulement des mises à jour (1/2)

Pool important d'utilisateurs de la version "unstable"

Ces utilisateurs mettent à jour leur machine quasi-quotidiennement et les bogues de mises à jour sont rapidement détectés

Tests systématiques (mise à jour d'un système complet "stable" vers "testing" ou "unstable")

En cours de développement ("piuparts")

http://liw.iki.fi/liw/log/2005-06.html#20050623b

Garantir le bon déroulement des mises à jour (2/2)

Tests manuels par les utilisateurs

Rapports de mises à jour soumis sous forme de rapports de boguehttp://bugs.debian.org/upgrade-reports

L'équipe qualité se charge de "répartir" les bogues sur les paquets concernés

Éventuellement, des instructions particulières sont ajoutées aux «notes de mises à jour» ("release notes")

Éliminer les bogues

Le test permanent par les utilisateurs garantit que tous les problèmes importants sont répertoriés dans le BTS («Bug Tracking System»)

Priorité aux bogues critiques

Les autres bogues sont acceptables, aucun logiciel n'est parfait

Priorité aux paquets de base

On ne construit pas un grand ouvrage sur de mauvaises fondations

Le système de suivi de bogues est un élément central

Le BTS est l'outil de coordination par excellence chez Debian et son fonctionnement par mail va de pair avec l'emploi important de listes de diffusion

L'équipe Debian QA en extrait des listes de bogues à corriger

http://bugs.qa.debian.org

Garantir que chaque paquet dispose d'un mainteneur actif

Un paquet = un mainteneur attitré

Charge à lui d'en faire un paquet de qualité :

en suivant les évolutions de la charte Debian

en intégrant les nouvelles versions "amont"

Mais les mainteneurs sont des volontaires

leurs priorités changent... des paquets se retrouvent non maintenus sans que personne ne le sache

Il faut un système pour détecter ces disparitions et il faut les éviter

Gestion de la croissance

Debian devient un projet de plus en plus gros

plus de contributeurs

plus de logiciels

et, en conséquence, plus de bogues, plus de travail de coordination

Les outils et les modes de travail doivent évoluer pour suivre

Outils et méthodes

Objectifs :

Répertorier les problèmes, les améliorations possibles

Faciliter l'analyse des paquets Debian

Faciliter le travail des mainteneurs

Faciliter la coopération

Inciter les volontaires à aider là où ils le peuvent

Package Tracking System (PTS) (1/2)

En français, Système de Suivi de Paquet

Réalisé par votre serviteur

Permet de «s'abonner» à un paquet et de suivre toute son actualité (bogues, nouvelles versions...)

Facilite la collaboration

Préalable pour inciter les mainteneurs à travailler à plusieurs sur leurs paquets

Package Tracking System (2/2)

Rassemble toute les informations pertinentes sur une page web :

Changelogs des 30 dernières mises à jour

Résumé des bogues, des versions disponibles

Popularité, logs de compilation, rapports de conformité, statut migration vers "testing"

Liste des mainteneurs et co-mainteneurs

Permet de diagnostiquer rapidement l'état d'un paquet
http://packages.qa.debian.org

Capture d'écran (PTS)

Debian Developer's Packages Overview (DDPO)

Même esprit que le PTS et complémentaire

Réalisé par Igor Genibel

Offre une vue centrée autour d'un développeur Debian au lieu d'une vue centrée sur un paquet

Chaque développeur peut faire le point sur tous les paquets le concernant

Nouvelles versions "amont" disponibles

Nombre de bogues, progression vers testing

Problèmes de compilation...

http://qa.debian.org/developer.php

Capture d'écran (DDPO)

Base de données MIA

MIA = Missing In Action = mainteneur inactif

Chaque personne est invitée à signaler à l'équipe qualité un mainteneur inactif

Prise de contact avec le mainteneur

Discussion pour résoudre le problème

Solutions générales :

marquer quelques-uns de ses paquets comme « orphelins » afin que d'autres puissent reprendre la maintenance

trouver des co-mainteneurs

Documentation des procédures

Pour garantir un fonctionnement optimal, des procédures existent

Ex: « Comment se désengager de Debian »

Elles sont documentées dans le document « Debian Developers Reference »

http://www.debian.org/doc/manuals/developers-reference/

Un véritable « guide de bonne conduite »

Ce document a changé sous l'impulsion de Debian-QA pour inciter les mainteneurs à travailler en équipe

Incitation à la co-maintenance

Mise en place d'un service type SourceForge avec http://alioth.debian.org

Chaque paquet peut avoir un espace de collaboration pour une maintenance collective

Gestion de configuration (CVS, Subversion, Arch)

Liste de diffusion, site web

Développement d'outils facilitant l'emploi de dépôts cvs ou subversion

cvs-buildpackage, svn-buildpackage

Chasse aux bogues
Bug Squashing Parties (BSP)

Week-ends consacrés à la résolution de bogues critiques

Tous les volontaires se retrouvent sur un canal IRC (#debian-bugs@irc.debian.org)

Règles de NMU assouplies pour l'occasion afin d'avoir des résultats immédiats

NMU = Non-Maintainer Upload = mise à jour d'un paquet par quelqu'un d'autre qu'un des mainteneurs

L'entraide en temps réel permet de résoudre des problèmes plus rapidement

Améliorations à venir

Plus de tests systématiques des paquets

installation, mise à jour, suppression, puis détection d'éventuels changements résiduels

tests dans le cadre de mises à jour globales d'une distribution ("stable" -> "unstable")

De nombreux progrès restent à faire

beaucoup de « petits paquets » ne dépendent encore que d'un seul mainteneur

seul 1/3 des paquets ont des abonnés au PTS

Conclusion

Les infrastructures adéquates existent

Les procédures sont documentées

Ce sont les volontaires (actifs) qui manquent

Mettre en place une politique de recrutement

Amplifier la campagne de sensibilisation

L'assurance qualité chez Debian

N'a pas la lourdeur d'une norme ISO 9000

C'est une fédération d'initiatives personnelles

C'est beaucoup de bon sens

2005-06-29T10:24:57