Trac vs. Redmine

Question

Je travaille dans le domaine de la recherche et mon groupe de travail en bioinformatique a besoin d'un logiciel de gestion de projet pour assurer le suivi de plusieurs projets (environnement Linux). À l'origine, nous avions prévu d'utiliser TRAC, mais j'ai ensuite entendu parler de REDMINE. De plus, j'ai lu dans des articles datant de 2008 et 2009 que de nombreux projets avaient adopté Redmine. Pour l'instant, je ne trouve aucune comparaison actualisée ou fiable entre les deux systèmes et je ne peux donc pas dire lequel est le meilleur (les deux sont peut-être aussi bons l'un que l'autre).

Ma question :

Est-ce que l'un d'entre vous a récent Vous avez de l'expérience dans l'un de ces systèmes, voire dans les deux, et vous pouvez indiquer quelques (gros) avantages/désavantages de Redmine ou de Trac (ou même des deux) ?

Les exigences sont les suivantes :

• Support de svn et/ou dcvs (Git)
• gestion des documents
• billetterie
• suivi des bogues
• wiki / blog interne (c'est-à-dire gestion des connaissances)
• soutien aux projets multiples
• l'installation doit être aussi simple que possible
• il ne devrait pas y avoir des centaines de plugins à installer avant d'avoir un logiciel de gestion de projet utilisable et opérationnel (l'installation de base devrait avoir la plupart des fonctionnalités)

Merci beaucoup pour votre temps ! Cheers

Answer 1

Je privilégierais Trac. J'utilise Trac depuis longtemps, plus de 7 ans maintenant. J'ai également travaillé 3 ans avec Redmine. Les dernières versions que j'ai utilisées en production étaient : Trac 1.0.1 et Redmine 2.2.3. Mais Redmine présente de sérieux inconvénients par rapport à Trac :

1. Installation n'est pas facile :

   1. Vous ne pouvez pas utiliser le système de paquets Debian/Ubuntu pour la production.

      • Comme la configuration n'est pas séparée du code de l'application, chaque fois que vous recevez des mises à jour du paquet, elles écrasent vos modifications.
      • Debian avait 5 failles de sécurité au début de 2013 (janvier), où un peu de toujours non corrigé dans unstable et testing. Bien sûr, les corrections dans Debian stable sont faites, les versions des paquets sont tellement dépassées dans stable, que les versions plus récentes de Redmine ne fonctionneront pas.
      • Les dépendances de Redmine sont fixes, donc les nouvelles versions des bibliothèques peuvent ne pas fonctionner. C'est la raison pour laquelle vous devez configurer votre apt-get ou aptitude pour ne pas mettre à jour certaines dépendances.
   2. Je vous conseille d'installer via gem y bundler . Pourtant, cela a été aussi facile que décrit sur la page d'accueil. Mais ce que je déteste le plus dans ces systèmes de gestion des paquets logiciels, à part la gestion des paquets systèmes, c'est qu'il faut s'occuper des mises à jour et de tous les autres trucs séparément. Certaines personnes suggèrent RVM fournir des environnements ruby virtuels, où vous pouvez avoir plusieurs versions de Rails installées les unes à côté des autres, ce qui n'est pas possible avec apt-get. Je ne me sens pas bien avec ça, mais au moins ça fonctionne.

2. Administration n'est pas facile, pensez à faire une sauvegarde : Dans Trac, cela se fait en une seule fois, dans Redmine, vous devez sauvegarder : la configuration, les fichiers joints et le contenu de la base de données, tous séparément. En outre, il est souvent indiqué que Redmine prend en charge plusieurs projets, il est donc plus facile de configurer un nouveau projet et la configuration n'est pas dupliquée. Voir ci-dessous, il y a un paragraphe supplémentaire sur le support des projets multiples. Enfin, lorsque j'administre un projet Trac, j'aime modifier les fichiers de configuration en texte clair. Dans Trac, il n'y a que un un tel fichier que vous devez regarder : trac.ini .

3. Configuration est cassé : Par exemple, vous pouvez créer des routes personnalisées dans Redmine, qui affichent la page wiki de départ et non la vue d'ensemble du projet comme première page. Il vous sera recommandé d'éditer les sources de Redmine ! C'est très dangereux car la prochaine mise à jour écrasera votre configuration. Ce type de configuration n'était donc pas vraiment prévu. Mais un bon outil devrait séparer la configuration du code source de l'application.

4. Fonctions wiki manquantes : Certaines fonctionnalités importantes du wiki sont manquantes en raison d'un bug non corrigé lié à une vulnérabilité XSS. (par exemple, voir le balisage du wiki textile). Vous ne pourrez donc pas placer de commentaires à l'intérieur des pages du wiki, rendre les images dans une taille personnalisée,...

5. Protection anti-spam manquante : Oui il existe un plugin reCaptach périmé, mais il ne fonctionne plus. En particulier, le fork protège également les pages de problèmes. Par rapport à Trac qui dispose d'un plugin SpamFilter qui a propriétés fantastiques c'est un échec. Personne ne veut supprimer le spam manuellement.

De nombreux points critiques ont été soulevés au fil du temps et ont fait dire aux gens que Redmine était meilleur. J'en doute :

1. Support multi-projets : Bien sûr, Trac fournit de multiples projets, chacun ayant sa propre configuration, et c'est très utile : Envisagez de faire un projet à source fermée et un autre à source ouverte. Pour le projet closed source, vous cacherez probablement le dépôt, mais pas pour le projet open source, ce qui n'est pas possible avec Redmine. De plus, avec Trac vous pouvez sauvegarder les projets séparément et bien sûr vous pouvez les séparer au cas où l'un de vos 50 projets deviendrait populaire et aurait besoin de son propre serveur ! Redmine ne peut pas faire cela. Récemment, un nouveau plugin est apparu, permettant de gérer plusieurs projets d'utilisateurs dans une seule instance de Trac. http://trac.edgewall.org/wiki/PluginList#MultipleProjects

   De plus, il existe un projet utilisant Trac pour construire cette fonctionnalité : Chien de sang

2. Système de contrôle des versions : Je pense que l'installation d'un plugin n'est pas si difficile, et pour presque chaque VCS il y a un plugin pour Trac : Git, Perforce, Mercurial, Darcs, Monotone, Subversion, Bazaar. De plus, je préférerais un petit framework de base avec des plugins plutôt qu'un gros framework avec un support intégré pour Git, Mercurial, etc... Une telle architecture n'est pas modulaire. Donc mettre le support VCS dans les plugins est le moyen de le faire. Pas d'intégrer tout dans le framework.

3. Plugins : Je dirais que Trac et Trac-Hacks ont beaucoup plus de plugins que Redmine, donc l'intégration de Doxygen, Jenkins, Latex, BibTex, etc. ne pose aucun problème !

4. Timing et estimation : Il y a des plugins pour ça dans Trac aussi ! Dans l'ensemble, je ne comprends pas le récent Trac-bashing, il est également écrit dans un langage d'interprétation à la mode (python), il a presque les mêmes fonctionnalités.

Le processus d'installation de Redmine n'est pas facile, mais l'installation de Trac est également devenue plus complexe ces derniers temps, de sorte que la création manuelle de bases de données, etc. ne peut plus être considérée comme un inconvénient.

Enfin, les deux projets utilisent un système de plugins. Le problème que rencontre souvent l'utilisateur de ces plugins est qu'ils peuvent être orphelins et ne pas supporter le framework actuel. Cela m'est arrivé plus d'une douzaine de fois pour Redmine, mais aussi parfois pour Trac. Mais mon impression très subjective est que les plugins cruciaux n'ont jamais été affectés par ce type de problème et que cela s'est produit un peu moins souvent avec Trac.

Enfin, dernier point mais non des moindres, je vais essayer de Phabricator car il offre un flux de travail intégré pour la révision du code.

Answer 2

J'utilise Redmine et ... j'aime ça ;)

• svn et git fonctionne très bien, il a plus de repos en œuvre (Darcs, Mercurial, Cvs, Bazar, le système de fichier ??? ), mais je n'ai pas essayé de les utiliser
• à propos de l'installation - dans mon cas, automatique installator sur mon hébergement, je ne peux pas dire une chose, vous devriez être en mesure de trouver de nombreux tutoriels
• billetterie / suivi des bogues - je pense que, pour les deux RM et le Trac c'est la principale fonctionnalité, donc trop de choses à écrire sur ;) vous pouvez configurer des rôles, lien des utilisateurs ou des groupes de projet, en précisant le rôle de chaque vous pouvez spécifier votre propre question (billet d'avion), de type, par exemple. bug, nouvelle idée, question de priorités vous avez diagramme de gantt (vous pouvez spécifier la date limite pour chaque question), vous pouvez lier chaque billet avec la version de votre projet ... beaucoup, beaucoup de fonctionnalités ici
• plusieurs soutien de projet - vous pouvez avoir plusieurs projets en lien avec un ( je veux dire la même chose ) ou plus de repos ( max one repo par projet )
• la gestion des documents / wiki / blog interne - havent utilisé cette fonctionnalité, mais oui, RM a quelque chose pour la doc de la gestion et de wiki module
• 100 de plugin ... je n'en ai pas et encore il y a trop d'options de configuration :P

Answer 3

Chez BitNami, nous fournissons des installateurs et des VMs gratuits pour Trac y Redmine . Redmine est certainement beaucoup plus populaire, mais Trac devient de plus en plus populaire, en particulier avec l'arrivée de la version 1.0. Puisque vous avez mentionné la prise en charge de Git ou de DVCS, vous pourriez également être intéressé par les éléments suivants Gitorious o Gitlab

Answer 4

Je travaille beaucoup avec redmine, et j'adore ça !

1. Support de svn et/ou dcvs (Git)

   j'ai compris les deux. si vous ajoutez le numéro de ticket au message de commit, le commit apparaîtra très élégamment dans le ticket, c'est une de mes fonctionnalités préférées en tant que développeur :)

2. gestion des documents

   Je l'ai aussi, mais juste très minimaliste. Vous pouvez télécharger des fichiers vers des tickets et des projets (séparément), mais vous ne pouvez pas les rechercher (par exemple).

3. billetterie, suivi des bogues, wiki

   oui, oui et... oui :) J'aime la syntaxe pour écrire des billets ou d'autres contenus textuels, un peu similaire à la syntaxe de stackoverflow.com.

4. soutien aux projets multiples

   Vous pouvez bien sûr créer des projets, des sous-projets, des sous-sous-projets.... avec des droits d'accès différents si nécessaire. Vous pouvez aussi faire cette cascade avec les tickets.

5. installation et plugins

   Je n'ai jamais installé une instance de redmine, et je n'ai aucune expérience avec ruby. Je suis juste un utilisateur de redmine - mais je sais qu'il est possible d'écrire ses propres extensions (mon entreprise en a écrit une pour ses propres besoins, pour étendre le suivi du temps).

Conclusion : J'utiliserai toujours Redmine lorsque j'aurai besoin d'un système de tickets !

Mise à jour : Parfois, j'utilise aussi l'intégration des problèmes des hébergeurs de code comme bitbucket ou github. Redmine est la plus grande solution que j'ai utilisée. Trello est également une alternative, que j'aime utiliser pour gérer les tâches des clients (vous pouvez créer des équipes), lorsque peu de personnes sont impliquées et que le projet n'est pas si important.

Answer 5

Redmine est l'outil de gestion de projet le plus simple qui soit, point final ! facilité d'acquisition, facilité d'installation, facilité de configuration, facilité d'utilisation et facilité d'intégration !