Redmine: premières impressions
Par Clochix le samedi 11 octobre 2008, 10:59 - Technoweb - Lien permanent
Utilisateur satisfait de Trac depuis des années, je regrette qu'il faille installer une nouvelle instance par projet[1] et que bon nombre de manipulations nécessitent un accès en console[2]. Et puis, pas la peine de le nier, il y a tellement de bruit autour de redmine depuis des mois que, badaud attiré par les attroupements, j'ai voulu me rendre compte par moi-même. Toute première impression, en exclusivité pour Toi lecteur/lectrice/spider.
Notes
[1] même si Tristan a développé un package Debian qui facilite grandement la chose, il faut encore en passer par la ligne de commande pour créer un projet
[2] quoique la version 0.11 simplifie bien les choses en intégrant enfin nativement le module WebAdmin
(nota: j'ai commencé à rédiger ce billet début Août mais viens juste de le relire et de lui donner le BAT, certaines des infos sont donc probablement périmées)
Redmine est un gestionnaire de projets en ligne qui offre de nombreuses fonctionnalités:
- une seule instance de redmine permet de gérer plusieurs projets; chaque projet a sa propre configuration (modules activé, rôles des utilisateurs, etc) et on peut créer des sous-projets (quoique je n'ai pas encore trouvé comment adapter cette fonctionnalité à mes besoins). Les projets peuvent être publics ou accessibles uniquement à leurs membres;
- il peut s'interfacer nativement avec de nombreux gestionnaires de sources: SVN, CVS, Git, Mercurial, Bazaar, Darcs...
- en plus des modules présents nativement dans Trac (wiki, suivi de tickets), Redmine offre aussi des diagrammes de Gantt (miel pour attirer les chefs de projet), la possibilité de suivre le temps passé sur les tâches et de faire plein de rapports (idem), un gestionnaire de documents amélioré, des forums...
- il est multilingue;
- il peut gérer les utilisateurs en se connectant à un annuaire LDAP;
- tout est administrable en ligne, via un "back office";
- et bien plus;
Plutôt alléchant ! Trac, et c'est une de ses forces, dispose de centaines de plugins qui élargissent son domaine d'action bien au delà de ce que fait Redmine pour l'instant, mais le fait de disposer d'autant de fonctionnalités nativement est un confort appréciable.
Du côté des "risques" à l'adopter dès aujourd'hui, je citerai :
- sa relative jeunesse : je n'ai cependant pas encore rencontré de soucis notable avec la version actuelle, étiquetée 0.7.3
- conséquence de sa jeunesse, il dispose pour l'instant de beaucoup moins de modules additionnels que Trac. Si vous avez un besoin qu'il ne satisfait pas nativement, vous aurez moins de chance de trouver votre bonheur parmi les plugins.
- RoR : il est basé sur le framework Ruby on Rails. Ce qui n'est pas un défaut, loin de là, mais les compétences sont encore peu nombreuses, et votre administrateur pourra rechigner à installer un nouvel environnement qu'il ne maîtrise pas. L'installation elle-même n'est pas forcément triviale;
- l'intégration avec Mylyn laisse encore à désirer. Elle est possible via le connecteur générique, mais j'ai pour l'instant butté sur un problème de certificat auto-signé de mon site[1]. Un connecteur spécifique est en cours de développement, mais pas encore en version alpha, donc je ne l'ai pas testé;
Première impression
Première déconvenue en me rendant sur le site de Redmine: là où Trac faisait dans le rouge et le gris sombre, Redmine est résolument bleu. Or je déteste le bleu. Hop, fin de l'expérimentation de Redmine, je retourne à mon Trac.
(après une nuit de galère à installer le bouzin, je me dis que j'aurais mieux fait de m'en tenir à cette première impression :-S)
Installer Redmine sur Debian Lenny
Je ne vais pas faire un guide d'installation complet, car j'ai tant galéré que je ne suis pas trop sûr des manipulations qui ont conduit le machin à fonctionner.
Il n'existe pas encore de version packagée pour Debian de Redmine. Il faut
donc tout faire à la main: installer les dépendances, télé-charger
l'application, deviner où l'installer, faire des chown et les
chmod qui vont bien... Rien de compliqué, mais ça rappelle que le
logiciel est encore en phase de développement, même s'il semble plutôt stable
et utilisable.
Premier problème, la version stable actuelle (0.7.3) présente une incompatibilité avec Ruby 1-8-7 présent dans Lenny. Il faut patcher un fichier, comme expliqué dans ce thread, pour supprimer un message d'erreur :-S. Ceci fait, on se retrouve avec une application qui fonctionne à peu près.
Sauf que manifestement les applis Rails aiment bien leur autonomie, et se promènent avec leur propre serveur web. Ainsi Redmine tourne tout seul via le serveur WEBRick qui écoute sur le port 3000. Sympa, mais j'ai un Apache qui tourne sur la machine, et pas trop envie de multiplier le nombre de serveurs, de ports ouverts, etc. Et c'est là que la galère a vraiment commencé: comment faire fonctionner Redmine avec Apache ?
Apparemment, plusieurs possibilités s'offraient à moi:
- utiliser mod_proxy pour rediriger les requêtes vers WEBRick. Mais en l'occurrence je voulais me passer de WEBRick;
- les seules autres documentations que j'ai trouvées concernaient l'utilisation d'Apache comme load balancer devant Mongrel. Mongrel est un autre serveur Web écrit en Ruby. Là encore, ce n'est pas ce que je voulais faire;
- en utilisant mod_rails, aka Passenger. L'installation paraissait simple, un simple
gem install passenger[2], mais celui-ci a quasiment planté mon serveur. Après quelques recherches, il s'avère que gem est extrêmement gourmand en mémoire, et que même en arrêtant tous les autres services, les 256Mo de ma part Gandi n'étaient pas suffisant[3]. Hop, suivant; - utiliser Redmine en CGI. C'est la solution sur laquelle je me suis rabattue dans un premier temps (fast-cgi pour être précis);
Installation en (fast) CGI
- installer les paquets qui vont bien, en l'occurrence le module apache libapache2-mod-fastcgi et les bibliothèques fast-cgi pour Ruby : libfcgi-ruby1.8.
- configurer Apache: dans le cas d'un vhost, il faut faire pointer la racine du site vers le répertoire public de redmine, et autoriser la lecture du .htaccess situé dans ce répertoire:
DocumentRoot /var/www/redmine/public <Directory "/var/www/redmine/public"> AllowOverride All </Directory>
- configurer Redmine
- dans le fichier
config/environment.rbdé-commentez ou ajoutez la ligne
- dans le fichier
ENV['RAILS_ENV'] ||= 'production'
** dans le répertoire public, renommez ispatch.fcgi.example en
dispatch.fcgi et rendez-le exécutable.
Et c'est tout ! Oui, au final ça a l'air tout simple et rien ne justifie les heures que j'y ai perdues, si ce n'est mon ignorance crasse de la vie du Rails, et le manque de documentation.
Avec mod_rails
Après quelques jours d'utilisation, le cgi ne semblait ni très réactif, ni
très stable, avec des plantages réguliers dans les logs, se traduisant par des
erreurs 500 aléatoires sur le site. Sur les conseils d'un camarade de bac à sable, j'ai alors
re-tenté d'installer mod_rails. Après quelques recherches sur les forums, j'ai
trouvé une astuce pour réduire la consommation mémoire de gem: l'appeler avec
l'option -B 1000000. Nouvelle tentative, le serveur ne plante pas,
l'install va un peu plus loin, et se plante en signalant l'absence de mkmf.
apt-file search mkmf.rb, apt-get install ruby1.8-dev,
gem install passenger -B 1000000, wéééé, joie, ça passe, ça
marche, et le résultat semble bien plus rapide et stable qu'en CGI, hop,
adopté.
A l'usage
Le principal défaut de Redmine est simple à corriger, la création d'un thème avec une simple CSS supprime le bleu. Et ensuite... Ensuite il faudrait que je l'utilise pour de vrai, sur un vrai projet, pour vraiment l'évaluer. Comme Couac est en sommeil en ce moment, va falloir que je teste sur des projets pros (histoire que les heures que je perds chaque jour à vendre mon corps servent à quelque chose), donc que je convainque Chef de me laisser l'installer et migrer un projet dessus. Chef, toi dont le ramage du plumage est à l'image de l'hommage...
Notes
[1] oui je sais il suffit d'importer le certificat dans Eclipse, j'ai trouvé une doc sur le sujet
[2] gem est le gestionnaire de paquets de Rails,
l'équivalent par exemple de la commande pear pour PHP
[3] gem essaie de télécharger et de monter en mémoire la liste de tous les paquets existants, et vu la vitalité de la communauté Rails, ça fait un paquet de monde
Commentaires
Sur l'histoire des plugins, même si Redmine en a moins, je pense qu'il a l'avantage sur Trac d'avoir ceux qu'il faut par défaut. Ca évite de monter son instance trac et ensuite d'installer tous les plugins qui vont bien..
Cf : http://www.unelectronlibre.info/jou...
C'est vrai par contre que son installation et son exploitation laisse encore à desirer... J'avais à l'époque pas réussi à ce que le service fonctionne correctement, donc en cas de redémarrage de la machine, il ne fallait pas que j'oublie de relancer mon script... pas glop du tout...
Ah oui, sinon sur le coup des compétences RoR, y en a pas vraiment besoin pour installer Redmine donc je pense pas que ce soit un gros handicap. Ou alors ça veut dire qu'il faut aussi être un expert python pour installer Trac, ce qui n'est pas non plus nécessaire
Personnellement, que Trac est plein de plugins, c'est un faux avantage. D'une part, comme ça déjà été dit, le trac de base est tellement pauvre qu'il faut à chaque fois se reinstaller tout les plugins indispensables (beaucoup sont tellement trivial et très utiles qu'on se demande pourquoi ce sont des plugins). Deuxio, il n'y a pas tant de plugins "potables" que ça : pour toutes les fonctionnalités que je voulais avoir, la plupart des plugins qui les offraient plus ou moins étaient soit obsolètes (pour des versions plus vieilles), soit buggés jusqu'à la moelle, soit complètement nuls.
Bref, ça a été dur d'avoir une install de bug tracker potable. Je ne reutiliserais pas trac avant un bon moment.
Sans oublier que le trac.cgi, c'est une horreur en montée en charge. Dés qu'on a quelques utilisateurs en même temps, ça bouffe presque 100% de CPU. Surement dû au fait que c'est du python d'ailleurs. (sur la même machine, apache ne bronche pas sur les sites PHP pourtant plus visités).
Alors quand je vois ici et là les plaintes sur les perfs de RoR, je me dis que Redmine, c'est pas demain la veille que je l'utiliserais.
Hum... mais ca fait pas déjà une semaine qu'on à commencé a travaillé dessus ? Hein dit ?
@NiCoS: en fait de compétences, j'ai l'impression que RoR utilise tout un écosystème spécifique: son gestionnaire de packages (gem), ses serveurs web, etc, etc. Donc pour l'utiliser correctement il vaut sans doute connaître un minimum cette plate-forme, ses bonnes pratiques, toussa. Alors que le fait que Trac soit en Python est transparent, je ne m'en suis jamais aperçu.
@Laurentj: j'avoue ne jamais avoir eu à me plaindre des perfs de Trac, parce que je l'utilise essentiellement dans un contexte professionel sur des projets d'ampleur limitée, avec peu d'utilisateurs. Je pense que Trac comme Redmine conviennent très bien pour de très nombreux projets en entreprise.
@Chef: si mais j'ai écrit le billet il y a 2 mois, corrigé il y a 2 semaines et ne me suis aperçu qu'il n'était pas en ligne qu'hier. Donc c'est marqué dans l'intro: il est en partie obsolète. Maintenant faut que je m'entraîne à l'utilisation de Mercurial, donc que je te convainque de migrer tous les projets dessus :-P
@Clochix : ah oui vu comme ça, c'est sur que faut se familiariser un peu avec l'écosystème RoR.
@Laurentj : Trac avec mod_wsgi et mod_python, c'est quand même nettement mieux que la version cgi...