¿Cómo se manejan proyectos múltiples (superpuestos) en trac?

Question

Estamos usando trac y estamos realmente satisfechos con él. Sin embargo, de fábrica, trac es el más adecuado para entornos de proyecto único solamente. Me gustaría escuchar acerca de los diversos enfoques que las personas toman para que funcione con múltiples proyectos y sus experiencias con ellos. ¿Hay algún complemento para recomendar? ¿Algún parche, ajustes o cosas? ¿Tal vez incluso está utilizando un sistema de seguimiento de errores completamente diferente que ofrece toda la funcionalidad de trac además de la compatibilidad con múltiples proyectos?

Recientemente comenzamos a gestionar un segundo proyecto que generalmente funciona bien pero también tiene algunos inconvenientes, especialmente cuando los dos proyectos se superponen debido al código de biblioteca común que escribimos y que se usa en ambos proyectos. Como manejas esto?

(Voy a adjuntar nuestro propio enfoque actual como una respuesta a este mensaje.)

Answer 1

El enfoque que adoptamos es crear otro ambiente trac para cada nuevo proyecto y establecer vínculos para InterTrac más simple referencias cruzadas entre los dos. También utilizamos un archivo de base común Trac.ini a través de la directiva [inherit].

Además de los problemas de ambigüedad de código compartido se menciona en la pregunta, esto tiene un par de inconvenientes que pueden o no pueden afectar, en función de la naturaleza de sus proyectos y su flujo de trabajo:

• la creación de nuevos proyectos no es un proceso fácil; no se puede hacer mediante la interfaz del navegador
• números de ticket no están unificados: cada nuevo entorno de proyecto comienza desde el n. ° 1: al menos con alias de InterTrac puede eliminar la ambigüedad fácilmente
• debe tener especial cuidado al instalar y configuración de complementos para que se instalen y configuren para todos los entornos

Answer 2

Una alternativa que hemos seguido es configurar diferentes proyectos como componentes.

Compartimos el repositorio SVN y la página wiki de inicio, pero no estamos utilizando las características de los hitos. Si el proyecto es lo suficientemente grande como para tener diferentes módulos (solo uno de ellos en nuestro caso) configuramos cada módulo como un componente en lugar del proyecto.

Answer 3

La misma sensación aquí, Trac es realmente agradable una vez que se ha configurado correctamente. Y es fácilmente pirateable sin tocar ningún código. Solo desearía que la sintaxis wiki fuera algo más común, como el descuento.

Tomamos el enfoque de usar una instancia de Trac. No necesitamos/queremos usar ACL ajustado y tiene el beneficio de mantener toda la actividad de los desarrolladores en un solo lugar.

Para separar proyectos, básicamente estamos asignando errores a varios hitos. Cada proyecto tiene un hito a corto y largo plazo. El corto plazo se usa para corregir errores actuales y el largo plazo para lanzamientos importantes.

La mayoría de los otros campos de "nuevo ticket" han sido podados, manteniendo los campos "tipo" y "severidad", que son los mismos en todos los proyectos de todos modos.

Los informes están esencialmente limitados a "Mis tickets" y el botón "Mostrar informe" ha sido modificado para acceder directamente a sus tickets.

El flujo de trabajo también se ha adaptado para agregar un estado intermedio de "prueba", por lo que QA puede garantizar la fijación.

La configuración de correo electrónico se ha ajustado para no inundar los buzones, de modo que los desarrolladores realmente lean sus asignaciones.

Con eso en su lugar, tenemos una herramienta bastante eficiente. Tomó algún tiempo para hacerlo bien, pero es fácil cambiar las cosas si sabes cómo hackear y buscar cosas en google.

Answer 4

Hace aproximadamente un año se implementó SimpleMultiProjectPlugin (soporte de múltiples proyectos en una instancia de Trac). Funciona con> = Trac 0.12. Agrega un nuevo campo de ticket 'proyecto', amplía la línea de tiempo y la hoja de ruta con filtros para múltiples proyectos y sus versiones de mapas, componentes e hitos de los proyectos.

Answer 5

El Apache Bloodhound project se inició específicamente para brindar soporte a múltiples proyectos a Trac (entre otras cosas). Es esencialmente una colección de complementos en la parte superior de Trac.

Bloodhound sigue siendo compatible con el más popular Trac-Hacks y sigue cualquier cambio en el propio Trac. Puedes probar the demo instance también.