Bonjour,
Je suis à la recherche du bug tracker de mes rêves. Ce BTS doit avant tout pouvoir se connecter à LDAP pour l'authentification. C'est indispensable. Idéalement, il pourrait également gérer une liste d'utilisateurs "locaux".
Ce BTS doit être multi-projet avec la possibilité que certains projets ne soient visibles que par les membres dudit projet.
Techniquement, ce BTS doit tourner sur un serveur Apache/Php/Python/Perl. Pas de Java disponible.
Ah oui, ce BTS doit être utilisé par des non-geeks et leur permettre de rapporter des problèmes facilement. Bugzilla n'est donc à priori pas une option.
Premier candidat : http://www.mantisbt.org/
Mantis a, sur le papier, tout ce qu'il me faut (excepter de pouvoir avoir des utilisateur locaux non LDAP). En plus, Mantis est packagé dans Debian et Ubuntu, ce qui facilite grandement la maintenance, et la prochaine version supportera l'export d'un graphe de dépendances vers Freemind. Le pied absolu !
Problème : En fait, le support LDAP de Mantis est complètement pourri. Il faut que les utilisateurs LDAP soient manuellement créés dans la DB mantis. De plus, ce support LDAP est considéré comme particulièrement buggué et peu sûr. Il se révèle que Mantis avec LDAP est tout simplement inutilisable pour le moment. Le support LDAP affiché sur la page d'accueil est tout à fait mensonger.
Dommage...
Second candidat : http://etraxis.sourceforge.net/
Tout beau, tout propre, eTraxis est vraiment joli et tout simple. En plus, il gère très bien les utilisateurs LDAP+les utilisateurs locaux, c'est parfait. Tout est parfait ?
Sauf que voilà, sous une apparente simplicité, après 20 minutes à deux dessus, on n'a toujours pas trouvé comment repporter un bug. Il s'avère que visiblement il nous manque le boutton "rapporter". De plus, eTraxis jongle avec des concepts de "modèles" qui nous sont complètement obscurs. eTraxis semble plus être une machine à décrire un BTS qu'un réel BTS. De plus, eTraxis lui-même ne s'utilise pas lui-même comme BTS ce qui fait un peu peur (ils utilisent celui tout pourri de SourceForge).
Bref, après 1/2h on a abandonné car on comprenait rien (et que, par essence, cela risque d'être le cas de nos utilisateurs non-geeks, même si ils ne doivent pas administrer)
Bilan : nul
Alors cher journal, qu'as-tu à me proposer dans ta hotte pour continuer mes tests de BTS connectés à LDAP ? Merci d'avance !
Je suis à la recherche du bug tracker de mes rêves. Ce BTS doit avant tout pouvoir se connecter à LDAP pour l'authentification. C'est indispensable. Idéalement, il pourrait également gérer une liste d'utilisateurs "locaux".
Ce BTS doit être multi-projet avec la possibilité que certains projets ne soient visibles que par les membres dudit projet.
Techniquement, ce BTS doit tourner sur un serveur Apache/Php/Python/Perl. Pas de Java disponible.
Ah oui, ce BTS doit être utilisé par des non-geeks et leur permettre de rapporter des problèmes facilement. Bugzilla n'est donc à priori pas une option.
Premier candidat : http://www.mantisbt.org/
Mantis a, sur le papier, tout ce qu'il me faut (excepter de pouvoir avoir des utilisateur locaux non LDAP). En plus, Mantis est packagé dans Debian et Ubuntu, ce qui facilite grandement la maintenance, et la prochaine version supportera l'export d'un graphe de dépendances vers Freemind. Le pied absolu !
Problème : En fait, le support LDAP de Mantis est complètement pourri. Il faut que les utilisateurs LDAP soient manuellement créés dans la DB mantis. De plus, ce support LDAP est considéré comme particulièrement buggué et peu sûr. Il se révèle que Mantis avec LDAP est tout simplement inutilisable pour le moment. Le support LDAP affiché sur la page d'accueil est tout à fait mensonger.
Dommage...
Second candidat : http://etraxis.sourceforge.net/
Tout beau, tout propre, eTraxis est vraiment joli et tout simple. En plus, il gère très bien les utilisateurs LDAP+les utilisateurs locaux, c'est parfait. Tout est parfait ?
Sauf que voilà, sous une apparente simplicité, après 20 minutes à deux dessus, on n'a toujours pas trouvé comment repporter un bug. Il s'avère que visiblement il nous manque le boutton "rapporter". De plus, eTraxis jongle avec des concepts de "modèles" qui nous sont complètement obscurs. eTraxis semble plus être une machine à décrire un BTS qu'un réel BTS. De plus, eTraxis lui-même ne s'utilise pas lui-même comme BTS ce qui fait un peu peur (ils utilisent celui tout pourri de SourceForge).
Bref, après 1/2h on a abandonné car on comprenait rien (et que, par essence, cela risque d'être le cas de nos utilisateurs non-geeks, même si ils ne doivent pas administrer)
Bilan : nul
Alors cher journal, qu'as-tu à me proposer dans ta hotte pour continuer mes tests de BTS connectés à LDAP ? Merci d'avance !
> Lire le journal (75 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #955121.
Run by 
Cette page a été générée par Templeet en 0.1183s (dont 0.0116 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Redmine
Salut,
je te conseille Redmine que j'ai mis en place pour mon boulot et qui fonctionne vraiment très bien.
Je n'ai pas testé la fonction LDAP mais apparemment ça le gère.
Malgré une installation moins rapide qu'un "apt-get install redmine", ça ce fait et le fonctionnement est vraiment au poil.
http://www.redmine.org/
http://www.redmine.org/wiki/redmine/RedmineInstall
La plus grosse source de bug est dû au composant situé entre la chaise et le clavier.
[ Répondre ]
[^]Re: Redmine
Effectivement, je surenchéris sur redmine.
De mon coté, je n'avais pas utilisé LDAP, trop pénible avec les règles de sécurité imposée ici, mais notre SSO. N'y connaissant rien en RoR, j'avais trouvé l'ensemble tout à fait génial.
Cela dit, LDAP est implémenté, un peu salement pour le moment (plus ou moins en dur, ce qui rend l'ajout de nouveaux backends assez pénible), mais ça devrait être rapidement corrigé.
Un véritable trac-killer, et ce n'est pas peu dire.
Redmine dispose en plus de quelques nouveaux plugins sympathiques, du genre "time tracking".
[ Répondre ]
[^]Re: Redmine
Je confirme pour Redmine, ça marche super avec un LDAP (un AD en fait) ...
[ Répondre ]
[^]Re: Redmine
Je plussoie Redmine.
Facile à installer aussi bien sur Win$ que sur une distrib Linux (Ubuntu, par ex.). Et franchement, moi qui ne connaît rien de rien à Ruby et donc à RoR, l'install ne pose vraiment pas de problème.
Il y a là :
http://blog.bmaron.net/index.php?post/2008/01/16/Redmine-un-(...)
de quoi te guider dans l'install.
Sinon, j'ai aussi trouvé une présentation :
http://www.slideshare.net/elefevre/cours-du-soir-redmine-val(...)
D'autre part, comparé à Trac, la personnalisation est bien plus aisée. Sans vouloir "troller", Trac serait plutôt un truc de "geek" comme l'était un soft proprio (et cher !) que j'ai eu à administrer et personnalisé ... à coup de scripts perl.
C'est lourd.
Redmine offre une interface très intuitive pour personnaliser les workflow ou les champs des tickets. C'est quand même un plus. Surtout si tu as des "clients" un peu pénibles (genre une équipe qualité ...) qui imposent de fréquentes modifications sur le process de gestion des changements. Faudrait pas, mais quand c'est pas toi qui décide ...
De plus, c'est un véritable outil de gestion de projet, avec intégration SVN (ou autre ...) et donc la liaison entre un tickets et le changeset, raodmap, forum ...etc...
Quant à la possibilité de gérer des droits différents suivants les "clients", si la découpe des projets le permet, tu peux jouer avec les virtual hosts d'apache pour créer des sites avec des droits particuliers.
Mais si tu n'es pas dans un monde idéal ... je ne suis pas sûr qu'il y ait une solution évidente ... à moins peut-être d'écrire un plugin ;)... ou attendre la version 0.8 ... il y a des discussions à ce sujet :
http://www.redmine.org/issues/show/337
Profitez bien de ce jour
J.L.P.
[ Répondre ]
[^]Re: Redmine
Redmine est bien pensé et multiprojects, sincèrement, il est vraiment bien foutu, et le développement est soutenu.
Ne pas oublier que c'est un français qui est à l'origine du projet si je me souviens bien.
[ Répondre ]
[^]Re: Redmine
J'ai aussi eu l'utilisation de Mantis et Trac, Trac est peut-être un peu plus dûr à mettre en oeuvre que Mantis, mais compense énormément par son efficacité et son intuitivité.
Nous étions une équipe de 8 développeurs, à utiliser Mantis avec des utilisateurs externes, Il n'est pas possible de faire de la mise en page dans tes tickets ou réponses, pas moyen d'avoir de Wiki, est-il possible de se connecter à SVN pour comparer des fichiers / révisions ? Je ne sais pas, mais Trac le fait de base.
La recherche se fait sur toute la base de données, alors que dans la version de Mantis dont je disposais, nous ne savions pas le faire. Il n'est pas possible de réaliser des milestones, les filtres de mantis pour les recherches sont parfois défectueux et parfois trop verbeux. Bien trop.
Le thème par défaut n'est pas très attrayant et la dernière fois que j'ai regardé la base de données utilisée par Mantis, celle-ci n'avait pas d'index pour optimiser les recherches. D'ailleurs je pense que c'est en cours dans la version de développement.
Honnêtement, comme candidat, tu as Redmine qui fonctionne très bien, multi-project, multi-utilisateur, graphe de gantt (gestion de projets), etc...
Bien qu'il ne soit pas développé en PHP ou en Python, il suffit d'installer Ruby et de l'installer via un gem.
gem install redmine
[ Répondre ]
[+] [^]Re: Redmine
oui mais justement, je trouve ce truc de gem dégueulasse. Perso, je refuse de faire en root autre chose que apt-get. C'est une règle que je m'impose et je sais très bien ce qui se passe lorsque je ne la respecte pas.
(par contre, en user je fais n'importe quoi, quitte à créer un user rien que pour ça)
Y'a un paquet rails dans Ubuntu donc à priori, cela doit pouvoir être possible mais toutes les doc parlent de compiler gem à partir des sources.
Et moi, je suis désolé, mais si la première page de la doc commence par faire installer GCC, ce n'est pas une solution que je peux me permettre de considérer. Redmine a l'air très bien mais y'a juste RoR qui sucks à mort visiblement. RoR, c'est super pour faire joujou sur sa machine mais ici c'est une machine de prod avec d'autres services indépendants et des impératifs de sécurité et maintenabilité.
[ Répondre ]
[^]Re: Redmine
y'a juste RoR qui sucks à mort visiblement.
C'est toi qui suck à mort.
Déjà tu mélanges l'installation de Gem et de Rails, ça montre bien le niveau.
Gem c'est un mainteneur de librairies Ruby très bien foutu. Et heureusement qu'il est là car même si certaines gem sont packagés dans certaines distrib Linux, j'ai pas envie d'attendre que le mainteneur de ma distribution mette à jour le paquet dès qu'une nouvelle version stable sorte.
Au contraire, je trouve ça bien plus sale d'installer des gems avec apt-get qu'avec gem.
De plus, on parle bien de scripts Ruby, c'est pas comme si c'était du code compilé, je vois pas le problème de sécu.
Et pour finir, si t'es autant parano, rien n'empêche d'utiliser un repository de gem sur un compte d'utilisateur.
Gem installe par défaut son repository dans /usr/share tout simplement pour que tous les utilisateurs aient accès aux librairies Ruby.
Nicolas.
[ Répondre ]
[+] [^]Re: Redmine
Ouaip, ça montre bien le niveau. En tant qu'admin de serveur mais n'étant pas développeur d'appli web, je n'ai jamais été fichu d'installer RoR correctement.
Alors je le dis et le répète : RoR c'est peut-être super pour développer mais ce n'est pas fait pour être installé. Je me fous des concepts de gem ou d'autres bizarreries. Je ne sais même pas ce que c'est un repository gem.
Le jour où on me dira : apt-get tel package et modifie la config du VirtualHost apache de telle manière et que, avec tout ça, l'utilisateur pourra faire sa popote en RoR dans son $HOME, alors là je reverrai mon opinion et à m'excuser (quoique, si c'est le cas actuellement, y'a quand même un gros problème de documentation/mentalité dans la communauté RoR).
Mais tous les howto que je trouve sur le web parle de compiler Gem des sources. Et même si c'est pas un binaire, je n'en ai rien à faire : je ne compile PAS sur un serveur de prod, je n'installe PAS sur un serveur de prod autre chose qu'un .deb ! Ce n'est pas uniquement de la sécurité, c'est surtout de la maintenabilité.
[ Répondre ]
[^]Re: Redmine
RoR c'est peut-être super pour développer mais ce n'est pas fait pour être installé.
Ecoute, t'as l'air de pas du tout connaître Rails, donc évite ce genre de trolls.
Tu mélanges tout : c'est au développeur de l'application Rails de décider s'il intègre toutes les librairies qu'il utilise dans son application ou bien s'il utilise celles du système.
Si le développeur de l'appli intègre toutes les gems et gèle Rails à l'intérieur de son appli, il n'y a rien a installer d'autre que les paquets Ruby standards.
C'est au contraire à ce niveau là que je trouve Rails flexible, il est possible de geler Rails et les gems utilisées à l'intérieur de son appli pour éviter les conflits de version. Rails est ultra-flexible sur ce niveau là.
Nicolas.
[ Répondre ]
[^]Re: Redmine
apt-get tel package et modifie la config du VirtualHost apache de telle manière et que, avec tout ça, l'utilisateur pourra faire sa popote en RoR dans son $HOME
C'est tout-à-fait possible de faire ça avec le mod fcgid d'apache. Rails est packagé dans Debian, et fournit un .htacess, et tout ce qui va bien.
Après le pb, c'est éventuellement les problèmes de versions, et le fait que certains modules ne sont pas packagés en .deb, mais sur ce point, il faut de plaindre auprès des développeurs de ta distribution.
Si ça t'intéresse, je te fais un mini-howto de A à Z pour installer Rails sur apache2/mod_fcgid, et une appli sans dépendances en tant que user.
[ Répondre ]
[^]Re: Redmine
Hello,
désormais le déployement d'une appli RoR via FCGI n'est carrément plus d'actualité depuis que modrails (1) est sorti et qu'il permet de déployer "proprement" une appli Rails en une seule ligne de conf Apache 2.
(1) : http://www.modrails.com/
[ Répondre ]
[+] [^]Re: Redmine
C'est ça qui me fait rire avec RoR. Dès que t'installes un truc, en fait, au final "oui mais faut la version SVN de telle lib" et "oui mais ça, c'est plus d'actualité parce que maintenant y'a mieux".
[ Répondre ]
[^]Re: Redmine
Et même si c'est pas un binaire, je n'en ai rien à faire : je ne compile PAS sur un serveur de prod, je n'installe PAS sur un serveur de prod autre chose qu'un .deb ! Ce n'est pas uniquement de la sécurité, c'est surtout de la maintenabilité.
A défaut de .deb si tu veux des binaires tu peux toujours te rabattre sur ca.
http://bitnami.org/stack/redmine
SI y a bien un truc que je trouve idiot avec les linuxiens de base c'est ce raisonnement qui consiste à dire si y'a pas des .deb, .rpm & et autre sources je prend pas.
Aujourd'hui on vit dans un monde où les interpréteurs en tout genre sont inévitables et je ne vois pas en quoi ca mettrait en péril
Quel est l'intérêt de FF sans les plugins ?
Quel est l'intérêt d'Eclipse sans les plugins ?
Quel est l'intérêt de python , Perl, Java sans les libs associées et les applis au dessus.
Ben la on, te demande d'installer un plugin au dessus de Ruby et c'est le bout du monde hein !
Pas plus que pour les autres tu verras un .deb sortir parce que les devs ont autre chose à faire que packager pour les 600 distribs du monde qui même lorsqu'elles utilisent le même format de package ne sont même pas foutue d'être compatibles entre elles.
Par contre à partir du moment où t'installe l'interprète et ses libs d'installation et ben bizarrement ca marche partout.
Dingue hein.
Allez vous pouvez moinsser maintenant
[ Répondre ]
[^]Re: Redmine
Si, c'est le bout du monde. T'as déjà maintenu un serveur de prod pendant plusieurs années toi ?
Firefox et Eclipse ? C'est en mode utilisateur, si ça foire, tu fais rm -rf ~/.firefox et t'es reparti.
Perl et Python ? Ben toutes les libs sont packagées, suffit de les apt-getter, ça fonctionne très bien, c'est automatiquement mis à jour en cas de problème de sécu, j'ai une liste centralisée de ce qui est installé ou pas sur le serveur.
J'ai l'impression de me répéter depuis 15 messages.
Les devs veulent pas packager pour 600 distrib ? Bah redéveloppons un 601ème système, c'est bien plus malin, ça c'est certain.
[ Répondre ]
[^]Re: Redmine
Pour les modules Perl du CPAN, il est trés facile de créer un paquet Debian grâce à dh-make-perl. Ça aide.
Ensuite, les développeurs ne sont pas non plus des maîtres en tout et il y a de nombreuses applications (pas forcément libres mais aussi des libres) dont j'ai pu voir les limites en support réseau, notamment pour gérer le protocole LDAP correctement.
Avec de nombreux développeurs, on (les admins) a parfois l'impression que l'installation de leurs applications se résume à mettre tout ce qu'il faut dans le répertoire qui-va-bien et plouf, ça marche ! Sauf que ça ne marche pas partout, pour diverses raisons, même en utilisant la méthode de l'autruche.
Après, tu peux déplorer le nombre de distributions mais que dire du nombre de langages de développement, notamment les langages interprétés ou pseudo-interprétés (Perl, PHP, Java, Python, Ruby, etc.).
[ Répondre ]
[^]Re: Redmine
Bon, tu demandes des conseils alors accepte les.
Redmine est certainement ce qu'il y a de mieux dans le domaine, surtout depuis que Trac dépale dans la semoule.
RoR et Redmine s'installe avec une facilité déconcertante, sans truc spécial à compiler. Sous Debian, tu peux même monter un cluster mongrel avec apt et 3 lignes de conf ...
Sinon, et pour finir, je ne connais pas grand chose de la communauté RoR, mais en revanchen je peux affirmer que Jean-Philippe Lang a fait du super boulot sur ce soft et que sa mentalité est tout à fait acceptable.
[ Répondre ]
[^]Re: Redmine
je renchéris, on est passé de TRAC à redmine à mon boulot, et rien à voir. Je te conseil redmine. je comprends tes pb de maj de serveur, mais redmine est vraiment le top. essaye le:)
ebaobab.net - Partagez avec vos amis tout en conservant votre vie privée !
[ Répondre ]
[^]Re: Redmine
Il y a un paquet pour rubygem, dans debian : http://packages.debian.org/etch/rubygems
Tu peux installer des gems (exemple au hasard : redmine) en tant qu'utilisateur sans privilèges, en utilisant l'option -install-dir pour choisir le répertoire de destination.
[ Répondre ]
[^]Re: Redmine
Merci ! Il m'avait échappé en cherchant "ruby on rails" dans les paquets.
15 messages passent leur temps à tenter de me convaincre que j'ai tort de vouloir un .deb et un seul me le fout sous le nez.
Je me sens un peu ridicule mais je me rassure, les autres au-dessus sont dans le même bain que moi :-)
Bravo !
[ Répondre ]
[^]Re: Redmine
C'est vrai on est un peu ridicule.
Sauf que là , c'est la distrib qui empaquette le système d'update de Ruby.
Ce ne sont pas les devs de RoR qui doivent se coltiner toutes les distribs de la création.
Tout est dans l'ordre logique des choses.
Un systéme d'install indépendant de la plateforme en dessous et pour ceux qui le souhaitent lorque la distrib le permet l'integration du système dans celui de la distrib.
Ceux qu'il fallait viser dans tes critiques ou tes suggestions n'étaient donc pas les dev Ruby mais bien les mainteneurs de ta distrib préférée.
Tout le monde est heureux maintenant.
[ Répondre ]
[^]Re: Redmine
s/en dessous/au dessus/
[ Répondre ]
[^]Re: Redmine
Faut dire que ce paquet a mis du temps à être dispo sous Debian. Voir http://pkg-ruby-extras.alioth.debian.org/rubygems.html pour les raisons qui étaient invoquées.
Ces arguments ne m'ont pas convaincu du tout, d'ailleurs : le fait qu'il y ait des milliers de libs/applis ruby sous le même format de fichier (gem) rend forcément plus simple le packaging en .deb, puisque ça le rend automatisable. Tout comme le fait que des milliers de libs/applis utilisant le toolchain GNU facilite le packaging en .deb.
[ Répondre ]
[^]Re: Redmine
J'ai jeté un coup d'oeil à Redmine (je ne connaissais pas), et je me rend compte que le déploiement est beaucoup moins aisé que ce que je présumais.
Je pensais que Redmine serait fourni sous forme de gem, avec une dépendance sur le gem de Rails. Eh bien non, Redmine ne fournit que des sources Ruby à copier vers une installation de Rails déjà existante, comme le ferait un plugin.
Du coup, je comprend mieux la réaction de Ploum : en l'état, pour déployer Redmine, il faut un minimum comprendre le fonctionnement de Rails. Et ça, c'est trop demander pour des utilisateurs finaux (même pour moi, qui connait Ruby mais pas Rails).
[ Répondre ]
[^]Re: Redmine
Voici ce que j'ai utilisé pour installer redmine il y a peu sur un jeos
C'est pas forcément à prendre tel quel, mais pour autant je trouve pas ça trop compliqué, même sans être un pro de rails :
(Installation de svn + authentification dav + redmine)
#!/bin/sh
sudo aptitude install wget subversion subversion-tools apache2-mpm-prefork libapache2-svn apache2-prefork-dev ruby rdoc irb libyaml-ruby ruby1.8-dev libzlib-ruby ri rubygems libmysqlclient15-dev mysql-client mysql-server
sudo mkdir /var/svn
cd /var/svn
sudo svnadmin create repo
sudo chown www-data /var/svn -R
sudo chmod 775 /var/svn -R
sudo cat<<EOF > /etc/apache2/sites-available/svn
<location /svn>
DAV svn
SVNParentPath /var/svn
AuthType Basic
AuthName "Repository"
AuthUserFile /var/svn/repo.htpasswd
AuthzSVNAccessFile /var/svn/users.authz
Require valid-user
</location>
EOF
sudo a2ensite svn
sudo /etc/init.d/apache2 force-reload
sudo gem update
sudo gem update --system
sudo gem install rails mysql passenger
sudo /usr/bin/passenger-install-apache2-module
sudo cat <<EOF > /etc/apache2/apache2.conf
## passenger
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.0.2/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.0.2
PassengerRuby /usr/bin/ruby1.8
EOF
echo "create user \"redmine\"@\"localhost\" identified by \"redmine\";create database redmine default character set utf8 collate utf8_general_ci;grant all privileges on redmine.* to \"redmine\"@\"localhost\" identified by \"redmine\" with grant option;" | mysql -u root -p
cd /var/www && sudo wget http://rubyforge.org/frs/download.php/39477/redmine-0.7.3.ta(...)
sudo tar xf redmine-0.7.3.tar.gz
sudo mv redmine-0.7.3 redmine
cd redmine && sudo cp config/database.yml.example config/database.yml
# update configuration !
sudo /etc/init.d/mysql start
sudo rake db:migrate RAILS_ENV="production"
sudo rake redmine:load_default_data RAILS_ENV="production"
cd /etc/apache2/sites-available
sudo cat<<EOF > redmine
<VirtualHost *>
serverpath /redmine
servername my.server.plop
DocumentRoot /var/www/redmine/public
Options +FollowSymlinks +ExecCGI
</VirtualHost>
EOF
sudo a2dissite default
sudo a2ensite redmine
sudo a2enmod rewrite
sudo /etc/init.d/apache2 force-reload
[ Répondre ]
[^]Re: Redmine
Petite note pour éviter de se retrouver avec la dernière version de rails (incompatible avec redmine 0.7.3), il faut utiliser :
sudo gem install rails --version '=2.0.2'
(on peut aussi utiliser le dossier vendor/ de redmine pour y placer rails)
[ Répondre ]
[^]Re: Redmine
comme beaucoup, je te conseil de regarder redmine.
Je viens de migrer pour ma boite un flyspray vers redmine, et c'est vraiment beaucoup mieux.
Précédemment j'utilisais trac, mais je trouve l'installation (et la config) plus lourde que redmine
La gestion multi projet est vraiment facile à mettre un oeuvre.
On peut également demander à redmine de s'occuper intégralement du repository (si svn) ce qui est assez sympa si on gère un repo par projet
Par contre, ce qui est parfois domage c'est de ne pas avoir trop de communication entre les projets (par exemple un bug renseigné sur le mauvais projet peut être déplacé sur le bon, mais ne permet pas - en une fois - le choix des catégories par exemple)
Il est également possible d'écrire des scripts de migration depuis d'autres bug trackers (mantis et trac en standard, dans ./lib/tasks/migrate_from_*.rake) et en écrire d'autre est assez simple (surtout grâce à ActiveRecord ;-) )
Version courte : redmine c'est comme trac mais en plus mieux !
[ Répondre ]
[^]Re: Redmine
Je plussoie pour Redmine !
Je l'utilise actuellement pour un petit projet perso : http://dev.euphorik.ch/projects/show/euk
Au boulot on utilise Mantis et Bugzilla. Je préfère de loin Redmine bien que le projet soit un poil jeune... mais très dynamique ;)
Points positifs (en vrac, j'en oublie surement plein)
- intégration d'une navigation SVN/git/Mercury (je n'ai testé que SVN et elle convient très bien)
- Wiki avec la syntaxe Textile, très puissant
- Workflow du statut d'une demande personnalisable par rôle
- Forum intégré
- Planification : gant et cie.
- Repporting : chaque dev peut dire combien de temps il a passé sur une tâche
- Gestion des versions avec roadmap
- Base de données à choix, pour moi c'est du PostgreSQL
- Multiprojet
- etc.
Points négatifs :
- On ne peut pas finement attribuer des droits, par exemple on voudrait que les clients ne voient que leurs demandes et que certains champs.. Ca va venir en partie avec la 0.8 (demandes privées).
[ Répondre ]
[^]Re: Redmine
J'ai essayé Redmine ici et je confirme que l'installation n'est pas une sinécure, et pourtant je suis familier de Ruby et RoR (mais pas du deploiement d'applis RoR en revanche).
C'est vrai que c'est bien fichu et un peu mieux que trac, par contre qu'est-ce que c'est lent ! Que ce soit avec Webrick ou bien Mongrel, les pages mettent de longues secondes à se charger. De plus l'appli "meure" après quelques heures d'utilisation et il faut la redémarrer.
Donc un projet très prometteur mais qui demande encore à être stabilisé, optimisé et mieux packagé. J'y reviendrais dans quelques mois !
[ Répondre ]
[^]Re: Redmine
Oui je suis d'accord que le projet est encore assez jeune, il existe néanmoins de la doc concernant l'installation : http://www.redmine.org/wiki/redmine/FrRedmineInstall .
Par contre j'utilise Webrick sur le site dont j'ai posté le lien et je n'ai jamais eu besoin de le redémarrer, aucun problème de stabilité. Il est vrai que c'est plutôt lourd (il me prend environ 100Mo de mémoire vive) et moyennement réactif. J'avoue ne pas avoir cherché à le configurer.
[ Répondre ]
[^]Re: Redmine
euh, juste une question bete.
N'oubliez pas que Rails n'est pas thread-safe de base et donc qu'il nécessite un load-balancer avec multi-process du coté serveur d'hébergement. Si vous utilisez un webrick ou un mongrel, il ne pourra gérer qu'une requete à la fois, donc si un gus upload un fichier ça bloque les autres...
Pourquoi vous embeter à héberger une appli rails avec 1 process Mongrel ou encore pire webrick alors que mod_rails permet d'héberger n'importe quelle appli rails avec apache 2 en 1 ligne de configuration ?
Surtout que mod_rails a été pensé à la base pour gérer de manière optimisée l'accès à la mémoire, etc.
Pensez-y avant de critiquer une appli Rails alors que le problème vient plutôt de votre manière de l'héberger. Il est vrai que l'hébergement des applis Rails n'a pas toujours été une sinécure mais désormais c'est vraiment très simple et fiable.
[ Répondre ]
[^]Re: Redmine
Euh, les "green threads" de Ruby sont quand même préemptibles, de ce fait je pense bien que des serveurs comme Webrick peuvent gérer plusieurs requêtes simultanément.
Par contre il est vrai qu'il ne tirera pas forcément partie d'un système multi-core ce qui ne m'incommode pas trop.
J'ai utilisé Webrick car il est preconfiguré avec Redmine et qu'il me suffit amplement. Je n'ai pas envie d'installer Apache juste pour ça...
Et si je peux me permettre, Rails ça a peut-être plein d'avantages mais ça reste relativement lent même avec Apache.
[ Répondre ]
[^]Re: Redmine
En fait j'ai simplement essayé dans l'ordre les méthodes de déploiement indiquées dans la doc du projet, ce ne sont pas particulièrement "mes" méthodes ;-) Pour info j'ai testé avec trois processus Mongrel derrière un Apache, comme indiqué dans la doc.
À vrai dire, j'avais connaissance de la possibilité d'utiliser mod_rails mais je n'ai pas essayé par manque de temps. J'ai pensé que suivre les méthodes recommandées sur le site de Redmine était un choix raisonable.
Est-ce beaucoup plus performant sous mod_rails ? Il faudrait que les performances soient 2 ou 3 fois meilleures pour que ça devienne utilisable. Notre code source est stocké sur un VPS qui n'est pas un foudre de guerre. Trac y est cependant utilisable, lui.
[ Répondre ]