InDefero 0.8.7 un long chemin depuis un an

Posté par (page perso) . Modéré par Florent Zara.
15
20
oct.
2009
PHP
InDefero est une forge logicielle que chacun peut installer sur son serveur avec le support de Git, Mercurial et Subversion. Le projet commencé en juillet 2008 arrive maintenant à maturité et est très agréable à utiliser au quotidien. Démarré comme un clone de GoogleCode, InDefero prend de plus en plus distance avec ce dernier pour répondre aux besoins exprimés par ses utilisateurs.

Comme plus de 1250 personnes, vous pouvez avoir votre forge hébergée pour vous ou l'installer sur votre serveur (même un tout petit VPS ou une offre mutualisée un peu robuste). Pour chaque projet de votre forge vous pouvez proposer une zone de téléchargements, un suivi des bugs, une documentation wiki, un parcours de l'arborescence de votre dépôt ainsi que la revue de code. Chaque partie peut être plus ou moins ouverte, vous pouvez aussi bien gérer un projet avec le code source en accès libre que garder le source accessible juste aux développeurs.

Les fonctionnalités de base sont :
  • interface web vers vos dépôts Subversion, Mercurial ou Git (chaque projet choisit son SCM) avec contrôle des droits d'accès directement dans l'interface ;
  • wiki pour la documentation avec possibilité de synchroniser une page avec le contenu du dépôt ;
  • tickets pour le suivi des bugs ;
  • revue de code ;
  • zone de téléchargement pour mettre à disposition des fichiers.
Le grand intérêt d'InDefero est sa légèreté, il fonctionne merveilleusement bien sur un simple serveur avec 256 Mo de RAM (hébergement Gandi) et maintenant la très sympathique communauté d'utilisateurs. InDefero utilise PHP et MySQL, PostgreSQL ou SQLite, sa rapidité provient de l'utilisation de Pluf, framework PHP5 très optimisé et d'une manière générale, d'une attention pour la performance.

InDefero est aussi pour moi une expérience de développement d'un logiciel sous licence GPL auto financé. Aujourd'hui, vous pouvez utiliser InDefero en l'installant sur votre serveur ou, au choix, en profitant de l'offre hébergée. Contrairement à toutes les autres « offres » d'hébergement, avec InDefero, vous avez accès au dump SQL de toutes vos données et vous pouvez facilement migrer en dehors de l'offre car le dump est compatible avec la version GPL. Aujourd'hui, plus de 1250 forges sont actives sur la version hébergée.

Est-ce que l'offre hébergée pourra effectivement financer le développement d'InDefero ? Je ne sais pas, mais dans tous les cas, elle a le mérite d'améliorer énormément la qualité du logiciel, en effet, tous les bugs sur la plate-forme sont facilement reproductibles et donc faciles à corriger. Pour le moment, 50% des coûts de l'infrastructure sont supportés par les utilisateurs, ce qui n'est pas si mal.

Venez essayer InDefero et dîtes nous ce que vous en pensez !
  • # C'est compliqué a installer!

    Posté par (page perso) . Évalué à 3.

    J'ai essayé d'installer la bête, mais sans controle de version, car je n'en ai pas besoin pour mes projets. Seulement il faut d'abord installer un framework, exécuter des script shell et patati et patata.

    Mon hébergeur ne me permet pas d'exécuter de scripts shell et rour cela fait beaucoup de manipulations pour avoir quelque chose de simple, alors j'ai laissé tomber.

    Un installeur simple et digne de ce nom serait sans doute grandement apprécié!
    • [^] # Re: C'est compliqué a installer!

      Posté par (page perso) . Évalué à 3.

      En fait, c'est sur la liste des choses à faire. Le seul problème avec un installeur est qu'il faut de toute façon faire des actions en root pour configurer le SCM (git, mercurial ou subversion). C'est là la limite d'un installeur via le web.

      En fait, la direction future (déjà prise par Archlinux) est de proposer des paquets directement pour chaque distribution.
      • [^] # Re: C'est compliqué a installer!

        Posté par . Évalué à 1.

        À noter qu'un truc particulièrement bloquant, c'est le besoin d'exécuter des commandes dans un shell (migrate.php) et de devoir renseigner des répertoires absolus sur la machine (qui pourraient être calculés automatiquement j'imagine).

        Personnellement, je n'ai pas réussi à l'installer au boulot où je n'ai qu'un accès ftp à mon répertoire web (je comptais l'utiliser sans dépo pour le moment) !

        Si en plus SQLite était complètement supporté, ce serait le must :)

        En tout cas ça fait plusieurs mois que je bave dessus pour l'utiliser au boulot, ça a l'air d'être super.
        • [^] # Re: C'est compliqué a installer!

          Posté par (page perso) . Évalué à 1.

          Cela va être résolu rapidement. J'ai pris l'approche Python d'avoir un script shell pour l'installation mais manifestement, c'est renier l'avantage de PHP que de pouvoir facilement faire tout tourner via le serveur web.

          Pour SQLite le problème vient des mises à jour de la base. SQLite n'a qu'un nombre limité de commandes "ALTER TABLE ...".

          Merci pour votre patience...
  • # InDefero 0.8.7 ?

    Posté par (page perso) . Évalué à 4.

    Le site officiel est moins à jour que DLFP puisqu'il mentionne la version 0.8.6 ;-)

    J'aurais aussi apprécié une petite liste des changements qu'apporte cette nouvelle mouture.

    En tout cas, c'est une forge que j''utilise et recommande. L'utilisation est très agréable (quoi qu'un peu lente) et l'ergonomie me va très bien. Le seul point noir était au moment où je l'ai installé, la documentation. Mais ce point semble s'améliorer.

    Merci aux développeurs pour le travail accompli.
    • [^] # Re: InDefero 0.8.7 ?

      Posté par (page perso) . Évalué à 2.

      > L'utilisation est très agréable (quoi qu'un peu lente)

      juste pour avoir des précisions, quel lien alors avec sa rapidité provient de l'utilisation de Pluf, framework PHP5 très optimisé et d'une manière générale, d'une attention pour la performance. tiré de la news

      Sinon, comme le commentaire précédent, une installation simplifiée serait réellement appréciable, même si ça ne m'empêchera pas de le retester bientôt (j'utilise redmine pour le moment, mais InDefero me semble assez agréable à utiliser et faisant suffisament de choses pour moi)
      Reste à voir (j'ai pas encore cherché, donc patapai) comment fonctionnent les workflow de gestion de bug (important pour moi)
      • [^] # Re: InDefero 0.8.7 ?

        Posté par (page perso) . Évalué à 2.

        j'utilise redmine pour le moment, mais InDefero me semble assez agréable à utiliser et faisant suffisament de choses pour moi

        Dans le même style, il existe Retrospectiva [http://retrospectiva.org/], qui, bien que pas très connu, mérite d'être essayé.
    • [^] # Re: InDefero 0.8.7 ?

      Posté par (page perso) . Évalué à 2.

      Um, oui le site doit être mis à jour, cela ne fait pas sérieux.

      Sinon, pour la lenteur, on est tous (sur le channel IRC) un peu étonné et je me demande si tu pouvais nous donner un peu plus de détails sur ton installation et le SCM utilisé ? InDefero est optimisé (et Pluf aussi) en continu à coup de Kcachegrind donc, bon, cela nous parait bizarre.

      Si tu as une instance memcached, mettre cela dans la config pour l'utiliser pour la mise en cache des infos pourrait aider :

      $cfg['cache_engine'] = 'Pluf_Cache_Memcached';
      $cfg['cache_timeout'] = 300;
      $cfg['cache_memcached_keyprefix'] = 'domaine.indefero';
      $cfg['cache_memcached_compress'] = 0;

      Par défaut cela utilise une cache disque qui n'est pas la plus performante.
      • [^] # Re: InDefero 0.8.7 ?

        Posté par (page perso) . Évalué à 2.

        Je ne connais pas assez InDefero pour donner un jugement, mais parfois l'impression de lenteur d'une application web n'est pas dû au temps de chargement de la page HTML elle-même, mais de ce qui vient avec.

        Par exemple, est-ce que InDefero utilise des javascripts qui pourraient ralentir le chargement de la page ? Un bon point de départ pour ce genre d'optimisations est les règles d'Yslow [http://developer.yahoo.com/yslow/help/#guidelines].
        • [^] # Re: InDefero 0.8.7 ?

          Posté par (page perso) . Évalué à 4.

          Merci Bruno, InDefero utilise du javascript mais le fait en suivant les guides de Yslow. Tout est fait en "amélioration progressive", les javascripts sont tous en bas de page, etc.

          On travaille vraiment beaucoup sur l'optimisation de la bestiole, avec 1200 forges hébergées et la très grosse forge d'Intuxication[1] on n'y échappe pas. Le passage de la forge de Céondo[2] sur une tranche Gandi 256Mo fait partie de ce travail de toujours pousser le logiciel à ses limites.

          Pour moi, un problème de performance est un bug critique, donc je suis là pour travailler dessus.

          [1]: http://www.intuxication.org
          [2]: http://projects.ceondo.com
      • [^] # Re: InDefero 0.8.7 ?

        Posté par (page perso) . Évalué à 2.

        Hello,

        Je n'ai pas beaucoup de temps dans l'immédiat pour fournir plus d'infos, mais j'ai remarqué que l'exploration de repository SVN est un peu lente à mon goût.

        Il faut aussi que j'avoue être resté à la 0.8.2... c'est peut être amélioré depuis (il faudrait que je prenne le temps d'upgrader mais ma tentative pour passer à 0.8.4 il y a quelques mois m'avait un peu fait peur...)

        Voila quelques détails supplémentaires :
        - machine assez puissante et très peu chargée
        - SVN partout
        - Je n'utilise pas memcached (c'est peut être préconisé?)
        - apache2
        - moins de 10 projets

        Je vais me donner le temps dans la semaine de (tenter de) migrer en 0.8.7 pour voir si je ressens toujours le problème.
        • [^] # Re: InDefero 0.8.7 ?

          Posté par (page perso) . Évalué à 2.

          Mise à jour réalisée... pfiouuu c'est pas évident...

          Résultat similaire. Je tenterais memcached demain je pense pour voir si ça résoud ce problème.
          • [^] # Re: InDefero 0.8.7 ?

            Posté par (page perso) . Évalué à 3.

            Merci, j'ai vu ton passage sur IRC, je serai disponible demain pour voir ensemble ce qui peut être fait pour améliorer tout ça. On a de gros utilisateurs Git et Mercurial, un peu moins Subversion, donc bon on a peut-être perdu de vue un cas particulier.
  • # Support de Mylyn

    Posté par (page perso) . Évalué à 2.

    Est-il prévu de contribuer un peu en parallèle à Mylyn pour y intégrer le support d'Infero ? Cela pourrait aider dans le choix d'Infero comme forge par pas mal de projets.
    En effet, beaucoup de personnes aujourd'hui se tournent vers Trac grâce à (ou à cause de) Mylyn. Les autres forges/bugtrackers actuellement supportés par Mylyn sont JIRA (proprio) et bugzilla. Le support d'Infero par Mylyn serait un vrai plus.

    Pour information (et de manière très schématique), Mylyn est un plugin pour Eclipse très apprécié des développeurs qui fait office de gestionnaire de tâches/client pour des systèmes comme bugzilla/Trac/JIRA.
    http://www.eclipse.org/mylyn/
    http://fr.wikipedia.org/wiki/Mylyn
  • # Contexte d'utilisation

    Posté par (page perso) . Évalué à 1.

    Bonjour!

    Cela tombe bien, je suis à la recherche d'une forge avec hébergement... Je travaille dans un labo qui entre autre développe des modèles numérique (sur le domaine de la neige et les avalanches). Nous utilisons pour l'instant notre propre serveur SVN, qui est sur notre réseau local, derrière un pare feux. Comme je cherche à ouvrir le développement le plus possible, il nous faudrait un serveur SVN externe, ainsi que des outils de gestion de projet. Cela signifie les pré requis suivants:
    *il faut pouvoir héberger aussi bien des projets GPL que des projets proprio (je voudrais bien que tous soit GPL, mais nous avons des bouts de codes dans certains projets qui ont été financés avec certaines restrictions)
    *il faut un SVN (accessible aussi via un client SVN standard), un wiki pour la doc et communiquer avec les utilisateurs (ie: annoncer de nouvelles versions, etc) et un bug tracker
    *si la partie web peut ne pas avoir une fiabilité excellente, le dépôt SVN doit être très disponible (nous travaillons quasiment tous les jours dessus, il ne faut donc pas qu'un jour sur deux le dépôt ne soit pas accessible)
    *il faut des backups sérieux (car il s'agit de notre base de code, ce sur quoi nous travaillons, ce pour quoi nous recevons des financements, etc)
    *évidement, il faut que nous ayons la possibilité a tout moment de récupérer notre base SVN (cela ne veux pas dire que nous allons partir à peine arrivés, mais comme il s'agit du code sur lequel nous investissons beaucoup, il faut que l'on garde toujours la possibilité de migrer vers autre chose, que l'on garde la possibilité de reprendre en main notre projet)

    Est ce que InDefero peut satisfaire à cela? (ie: est ce que InDefero est prêt pour ce genre d'utilisation?)

    Mathias
    • [^] # Re: Contexte d'utilisation

      Posté par (page perso) . Évalué à 2.

      Bonjour Mathias,

      pour ce que je lis de la description des besoins, Indefero répond totalement à ce genre de besoins. L'intérêt de l'offre, contrairement à la majorité de ce qui se fait, est qu'il est possible de récupérer l'intégralité des données (dump PostgreSQL pour le moment mais bientôt dump JSON avec les outils pour faire l'import dans PostgreSQL, SQLite ou MySQL) ainsi que le dump subversion (svnadmin dump) quotidien.

      Le backup est fait dans un autre centre de données (Gandi) que le principal (OVH) avec warm standby de la base de données (merci PostgreSQL) et bientôt backup temps réel des données des dépôts[1].

      Une fois le backup temps réel des données des dépôts effectué, cela permettra de passer instantanément d'un centre à l'autre en cas de pépin avec le minimum de perte de données et d'interruption de service. La sécurité/disponibilité des données est un point crucial de l'offre (en fait c'est le point majeur).

      Les modèles numériques pour les avalanches, c'est sympa ça, à Davos ils ont un bon centre de recherche dans le domaine, mais je ne sais pas s'ils font de la modélisation.

      loïc

      [1]: http://www.ceondo.com/ecte/2009/10/new-backup-strategy-indef(...)
      • [^] # Re: Contexte d'utilisation

        Posté par (page perso) . Évalué à 1.

        Merci beaucoup pour ta réponse!

        Les modèles numériques pour les avalanches, c'est sympa ça, à Davos ils ont un bon centre de recherche dans le domaine, mais je ne sais pas s'ils font de la modélisation.
        Bah si, la preuve, j'y travaille et je m'occupe des codes de manteau neigeux, codes que je voudrais mettre dans un hébergement externe (et par étape passer en GPL).

        Mathias
    • [^] # Re: Contexte d'utilisation

      Posté par . Évalué à 3.

      évidement, il faut que nous ayons la possibilité a tout moment de récupérer notre base SVN (cela ne veux pas dire que nous allons partir à peine arrivés, mais comme il s'agit du code sur lequel nous investissons beaucoup, il faut que l'on garde toujours la possibilité de migrer vers autre chose, que l'on garde la possibilité de reprendre en main notre projet)

      Dans ce cas, utilise un DVCS comme Mercurial, n'importe quel clone du dépôt est aussi un réplicat intégral du dépôt.
      Gros avantage des DVCS par rapport à SVN : la simplicité d'administration.

      il faut des backups sérieux

      Pareil, avec un DVCS, n'importe quel clone est un backup.
  • # Maintenant que la grosse vague est passée

    Posté par (page perso) . Évalué à 3.

    je fais un tout petit hors sujet pour remercier l'équipe de modération pour la rapidité de la modération et la qualité des modifications apportées à ma proposition originale. Merci !

    loïc

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.