2008-11-06 19 views
10

Używamy trac i jesteśmy z niego naprawdę zadowoleni. Jednak po wyjęciu z pudełka, system trac najlepiej nadaje się tylko do środowisk z jednym projektem. Chciałbym usłyszeć o różnych podejściach, jakie podejmują ludzie, aby pracować z wieloma projektami i ich doświadczeniami z nimi. Czy są jakieś wtyczki do polecania? Jakieś łatki, poprawki lub czegokolwiek? Czy może używasz zupełnie innego systemu śledzenia błędów, który oferuje całą funkcjonalność trac oraz obsługę wielu projektów?Jak radzić sobie z wieloma (nakładającymi się) projektami w trac?

Niedawno zaczęliśmy sami zarządzać drugim projektem, który generalnie działa dobrze, ale ma również pewne wady, zwłaszcza gdy dwa projekty nakładają się na siebie z powodu wspólnego kodu bibliotecznego, który napisaliśmy, który jest używany w obu projektach. Jak sobie z tym poradzić?

(będę dołączyć własne podejście bieżący jako odpowiedź na tego posta.)

Odpowiedz

9

Podejście wzięliśmy jest stworzenie innego środowiska trac dla każdego nowego projektu i skonfigurować InterTrac linki do prostsze odsyłaczy między dwójka. Używamy również wspólnego pliku bazy Trac.ini za pośrednictwem dyrektywy [dziedziczymy].

Oprócz problemów niejednoznaczność z kodu udostępnionego mowa w pytaniu, to ma kilka wad, które mogą lub nie mogą mieć wpływ na ciebie, w zależności od charakteru swoich projektów i przepływu pracy:

  • tworząc nowe projekty nie jest łatwym procesem; nie można tego zrobić za pomocą interfejsu przeglądarki
  • Numery biletów nie są ujednolicone: każde nowe środowisko projektu zaczyna świecić od numeru 1 - przynajmniej z aliasami InterTrac, które można z łatwością je rozróżnić
  • należy zachować szczególną ostrożność podczas instalowania i konfigurowanie wtyczek, aby zostały zainstalowane i skonfigurowane dla wszystkich środowisk.
2

Alternatywą, którą stosowaliśmy, jest konfigurowanie różnych projektów jako komponentów.

Udostępniamy repozytorium SVN i domową stronę wiki, ale nie korzystamy z funkcji przełomowych. Jeśli projekt jest wystarczająco duży, aby mieć różne moduły (tylko jeden z nich w naszym przypadku), konfigurujemy każdy moduł jako komponent zamiast projektu.

+0

To właśnie robię. Używam takich komponentów: "Projekt: Komponent" –

+0

OK, więc w jaki sposób obchodzić etapy i wersje w tej konfiguracji - czyli w jaki sposób kojarzysz je z projektami (/ komponentami)? czy używasz konwencji nazewnictwa lub czegoś w tym stylu? –

+0

również, czy też obsługujecie podzespoły? –

1

To samo uczucie, Trac jest naprawdę fajny, gdy został poprawnie skonfigurowany. Można go łatwo hakować bez dotykania żadnego kodu. Żałuję tylko, że składnia wiki nie była czymś bardziej powszechnym, jak przecena.

Przyjęliśmy podejście polegające na użyciu jednej instancji Trac. Nie potrzebowaliśmy/nie chcieliśmy używać ścisłej listy ACL, a jej zaletą jest utrzymywanie aktywności deweloperów w jednym miejscu.

W celu oddzielenia projektów zasadniczo przypisujemy błędy do różnych kamieni milowych. Każdy projekt ma krótkoterminowy i długoterminowy etap. Krótkoterminowy służy do naprawiania rzeczywistych błędów i długoterminowych w przypadku głównych wersji.

Większość innych pól "nowego biletu" zostało przyciętych, zachowując pola "typ" i "dotkliwość", które są takie same dla każdego projektu.

Raporty są zasadniczo ograniczone do "Moich biletów", a przycisk "Pokaż raport" został zmodyfikowany, aby uzyskać bezpośredni dostęp do swoich biletów.

Przepływ pracy został również dostosowany w celu dodania pośredniego statusu "testowania", dzięki czemu kontrola jakości może zagwarantować poprawkę.

Konfiguracja poczty e-mail została zmodyfikowana tak, aby nie zalać skrzynek pocztowych, dzięki czemu programiści faktycznie czytają swoje zadania.

Dzięki temu mamy dość wydajne narzędzie. Trzeba było trochę czasu, aby to naprawić, ale łatwo jest zmienić rzeczy, jeśli wiesz, jak siekać i szukać rzeczy w Google.

2

Około roku temu zaimplementowano SimpleMultiProjectPlugin (obsługa wielu projektów w jednej instancji Trac). Działa z> = Trac 0.12. Dodaje nowe pole biletu "projekt", przedłuża oś czasu i mapę drogową z filtrami dla wielu projektów i ich wersji map, komponentów i kamieni milowych do projektów.

1

The Apache Bloodhound project został stworzony specjalnie w celu wspierania Trac dla wielu projektów (między innymi). Zasadniczo jest to zbiór wtyczek na górze Trac.

Bloodhound pozostaje kompatybilny z najpopularniejszym Trac-Hacks i śledzi wszelkie zmiany w samym Trac. Możesz także spróbować the demo instance.

+0

Grałem na Twojej witrynie testowej i czy to możliwe, że kamienie milowe nie są jeszcze przez te produkty uważane? Brakowało mi czegoś w rodzaju mapy drogowej produktu, w którym wymienione są jego kamienie milowe. Chociaż dobra robota i interesująca, przynajmniej odkąd odkryłem Bitnami, znajduje się również stos Bloodhound Trac, chociaż nie jest jasne, czy to również zawiera SVN. – falkb

+0

@falkb: Mapa drogowa nadal trwa, ale uważam, że zostanie ona ponownie wprowadzona w następnym wydaniu w tym tygodniu. Nie pracowałem nad tą funkcją, więc najlepiej jest zapytać na naszej liście mailingowej, jeśli masz więcej pytań na ten temat. –