Trac basics CISC 475/675 Lab 5

Lab agenda • Basics of Trac • Lab demo on what Trac can offer • Lab exercise on trac

Project Management systems • A software project is more than just the code • Large projects require lots of tracking, such as: – Charting overall progress – Planning enhancements & “To Do” lists – Identifying & handling bugs/defects

• • • •

Assigning tasks to individual developers General coordination of entire project Central location for all pertinent information Keeping everyone “on the same page” Slide courtesy of Charlie Greenbacker

What is Trac? A open source project management tool by edgewall In their own words…. “Trac is a minimalistic approach to webbased management of software projects. Its goal is to simplify effective tracking and handling of software issues, enhancements and overall progress.”

Trac at a glance ● Enhanced wiki & issue tracking system for software development projects – Wiki for collaborative information sharing – Ticketing system for tasks & bugs – Timeline & Roadmap for overall progress ● Minimalistic approach to web-based software project management – “Staying out of the way” of team's process/policies – Provides basic tools to use however you see fit ● Tight integration with Subversion Slide courtesy of Charlie Greenbacker

Project trac on eecis • CourseCheck http://cisc475.acad.cis.udel.edu/CourseCheck • pSearch http://cisc475.acad.cis.udel.edu/psearch

Login will be through EECIS account

Login through your eecis

All the documentation about using Trac. My recommendation: DO NOT EDIT WIKI TO REMOVE THIS Let this always be on the homepage and create other content as required during the progress of the projects

Trac Wiki • For textual information and documentation • Uses can be similar to how you are working on sakai • But it is NOT for bugs and problem reporting – there is a separate “Ticket” section for that • The format is slightly different from Sakai and all formatting information is available through documentation on the trac home page http://cisc475.acad.cis.udel.edu/psearch/wiki/WikiForma tting

Trac Timeline Historic view of entire project in single report – Similar in concept to “svn log” – Includes multiple types of information: – – – –

Subversion commits Wiki changes Ticket changes Milestones from Roadmap

– Entries are listed chronologically, include username, comment, link to changed item (code or Trac page) Available for subscription as RSS feed Slide courtesy of Charlie Greenbacker

The Revision number from SVN The user who made the commit

The comment/message during commit (see that’s why relevant and useful comments are essential!)

Trac and Subversion • Subversion events displayed throughout Trac – Individual commits listed on Timeline – Clicking on “changeset” link brings up page showing the changes from previous revision – Very helpful visualization tool for SVN actions

• Trac provides web access to SVN respository – Conveniently browse contents of each file/directory – See who made last change & how recently – Easy comparison of changes between revisions Slide courtesy of Charlie Greenbacker

Click any Changeset/revision to see ‘what had be done’ Who did what and when The content and changes within

The two (or more) revision/commits when the file had some change

Highlights what got changed – added or deleted or no-change

Browse the SVN repo

Trac Ticketing System Simple tracking of tasks & bugs within project • Managers can assign jobs to individual developers – Tasks can be part of certain future milestones to reach

• Developers can report bugs with any part of system – Managers assign “fix” responsibilities to appropriate party

• Each ticket “belongs” to a developer who is responsible for its resolution • Ticket indicates which project component the issue is related to • Discussion & progress posted on ticket • Ticket is closed once issue is resolved Slide courtesy of Charlie Greenbacker

Ticket Fields As per Trac documentation • • • • • •

• • • • • • • •

A ticket contains the following information attributes: Reporter — The author of the ticket. Type — The nature of the ticket (for example, defect or enhancement request) Component — The project module or subsystem this ticket concerns. Version — Version of the project that this ticket pertains to. Keywords — Keywords that a ticket is marked with. Useful for searching and report generation. Priority — The importance of this issue, ranging from trivial to blocker. Milestone — When this issue should be resolved at the latest. Assigned to/Owner — Principal person responsible for handling the issue. Cc — A comma-separated list of other users or E-Mail addresses to notify. Note that this does not imply responsiblity or any other policy. Resolution — Reason for why a ticket was closed. One of fixed, invalid, wontfix, duplicate,worksforme. Status — What is the current status? One of new, assigned, closed, reopened. Summary — A brief description summarizing the problem or issue. Description — The body of the ticket. A good description should be specific, descriptive and to the point.

Trac Roadmap • High-level view of issues in ticketing system – Helps planning/management of future development – Tickets are organized into milestones • Milestones represent certain goals to be achieved • Roadmap displays progress bar for milestone completion • On each milestone's page, you can see the progress for each major component in the system

– Useful for meeting deadlines and seeing where work should be focused • Available for subscription in iCalendar format! Slide courtesy of Charlie Greenbacker

Task for the lab • Create a ticket for your project – If you can make a genuine ticket based on current project status that is good. Or else assume a fake situation and create a ticket.

• Assign the Owner to be someone in your project (NOT YOURSELF) • You may have a ‘discussion’ on the ticket. • The owner should then resolve the ticket and close it. • At the end everyone should have created AND resolved at least one ticket.

• http://cisc475.acad.cis.udel.edu/CourseCheck • http://cisc475.acad.cis.udel.edu/psearch