Groupe de travail Forges

Plutôt que de multiplier les serveurs Subversion et Trac dans les labos, devrait-on envisager de mettre en place un site de développement collaboratif ?

C'est pour répondre à cette question que s'est formé un groupe de travail, chargé de débattre de l'opportunité du projet, de comparer les possibilités techniques, voire d'accompagner la mise en oeuvre d'une forge de développement spécifique pour l'IN2P3 et/ou le RI3.

Les documents ci-dessous tentent de faire la synthèse des informations accumulées par le groupe et des débats qui ont jalonné ce travail. Dans tous ces documents et débats, on prendra garde à ne pas confondre les plate-formes ou sites d'hébergement des projets (la forge), et le ou les logiciels qui permettent de les faire fonctionner (le moteur).

Si le terme de forge vous semble flou, vous pouvez vous familiariser avec le sujet grâce à cette vidéo.

Besoins

Types de projets

Les projets qui cherchent un hébergement sont ceux qui ne sont pas déjà sous la coupe d'une grosse expérience de physique, car ces dernières fournissent déjà des outils d'aide au développement en quantité suffisante. Cela laisse la porte ouverte pour :

Beaucoup de projets potentiellement concernés existent déjà. Que l'on choisissent de profiter d'une forge existante, ou d'en construire une nouvelle, il sera particulièrement important de réfléchir à la façon de migrer ces projets pré-existants, par exemple la transformation d'un historique CVS en historique Subversion.

Contraintes et services souhaités

Dans nos rêves les plus fous

C'est à la limite de ce que l'on considère habituellement comme relevant d'une forge, mais une aide à l'intégration continue ferait beaucoup d'heureux. On parle ici de pouvoir compiler et tester la dernière version de son code, sur toutes les plate-formes de son choix, toutes les nuits, avec publication des résultats dans le site de la forge. Avec la banalisation de la virtualisation des machines, est-ce que le rêve devient accessible ?

Survol de quelques hébergeurs existants

On peut trouver de nombreux sites d'hébergement de projets. Nous en listons quelques-uns ci-dessous. Est-ce que l'un d'entre eux semble adéquat pour recevoir les projets IN2P3 et/ou IRFU ?

Il semble que non. Nous avons affaire soit à des sites qui n'acceptent que les logiciels libres, soit à des opérateurs privés dont la philantropie est trop douteuse, soit à des sites réservés aux projets d'une communauté particulière. Le site du Comité Réseau des Universités, peut-être le plus adapté à nos projets, demande tout de même que les projets soit appelés à devenir libres et ouverts à un moment ou à un autre. Le refus des projets privés est plus une contrainte pratique qu'un choix idéologique : ils n'ont pas et n'auront pas les ressources nécessaires pour assumer l'explosion prévisible du nombre de projets.

SourceForge (ici)

La mère de toutes les forges. SourceForge.net héberge aujourd'hui énormément de projets et d'utilisateurs, mais il n'accepte pas les projets privés.

Au Comité Réseau des Universités (ici)

SourceSup est une alternative intéressante à SourceForge.net pour les membres de notre communauté :

Toutefois, tous les projets hébergés doivent quand même avoir vocation à devenir public à terme. Il ne peut s'agir de projets purement internes à une institution.

A l'INRIA (ici)

Un bel exemple dont on peut tirer des enseignements (voir la Présentation JRES 2007) mais qui n'héberge que les projets INRIA.

Chez Google (ici)

Impensable d'héberger nos projets chez un prestataire américain privé, même si c'est gratuit et que les services offerts ont une bonne longueur d'avance.

Au CERN (ici)

Le portail Savannah, "motorisé" par Savane, est couplé à un Service CVS Centralisé, et sera bientôt couplé à un Service SVN Centralisé. Il est réservé aux projets CERN.

HEP Forge (ici)

Construite autour de Trac, cette forge est réservée aux projets publics de physique des hautes énergies et ayant vocation à être réutilisés.

Sites à évaluer

 

Survol de quelques moteurs existants

Si nous mettons en route une forge propre à l'IN2P3 et/ou au RI3, quel logiciel choisir comme point de départ ?

La grande majorité des produits proposés sont des dérivés du SourceForge original. Parmi ceux-ci, gForge semble le plus mature et le plus utilisé (en tout cas dans les institutions françaises), mais depuis que ces créateurs s'investissent dans une version commerciale (GForge AS), on peut s'interroger sur la pérenité du gForge libre.

En parallèle, Trac est la forge python qui monte, mais RedMine, le concurrent basé sur RubyOnRails, est en train de lui voler la vedette, parce que plus facile à installer et supportant plus d'outils de gestion de version (notamment CVS).

Savane (ici)

Utilisé par le CERN. Ne comprend pas de wiki, et semble moins déclencher l'enthousiasme que des produits comme Trac ou Redmine.

FusionForge (ici)

Créé à partir de gForge, lorsque les développeurs de ce dernier ont décidé de se concentrer sur sa variante payante (GForge AS). Utilisé pour les forges de l'INRIA et du CRU, ce produit semble à la fois mature et capable de monter en charge.

Trac (ici)

Attrayant pour sa simplicité d'utilisation, on peut se demander si c'est approprié pour un site qui voudrait gérer un grand nombre de projets, y compris des projets privés, et les administrateurs qui doivent installer et configurer Trac semblent parfois moins emballé. L'intérêt semble initial accordé à Trac semble maintenant se déplacer vers RedMine.

RedMine (ici)

Récent et populaire, est-ce qu'il est mature et capable de monter en charge ?

LibreSource (ici)

Quelques annonces récentes ont circulé sur ce logiciel franco-français, issu de l'INRIA. Ne semble pas connectable à un dépôt CVS. Tant que l'INRIA ne l'utilisera pour sa propre forge, on peut s'interroger sur sa maturité.

RedMine (ici)

Récent et populaire, est-ce qu'il est mature et capable de monter en charge ?

InDefero (ici)

Un clone de GoogleCode. A étudier.

CodingTeam ?

LaunchPad ?

PicoForge ?

VHFFS ?

 

Une forge spécifique IN2P3 ?

C'est en étudiant les sites proposant d'héberger des projets logiciels, et les logiciels qui permettent de mettre en place de tels sites, que l'on a pu identifier progressivement nos besoins spécifiques :

De tous les sites d'hébergement envisagés, aucun n'est satisfaisant, car limité aux projets libres, ou opéré par un tiers non digne de confiance, ou limité aux projets d'un organisme donné. Si nous voulons que note forge soit ouverte à tous les projets du réseau, nous ne pouvons échapper à la mise en place de notre propre site, et les bénéfices à en tirer sont assez évidents :

En ce qui concerne le choix d'un logiciel ou d'un autre, nous vous renvoyons au survol des moteurs existants. En ce qui concerne l'hébergement, le centre de calcul est évidemment ce qui vient à l'esprit. D'autres possibilités ?

Essai avec Redmine

Au moment où nous voulions mettre en place un prototype de forge, et hésitions entre Trac et Redmine, le centre de calcul de l'IN2P3 venait de mettre en place une forge Redmine pour ses projets internes, dans laquelle il accepta d'héberger quelques projets externes à titre expérimental. Jusqu'à présent toutes les demandes de projet ont été acceptées, mais elles n'étaient pas trop nombreuses puisqu'aucune publicité n'a été faite auprès des développeurs de l'institut.

Quelques statistiques, tirées de la présentation de Jean-René Rouet lors de la dernière réunion ouverte du CCRI (juillet 2009) :

On espère éclaircir le devenir de cette forge lors de la prochaine réunion du groupe, le 6 novembre. Parmi les questions à poser :

Réunions

Ci-dessous, les comptes-rendus des réunions passées ou les ordres du jour des réunions à venir.

Compte-rendu de réunion du groupe forges (2009/11/06)

Le groupe "Forges" du RI3 s'est réuni en visioconférence le 6 novembre 2009 de 10h à 12H.
Etaient présents : Julien Devemy, Nicolas Dosme, Laurent Garnier, Christian Helft, Eric Legay, Pierre-Etienne Macchi, Antoine Pérus, Jean-René Rouet, David Chamont.

Forge et Réseau des développeurs du CNRS

Christian Helft nous a parlé d'un groupe informel récemment formé en vue de créer une fédération des réseaux de développeurs du CNRS. Le nom de baptême envisagé est "FIND". La plupart des initiateurs du projet ont profité des dernières journées Plume (22-23 septembre) pour rencontrer le responsable de la MRCT (Gérard Lelievre). Certains initiateurs de "FIND" et Jean-Luc Archimbaud, responsable du projet Plume, ont engagé le débat avec Dominique Boutigny, responsable du centre de calcul, pour évaluer la possibilité d'héberger un jour au centre de calcul une forge pour l'ensemble du CNRS.

P.S. : depuis la réunion, le réseau a été renommé "DEVLOG" et fait l'objet d'une fiche plume (http://www.projet-plume.org/ressource/devlog).

Serveur Redmine du Centre de Calcul

Initialement mise en place pour les besoins interne du CC, ce serveur héberge maintenant une quinzaine de projets extérieurs, à titre d'essai (voir la présentation de Jean-René Rouet à la réunion CCRI de mi-2009). Jean-René précise que depuis juin un dizaine de projets ont été ajoutés au cas par cas, et un peu plus d'utilisateurs. L'administration du serveur n'a pas posée de problème particulier, et plusieurs mises à jour de Redmine ont été appliquées sans peine. La communauté internationale des utilisateurs et contributeurs à Redmine est plutôt active, et le nombre de greffons disponibles est passé d'une dizaine à une centaine.

De son côté, Julien Devemy a interrogé les utilisateurs pour recueillir leurs remarques. Le sentiment général semble plutôt bon. Comme on pouvait s'y attendre, les principales doléances portent sur l'intégration et la simplicité des fonctionnalités (ce qu'on attend d'une forge) :

Redmine contre Trac

Redmine a été adopté par le centre de calcul pour ses besoins internes parce qu'il semblait le mieux adapté à un instant donné. Nous en avons profité de façon opportuniste pour intégrer à titre d'essai des projets hors-centre. Néanmoins, il est clair que Trac possède plus d'utilisateurs, ce qui est plus rassurant pour sa pérennité. Certains utilisateurs soulignent également que le langage de programmation de Trac, python, est beaucoup mieux connu que ruby dans notre communauté. Les administrateurs objectent que nous ne sommes pas supposés co-développer Redmine, donc le langage de programmation utilisé importe peu. Il est aussi souligné que Redmine a la qualité de s'appuyer sur un cadriciel web (ruby-on-rails).

De toute évidence, le débat Redmine/Trac est loin d'être clos. Nous n'avons pas trouvé de comparatif récent sur la toile, et nous n'avons pas fait nous-même une comparaison détaillée. L'intérêt d'investir du temps dans une telle étude est discutable, dans la mesure où il n'y a pas d'équipe volontaire pour maintenir une forge basée sur Trac.

Par ailleurs, il y a des membres du groupe qui pensent que ni Redmine ni Trac ne méritent le titre de forge (P.S. : question à développer dans le sujet de forum http://informatique.in2p3.fr/?q=node/507).

Une forge IN2P3 officielle au printemps ?

Les administrateurs du serveur Redmine du centre de calcul aimeraient être renforcés par des "administrateurs fonctionnels", chargés de la configuration du site, de l'administration des projets, de l'écriture de pages web de support, du support aux utilisateurs... concrètement : tout ce qui ne demande pas un accès direct à la machine mais peut se faire via l'interface web de Redmine, avec un rôle d'administrateur. David Chamont et Antoine Pérus se proposent d'essayer.

Ils expriment également une inquiétude, si le service est ouvert plus largement, de voir se multiplier le nombre de comptes utilisateurs à gérer au sein de Redmine. Cette inquiétude n'est pas partagée par tous les membres. Cependant, il conviendrait d'externaliser la gestion des comptes utilisateurs, en concertation avec le service CVS/SVN existant au centre de calcul, spécialement si on veut pouvoir synchroniser la création d'un projet avec la création d'un dépôt de code.

David Chamont demande si OpenID ne serait pas une technologie intéressante. Les représentants du centre n'adhèrent pas à cette technologie ou ils n'ont aucun contrôle sur l'origine des utilisateurs. Ils préfèrent des adresses électroniques bien identifiées, éviter les noms de compte fantaisistes, etc. De plus, la technologie adoptée par le milieu de la recherche est plutôt basée sur Shibolleth. Dans tous les cas, la solution retenue devra impérativement être ouverte aux développeurs extérieurs à l'IN2P3, notamment ceux de l'IRFU.

Actions

La priorité est de revoir la politique d'authentification et de gestion des comptes utilisateurs, en essayant en premier lieu de se rapprocher de ce qui est fait pour le service CVS/SVN du centre de calcul. S'il s'avère que les besoins spécifiques de la forge pourraient nuire à la stabilité du service CVS/SVN, Christian Helft propose de mettre en place une deuxième collection de dépôts subversions, dédiés spécifiquement à la forge. Les représentants du centre aimeraient éviter un tel doublon.

Maintenant que le nombre de projets s'accroît, il devient également urgent de mieux accompagner visiteurs et utilisateurs, en rédigeant des pages de présentation de la forge, en classant les projets et en fournissant un guide pour les nouveaux utilisateurs.

Membres du groupe

Participants

Par ordre alphabétique :

Références

Présentations

Sur la toile

Sites d'hébergement

Moteurs de forge

Autres ressources