svn - ¿Cómo puedo aprovechar mejor Trac?

project-management

Question

Tengo un proyecto de Trac instalado encima de una implementación de Subversion (fácil de hacer gracias al panel de control de Webfaction), pero ahora tengo que hacer una configuración. Con eso en mente, ¿hay formas fáciles de hacer lo siguiente en Trac:

1) Asegúrese de que los clientes solo puedan ver un indicador de progreso de alto nivel.
2) Brindar informes resumidos diarios sobre tickets, pruebas y tareas.

Además, me interesa saber si hay complementos altamente recomendados que lamentaría haber olvidado instalar.

Answer 1

@Dave Dunkin tiene razón. Use Trac para su uso interno y use un sistema como Basecamp para brindar a sus clientes una descripción general de alto nivel de lo que está sucediendo en el proyecto.

Answer 2

No recomendaría usar el mismo proyecto de Trac para rastrear tareas de desarrollo y mostrar el progreso del cliente. Desea ser sincero con sus tickets de desarrollo, comentarios, etc. Los clientes pueden enfocarse en las cosas incorrectas y malinterpretar los datos que coloca en los tickets. Recomendaría proporcionarle al cliente un proyecto separado que contenga tareas de alto nivel y solo muestre el progreso en esas tareas, no las cuestiones esenciales.

Answer 3

En cuanto a los complementos adicionales, instalamos TocMacro, XmlRpcPlugin, WysiwygPlugin y TracRedirect. En particular, el plugin WYSIWYG es realmente bueno para alentar a menos personal técnico a que mantenga sus propios documentos en la wiki; incluso puede usar C & P de MS Word a la vez que conserva el formato, lo que ayuda.

Eche un vistazo al material de flujo de trabajo personalizado que Trac le brinda, si su propio flujo de trabajo no está bien representado por los valores predeterminados de Trac. Esto nos ha permitido agregar pasos de revisión de código y prueba de integración al flujo de trabajo.

Recomiendo hacer que su servidor Trac se autentique frente a algún marco de autenticación central. Ejecutamos un árbol LDAP con credenciales de autenticación, y esto es utilizado por todos nuestros sistemas internos, incluidos trac, svn, samba, openvpn, etc.

Answer 4

Si se trata de una instalación en stock, la base de datos es solo un SQLite3, por lo que puede escribir fácilmente scripts para obtener información "segura", como el número de tickets o por qué no uno de los informes. De esta forma, puede discutir libremente siempre que el nombre del ticket esté correcto. Revisiones, hitos, wikipages, etiquetas (si usa ese complemento) también están disponibles.

Answer 5

Probablemente ROADMAP_VIEW retirar todos los permisos excepto ROADMAP_VIEW del usuario anónimo, pero eso probablemente será demasiado alto, ¿no? El control de acceso en el boleto individual o el nivel de comentario actualmente no es compatible con AFAIK. Consulte http://trac.edgewall.org/wiki/TracPermissions para obtener detalles sobre los permisos de trac.

Answer 6

Como se menciona en uno de los comentarios, no puede restringir el acceso a tickets o comentarios en función del usuario. Encontrar o crear un sistema de informes externo es su mejor opción.

Un par de cosas basadas en la experiencia con Trac:

1. Crear un flujo de trabajo personalizado es bastante directo. El uso de GraphViz es una gran ayuda para comunicar estados y acciones. Un plugin de flujo de trabajo (como AdvancedTicketWorkflowPlugin ) que amplía aún más la funcionalidad incorporada no es demasiado difícil si necesita una interacción de estado más compleja.

2. Para informes personalizados, puede escribir consultas SQL que toman parámetros con nombre, y luego vincularlas desde una página wiki:

Por ejemplo, la consulta puede contener una cláusula WHERE como esta:

WHERE datetime(t.changetime, ''unixepoch'') >= datetime(''now'',''-$DAYS days'')

y la página wiki puede tener esto:

Show activity for last [http://server.com/trac/report/9?DAYS=8 8] days.

Answer 7

1) indicador de progreso de alto nivel:

La pestaña de la hoja de ruta le da un tipo de indicador de progreso de alto nivel. Enumera todos los hitos, y para cada hito te muestra:

• título de hito
• Breve descripción
• fecha en que se debe cumplir el hito
• cuánto tiempo queda hasta entonces (o cuánto tiempo está detrás de su agenda)
• cuántas entradas se asignan a ese hito y cuántas de ellas se han cerrado, visualizadas como una bonita barra de progreso verde. Esta barra se basa en la suposición de que cada boleto tiene el mismo peso, lo que podría ser engañoso.

Puede restringir sus permisos de forma que su cliente solo pueda acceder a esta vista.

Dependiendo de la relación entre usted y su cliente, es posible que desee darle la posibilidad de crear nuevas entradas (permiso TICKET_CREATE), lo que debería ser posible sin darle acceso de lectura a otras entradas (TICKET_VIEW y TICKET_MODIFY). Lo siento, pero actualmente no puedo probar si esto realmente funciona, tal vez alguien pueda comentar sobre esto.

2) informes resumidos diarios

trac le ofrece alimentadores RSS para todo lo que pueda pensar. Debería ser posible generar informes diarios a partir de esto, o simplemente decirle a su cliente RSS que verifique el feed una vez al día.

Trac también tiene la capacidad de informar al propietario del boleto por correo si ese boleto cambia, pero sucederá instantáneamente, no como un resumen diario. Puede hacer comentarios sobre los tickets y, a veces, los usamos como un panel de discusión o una lista de correo, y en este caso es bueno recibir una notificación al instante.

Otra configuración

En cada proyecto que hago con trac, creo una consulta personalizada para listar todas las entradas que nadie posee:

SELECT p.value AS __color__, owner AS __group__, status, id AS ticket, summary, component, milestone, t.type AS type, time AS created, changetime AS _changetime, description AS _description, reporter AS _reporter FROM ticket t LEFT JOIN enum p ON p.name = t.priority AND p.type = ''priority'' WHERE status = ''new'' AND (owner = '''' OR owner = ''somebody'' OR owner = ''None'' ) ORDER BY owner, p.value, t.type, time

Cada boleto puede tener un propietario y varias personas en el campo de CC, pero el informe de mis boletos solo muestra aquellos en los que usted es el propietario. Para superar esto, agrego una consulta como esta:

SELECT p.value AS __color__, (CASE owner WHEN ''$USER'' THEN (CASE status WHEN ''assigned'' THEN ''Tickets that you accepted'' ELSE ''Tickets that were assigned to you, please accept or reassign'' END) ELSE ''Tickets, that have your name in the cc'' END) AS __group__, id AS ticket, summary, component, version, milestone, t.type AS type, priority, time AS created, changetime AS _changetime, description AS _description, reporter AS _reporter FROM ticket t LEFT JOIN enum p ON p.name = t.priority AND p.type = ''priority'' WHERE t.status ''closed'' AND (owner = ''$USER'' OR cc like ''%$USER%'') ORDER BY owner, (status = ''assigned'') DESC, p.value, milestone, t.type, time

(este código funciona en trac 0.11b)

Ese es mi informe de boleto favorito. Groups tickets por tres clases:

• Boletos que posee y aceptado
• Boletos que le fueron asignados, pero que aún no aceptó
• Boletos que lo tienen en el cc (que es lo más lujoso que no obtiene sin esa consulta)

Las consultas pueden dar miedo, pero son simples modificaciones de las consultas que ya están allí. No tiene que hackear el código fuente de trac, la interfaz web le permite editar consultas.

Complementos

Recomiendo el complemento XML RPC si trabaja con eclipse. Permite una estrecha integración con Mylin . (Creo que la integración básica funciona incluso sin el complemento), por lo que los desarrolladores pueden realizar muchas tareas desde eclipse sin cambiar a la interfaz web de trac.

(Si usas eclipse, pero no conoces mylin, deberías echarle un vistazo. Puedes probarlo sin ninguna configuración porque viene con la mayoría de las distribuciones de eclipse y puede funcionar como independiente sin trafico).