2008-11-06 5 views
10

Nous utilisons trac et sommes vraiment satisfaits. Cependant, prêt à l'emploi, trac est le mieux adapté aux environnements à projet unique uniquement. Je serais intéressé d'entendre parler des différentes approches que les gens adoptent pour le faire fonctionner malgré tout avec plusieurs projets et leurs expériences avec eux. Y a-t-il des plugins à recommander? Des patchs, des tweaks ou des whatnots? Est-ce que vous utilisez peut-être même un système de suivi des bogues entièrement différent qui offre toutes les fonctionnalités de trac et un support multi-projets?Comment gérez-vous plusieurs projets (chevauchement) dans trac?

Nous avons récemment commencé à gérer nous-mêmes un second projet qui fonctionne généralement bien, mais présente également certains inconvénients, en particulier lorsque les deux projets se chevauchent en raison du code de bibliothèque commun utilisé dans les deux projets. Comment gérez-vous cela?

(je vais joindre notre approche actuelle comme une réponse à ce poste.)

Répondre

9

L'approche que nous avons est de créer un environnement de trac pour chaque nouveau projet et mettre en place InterTrac liens pour les références croisées plus simple entre les deux. Nous utilisons également un fichier de base commun Trac.ini via la directive [inherit].

Outre les questions d'ambiguïté avec le code partagé mentionné dans la question, il a quelques inconvénients qui peuvent ou peuvent ne pas vous affecter, selon la nature de vos projets et votre flux de travail:

  • création de nouveaux projets Ce n'est pas un processus facile. il ne peut se faire via l'interface du navigateur
  • numéros de billets ne sont pas unifiés: chaque nouvel environnement de projet commence frais de # 1 - au moins avec des alias InterTrac vous pouvez facilement les désambiguïser
  • vous devez prendre des précautions supplémentaires lors de l'installation et configurer les plugins afin qu'ils soient installés et configurés pour tous les environnements
2

Une alternative que nous avons suivie est de configurer différents projets en tant que composants. Nous partageons le référentiel SVN et la page du wiki d'accueil, mais nous n'utilisons pas les fonctionnalités des jalons. Si le projet est assez grand pour avoir différents modules (un seul dans notre cas), nous configurons chaque module comme un composant à la place du projet.

+0

C'est ce que je fais. J'utilise des composants comme celui-ci: "Project: Component" –

+0

OK, alors comment gérez-vous les jalons et les versions dans cette configuration, c'est-à-dire comment les associez-vous aux projets (/ components)? utilisez-vous une convention de nommage ou quelque chose comme ça? –

+0

également, gérez-vous également des sous-composants? –

1

Même sensation ici, Trac est vraiment agréable une fois configuré correctement. Et c'est facilement piratable sans toucher à aucun code. Je souhaite seulement que la syntaxe wiki soit quelque chose de plus commun, comme markdown.

Nous avons pris l'approche d'utiliser une instance de Trac. Nous n'avons pas besoin/ne voulons pas utiliser ACL serré et il a l'avantage de garder toutes les activités des développeurs en un seul endroit.

Pour séparer des projets, nous assignons essentiellement des bogues à différents jalons. Chaque projet a une étape à court et à long terme. Le court terme est utilisé pour corriger les bugs réels et à long terme pour les versions majeures.

La plupart des autres champs "new ticket" ont été supprimés, en conservant les champs "type" et "severity", qui sont identiques sur tous les projets. Les rapports sont essentiellement limités à "Mes tickets", et le bouton "Afficher le rapport" a été modifié pour accéder directement à vos tickets.

Le workflow a également été adapté pour ajouter un statut intermédiaire de "test", de sorte que QA puisse garantir la fixation.

La configuration de la messagerie a été modifiée pour ne pas inonder les boîtes aux lettres, de sorte que les développeurs lisent réellement leurs affectations.

Avec cela en place, nous avons un outil assez efficace. Il a fallu du temps pour le faire correctement, mais il est facile de changer les choses si vous savez comment bidouiller et chercher des choses sur google.

2

Il ya environ un an, SimpleMultiProjectPlugin (prise en charge de plusieurs projets dans une instance Trac) a été implémentée. Il fonctionne avec> = Trac 0.12. Il ajoute un nouveau champ de projet «projet», étend la page de calendrier et de feuille de route avec des filtres pour plusieurs projets et ses versions de cartes, des composants et des jalons aux projets.

1

Le Apache Bloodhound project a été démarré spécifiquement pour apporter le support de plusieurs projets à Trac (entre autres). C'est essentiellement une collection de plugins sur Trac. Bloodhound reste compatible avec la plupart des populaires Trac-Hacks et suit les changements apportés à Trac lui-même. Vous pouvez aussi essayer the demo instance.

+0

J'ai joué sur votre site Test, et est-ce que les jalons ne sont pas encore pris en compte par ces produits? J'ai manqué quelque chose comme une feuille de route d'un produit où ses jalons sont répertoriés. Bien que bon travail et intéressant, au moins depuis que j'ai découvert que Bitnami héberge également une pile Bloodhound Trac bien qu'il ne soit pas clair si cela contient aussi SVN. – falkb

+0

@falkb: La feuille de route est encore en cours, mais je crois qu'elle sera réintroduite dans notre prochaine version cette semaine. Je n'ai pas travaillé sur cette fonctionnalité, donc c'est mieux si vous demandez sur notre liste de diffusion si vous avez plus de questions à ce sujet. –

Questions connexes