Une plate-forme pour mes développements
Un bon gros weekend de geek. Mais il fallait le faire, ça commençait à trop tarder, avec les petits plugins que j’éparpille un peu partout, et les quelques développements que je réalise, il était temps que je mette en place une plate-forme pour assurer la maintenance de tout cela. Mon choix s’est porté sur Trac, voici pourquoi.
Mais pourquoi, au fait ?
J’avais installé un wiki sur mon site il y a quelques mois, pour noter tout ce qui n’a pas la même durée de vie qu’un article de blog. Et j’ai pris aussi l’habitude de développer avec Git, en hébergeant le code source chez Gitorious.
Gitorious est un très bon hébergeur de code source, basé sur Git donc, avec une interface assez jolie et ergonomique. Il est sous licence AGPL contrairement à son concurrent le plus direct, GitHub, qui est propriétaire. Vu mon penchant pour le logiciel libre, je me suis naturellement orienté vers Gitorious. Il a toutefois un défaut important : il n’y a pas de gestionnaire de tickets. C’est prévu, mais pour l’instant ils en sont à la conception, puisqu’ils voudraient mettre en place un système vraiment décentralisé et communiquant. On pourrait ainsi référencer et suivre les tickets ouverts sur d’autres instances de Gitorious.
C’est bien beau, mais pour l’instant ça veut dire que je dois trouver un autre moyen pour gérer les tickets des logiciels que je développe et auxquels je contribue. Ce n’est pas bien grave, il y a de nombreuses options en logiciel libre, donc j’ai cherché celle qui me conviendrait le mieux. Parmi mes contraintes, il y a :
- être en développement actif
- être relativement simple et facile à manipuler, je n’ai pas envie de noyer des rapporteurs de bugs potentiels
- la possibilité d’utiliser OpenID. Je n’ai pas envie de forcer les rapporteurs de bugs à ouvrir un nième compte à usage unique. En plus, grâce à OpenID, je déporte la problématique de gestion du spam sur le fournisseur OpenID, ce qui m’arrange pas mal.
- la possibilité de personnaliser sommairement l’interface, pour l’adapter au thème du reste du site.
Voici le résultat des courses (à mettre bien entendu en regard de mon besoin, qui n’est pas forcément celui de tout le monde).
La gestion de ticket en logiciel libre
Tout d’abord, j’ai cherché ce qui m’imposerait un minimum de dépendances. Sachant que mon espace web fonctionne très majoritairement en PHP/PostgreSQL, j’ai cherché des gestionnaires de tickets sur les mêmes technos.
Flyspray
Flyspray est un gestionnaire de tickets léger en PHP. Il a l’air pas mal du tout, mais son activité de développement semble relativement faible, et il n’a pas encore OpenID, donc j’ai laissé tomber.
Mantis
Attention, gros poids lourd. Mantis est un gestionnaire de tickets très puissant, mais qui échoue sans réserves au point n°2. Peut-être que ce sera un outils parfait pour quelqu’un dont c’est le métier, qui va rester toute la journée devant et apprendre à le maîtriser, mais pour moi et le quidam moyen qui ouvrira des tickets chez moi, c’est trop compliqué.
InDefero
Ça c’est très intéressant. InDefero est un petit dernier qui se veut être un clone de Google Code en PHP. Il a l’air vraiment très bien, mais pour l’instant il ne gère pas OpenID. Dommage, tout le reste avait l’air très bien.
Bon, ne voyant rien sortir en PHP/PostgreSQL, j’ai décidé de relâcher la contrainte PHP, et d’aller regarder ce qui se fait dans les autres langages.
Bugzilla
Je connais pas mal, vu que c’est ce qui est installé chez Fedora. Trop complexe à utiliser, trop complexe à installer, et trop gourmand en ressources.
Redmine
Là, on a du très lourd. Redmine est un gestionnaire de projets écrit en Ruby, qui fait exactement tout ce que je veux, et même plus. Le mec cool qui m’héberge a en plus déjà installé un Redmine sur le serveur, mais vu que mes réglages sont assez différents (accès à tout le monde), il faudra que je m’installe une autre instance. A priori pas un problème.
Trac
Trac, je connais déjà. C’est un très bon gestionnaire de projets, simple et efficace, écrit en Python (donc un plus pour moi), et pour lequel j’ai déjà écrit plusieurs plugins. Lui aussi, il fait tout ce que je veux.
Redmine ou Trac
Les deux finalistes sont donc Redmine et Trac. Je me suis dit que c’était l’occasion d’essayer Redmine, donc j’ai essayé de comprendre comment c’était installé sur la machine. Et bien, je dois dire que je n’ai pas compris. C’est manifestement installé dans Apache avec Passenger, mais à part ça je n’ai rien réussi à recoller. En plus j’ai essayé de ne pas toucher aux fichiers pour éviter de casser quoi que ce soit, ce qui fait qu’au bout d’une demi-heure de farfouillages et de recherches sur le net, j’ai perdu la motivation. Ça marche, mais je ne comprends pas pourquoi, et ça j’aime pas tellement.
Donc bon, je me suis rabattu sur le bon vieux Trac que je connais bien maintenant. Finalement, le fait qu’il soit écrit en Python fait que je peux mieux le maîtriser, et écrire des plugins si nécessaire, plugins qui pourront peut-être servir à d’autres.
Comme j’ai plusieurs projets indépendants, je vais faire gérer plusieurs “environnements” à la même instance de Trac, ce qui économisera la mémoire. Cela se fait assez facilement grâce à la fonctionnalité correspondante de Trac, c’est à dire --env-parent-dir pour tracd ou la variable d’environnement TRAC_ENV_PARENT_DIR dans mod_wsgi (que j’utilise). Toutes les instructions sont sur le site de Trac.
Adaptations
Alors, reprenons le besoin : mon code est hébergé chez Gitorious, il ne me faut donc qu’un gestionnaire de tickets. Comme Trac fournit un wiki, je vais m’en servir à la place de celui de Gitorious, pour pouvoir référencer les tickets d’incidents, et profiter des possibilités d’adaptation graphique de Trac. Par contre, Trac fournit aussi un gestionnaire de code source, et ça je n’en ai pas besoin.
Le navigateur de sources
Et oui, si mon code est hébergé chez Gitorious, ça serait bizarre de se servir de l’explorateur de code de Trac. J’ai donc cherché plusieurs solutions pour remplacer le navigateur de Trac par un lien vers Gitorious, mais rien ne s’est révélé très satisfaisant. En plus de ça, la syntaxe wiki de Trac permet de référencer un fichier dans l’arborescence des sources, avec un lien du type [source:monfichier.ext]. Dans le meilleur des mondes, ces liens arriveraient directement dans Gitorious, sur le bon fichier, et même à la bonne ligne.
J’allais quand même pas rater une occasion d’améliorer le monde, non ? 
Donc j’ai fait un plugin Gitorious pour Trac qui fait exactement ça : il remplace le lien du navigateur de sources par un lien vers Gitorious (il faut configurer le nom du projet cible), et intercepte tous les liens vers les sources en les réécrivant pour pointer vers le navigateur de Gitorious. Si vous êtes dans le même cas que moi, n’hésitez pas à vous servir de mon plugin.
Il y a des fonctionnalités de Trac qui n’existent pas chez Gitorious, je n’ai donc pas tout remplacé, mais c’est déjà assez sympa.
Autres plugins
Trac dispose d’un plugin pour l’authentification par OpenID, donc y’a qu’à installer. Il me fallait aussi évidemment le plugin Git, histoire que mes modifications apparaissent dans la timeline. Et j’en ai bien sûr profité pour installer mon plugin d’export ODT. Enfin, j’ai installé le plugin TranslatedPages pour faciliter la traduction des pages du wiki.
La quantité de plugins disponible pour Trac est vraiment phénoménale, on trouve tout ce qu’on veut !
Graphisme
Je n’allais pas quand même laisser les visiteurs et les rapporteurs de bugs avec une rétine intacte, c’est pas le genre de la maison. J’ai donc modifié le template de Trac par défaut pour que mon espace de développement soit aussi moche que le reste de mon site. La cohérence, c’est important. Les instructions se trouvent sur le site de Trac, avec quelques exemples pour les cas classiques (ajouter une CSS, etc.).
Le langage de templates utilisé par Trac est Genshi, c’est très proche du XML/XSL, ça me rappelle le langage TAL de Zope, donc c’est marrant. En plus je commence à bien le connaître puisque je l’utilise au boulot.
J’ai aussi modifié la page qui sert d’index aux projets. Là aussi, les instructions sont déjà toutes prêtes sur le site de Trac. Je vous laisse souffrir admirer.
Téléchargements
Il existe plusieurs moyens de proposer un espace de téléchargement de fichiers dans Trac. On peut tout simplement faire un lien vers un répertoire d’Apache. On peut ajouter un lien dans la barre de navigation principale pour pointer vers ce répertoire. On peut aussi attacher les fichiers à une page du wiki, mais ce n’est pas ce qu’il y a de plus pratique. Et évidemment, il y a trois plugins différents pour gérer un véritable espace de téléchargement (Trac : there’s a plugin for it).
Mais moi je voulais quelque chose d’un peu différent : je voulais pouvoir générer automatiquement des archives de la branche de développement toutes les nuits, je voulais pouvoir signer les publications, etc. J’ai donc opté pour un dossier dans Apache, qui est rempli par un script externe. Ce script tourne toutes les nuits et créée deux archives (tar.gz et zip) pour chaque tag de chaque projet, ainsi que deux archives de la branche de développement. Il en profite pour générer un bel index, et un flux Atom. C’est pas très compliqué, il y a peut-être 50 lignes de shell, donc pour l’instant je ne le publie pas sauf si quelqu’un se déclare intéressé. La génération du flux Atom est laissée à un autre script que j’ai écrit.
Conclusion
Je dispose maintenant d’une bonne plateforme d’hébergement de code, simple, bien intégrée avec Gitorious, extensible, automatisée, et surtout que je connaît bien.
Si jamais je décide de pousser l’auto-hébergement plus loin et de me passer de Gitorious, Trac est tout à fait à même de répondre au besoin. Je ne tire pas un trait sur Redmine pour autant, peut-être qu’un jour j’aurais l’occasion de l’utiliser activement. En attendant, le fait que je sois capable d’écrire des plugins pour Trac est quand même un facteur de poids dans la balance.
Si vous voulez plus de détails sur l’implémentation de tout ça, n’hésitez pas à me contacter (mais c’est pas très sorcier au final).
