Wiki:TracReadMe

Benutzung

Hier gibt es eine kleine Einführung in die Benutzung von Trac. Sie ist nicht dazu gedacht, die umfangreichen tiefgreifenden Hilfen und anderen Tutorials im Internet zu ersetzen, sondern soll gerade am Beginn einen schnellen und frustfreien Start in die Benutzung von Trac ermöglichen.

1 Wiki

  • Abb. 1: Das integrierte Wiki

Trac bringt ein voll funktionsfähiges Wiki mit, was natürlich grade für besonders große Projekte sehr wichtig ist. Nach der Erstellung der Instanz beinhaltet das Wiki eine Kopie des Trac-Wikis zur aktuell verwendeten Version und bietet somit seine eigene umfangreiche Online-Hilfe, auf die vom gesamten Trac aus zugegriffen werden kann, gleich selbst mit.


2 Journal

  • Abb. 2: Das Journal - eine Chronik des Projekts

Die Zeitleiste eures Projektes stellt Änderungen am Wiki, an Tickets und an Meilensteinen übersichtlich dar.


3 Projektplan

  • Abb. 3: Planung von Meilensteinen

Meilensteine sind festgelegte Zwischenziele in einem Projekt. Sind einem Meilenstein Tickets zugeordnet, wird ein Fortschrittsbalken mit dem Verhältnis zwischen offenen und abgeschlossenen Tickets angezeigt, sowie Shortcuts zu jeweils offenen, geschlossenen oder allen Tickets dieses Meilensteins.


4 Source Code Browser mit direkter Anbindung an Github

  • Abb. 4: Browsen durch das Repository

Falls einer Trac-Instanz ein Repository zugeordnet ist, könnt ihr es hier ähnlich wie direkt im Browser durchsuchen. Allerdings bietet der Code Browser Tracs ungleich mehr Funktionen: Es wird neben der Größe auch die Revisionsnummer, das Alter und die Commit-Message des aktuellsten Standes der entsprechenden Datei oder des entsprechenden Ordners angezeigt. Außerdem können einzelne Dateien oder das gesamte Repository zu einer bestimmten Revision angezeigt (Kontrollen oben), Changesets (auf Rev. klicken) betrachtet und der Unterschied einer Datei zwischen zwei beliebigen Versionen (auf Datei klicken) untersucht werden.

Alternativ zu Github können Sie auch Ihr eigenes Repository wie zum Beispiel Git auf einem cBUZZ Server mit Trac verknüpfen!


5 Ticketsystem

  • Abb. 5: Neues Ticket

Dies ist das wohl wichtigste Modul von Trac. Tickets sind mit klassischen ToDo-Zetteln zu vergleichen. In ihnen ist der Name der Aufgabe, eine Beschreibung, der Übermittler, der Bearbeiter und vieles mehr festgehalten - spätestens mit dem Benutzen von Plugins sind der Phantasie dort keine Grenzen gesetzt. Im Abschnitt zum Admin-Panel wird auf die meisten dieser Felder eingegangen, da die angebotenen Optionen dort bearbeitet werden können.

Es ist nirgendwo festgeschrieben, wie genau so ein Ticketsystem zu benutzen ist. Von naja, eigentlich sind es nur Notizzettel bis hin zum Ticketsystem für große Teams mit tausenden Tickets ist alles drin. Aus diesem Grunde wird hier auch nicht näher auf den Ticket Workflow eingegangen, da ihr mit ein wenig Herumprobieren euren ganz eigenen herausfinden werdet.

  • Abb. 6: Tickets anzeigen

Wichtig hier sind noch die sogenannten Reports, welche hinter dem Menüpunkt Tickets anzeigen stecken. Tickets werden nicht generell einfach in einer Liste angezeigt, sondern in einer Tabelle, die eine Datenbankabfrage hinter sich hat. So listet Active Tickets zum Beispiel alle Tickets, die nicht den Status closed besitzen. Normalerweise sollten die vorhandenen Abfragen vollkommen ausreichen, jedoch können auch neue Reports angelegt werden. Ein interessanter Zusatz zum WHERE-Teil einer Abfrage wäre zum Beispiel:

1 WHERE owner == 's0123456'

, wobei natürlich deine eigene Matrikelnummer eingesetzt werden sollte, um nur Tickets dieses Benutzers anzuzeigen.


6 Suche

  • Abb. 7: Projektweite Suche

Zu diesem Bereich gibt es wohl am wenigsten zu sagen: Er erlaubt das Durchsuchen aller Tickets, Changesets, Meilensteine und des gesamten Wikis.


7 Admin-Panel

  • Abb. 8: Die Schaltzentrale der Trac-Instanz

Hier könnt ihr alle euch erlaubten Einstellungen vornehmen. Der User admin braucht also keinen Zugriff auf eine Kommandozeile auf dem Server, um trac-admin-Kommandos abzusetzen, wie es im Internet oft beschrieben wird. Trotzdem kann der User admin hier mit falschen Einstellungen das ganze Trac zerstören.


7.1 Berechtigungen

  • Abb. 9: Hier werden dem User seine Rechte zugeordnet

7.2 Users

  • Abb. 10: Berechtigungen und Gruppen verwalten

Der User kann sich selbst über den Menüpunkt Register anlegen oder vom Admin angelegt werden. Der Admin muss hier danach im Feld Subject zu Gruppe hinzufügen: den User mindesten in die Gruppe: Lesen hinzufügen.

  • Abb. 11: Wenn der Benutzer noch keinen Account hat, kann er ihn hier beantragen

7.3 anonymous Users erlauben

  • Abb. 12: anonymous ist ein vordefinierter Benutzer

Wenn Sie das Trac Wiki öffentlich auch ohne Anmeldung zugänglich machen möchten, tragen Sie einfach im Feld Subject zu Gruppe hinzufügen: den vordefinierten User anonymous ein um ihn in die Gruppe: Lesen hinzufügen.

8 Einstellungen zum Ticket-System

8.1 Komponenten

  • Abb. 13: Komponenten im Admin

Komponenten eures Projektes, denen ihr Tickets zuordnen könnt. Das kann zum Beispiel so etwas wie Backend, Frontend und Android-App sein, aber auch etwas abstraktes wie Dokumentation - eurer Phantasie ist keine Grenzen gesetzt.


8.2 Meilensteine

  • Abb. 14: Meilensteine im Admin

Hier werden die Daten von bearbeitet. Ihr könnt ihnen Namen, Beschreibung, vorgesehenes und tatsächliches Fertigstellungsdatum geben. Als Beispiel sei hier natürlich die ganz wichtige Abgabe eines Projekts genannt!


8.3 Priroritäten

  • Abb. 15: Prioritäten im Admin

Was wird zuerst erledigt?


8.4 Lösungen

  • Abb. 16: Lösungen im Admin

Wie wurde dieses Ticket geschlossen? Gefixt? Bug gar nicht vorhanden? Duplikat? Es bietet sich an, gerade für simple Aufgaben-Tickets ein done hinzuzufügen.


8.5 Schweregrade

  • Abb. 17: Dringlichkeiten im Admin

Eine Option, die so oft nicht benötigt wird, da bereits die Priorität eine ausreichende Einteilung der Tickets bietet. Kleiner Tip: Ihr könnt hier - wie in allen anderen Ticket-Eigenschaften - für euren Workflow eintragen, was ihr wollt. Ob nun leicht und schwer, S, M und L oder mandatory und optional oder was auch immer ihr in eurem Workflow abbilden möchtet.


8.6 Ticket Typen

  • Abb. 18: Ticket-Typen im Admin

Hier ist Fehler (defect) (Bug), Verbesserungen (enhancement) (am bestehenden System) oder Neue Features (task) (als Kundenwunsch) voreingestellt und sollte selbsterklärend sein.

8.7 Versionen

  • Abb. 13: Versionen im Admin

Zu guter Letzt könnt ihr Tickets also auch Versionen zuordnen. Ist ein Feature zu schwer für die aktuelle Version 0.9? Kein Problem, einfach auf Version 1.0 verschieben!

(Gefunden bei: Quelle)

zuletzt geändert vor 3 Jahren Zuletzt geändert am 18.01.2016 01:19:54

Anhänge (19)

Alle Anhänge herunterladen als: .zip