Sto scrivendo questo dal punto di vista di Redmine. Non ho usato Trac e ho solo massaggiato la sorgente con i miei occhi (nemmeno leggendolo). Ad un livello elevato, sembra essere simile a Redmine, quindi molte delle cose che dico potrebbero applicarsi anche a questo.
La prima domanda da tenere in considerazione è l'integrazione tra il lato di tracciamento dei bug (e di modifica del codice) e il rilevamento del problema "customer facing". Luoghi diversi possono consentire un grado di apertura che non è disponibile in altri.
- Un prodotto software closed-source non permetterà certo alle modifiche del codice di avvicinarsi al sistema di tracciamento dei bug del cliente. Il rischio di far uscire del codice è una preoccupazione per molti di loro.
- Un prodotto software open source ospiterà spesso il codice sorgente e il bug tracking accanto al rilevamento dei problemi dei clienti (sono la stessa cosa). Questo può essere visto sia in Redmine che in Trac.
- Un ambiente accademico ... beh, probabilmente è da qualche parte nel mezzo.
L'ultimo punto è la chiave - è un problema se la fonte esce? O del resto, è un problema se le persone vedono la discussione tra gli sviluppatori del prodotto nelle note di un problema?
Redmine ha la capacità di limitare quali determinati utenti possono leggere. Potresti avere singole note contrassegnate come private o cose come "solo le persone con il ruolo di programmatore possono visualizzare il repository."
Se ciò è accettabile, la cosa più semplice è per integrare il monitoraggio dei problemi degli utenti finali e il bug tracking nello stesso sistema. Probabilmente vorrai separare "bug" e "problemi" gli uni dagli altri, anche se noti che esiste una relazione tra loro. Un problema dell'utente finale può essere causato da un bug o potrebbe essere qualcosa che l'utente finale non capisce.
Problemi e bug hanno flussi di lavoro diversi - i problemi possono passare attraverso qualcosa come "nuovo - > confermato - > in attesa di correzione - > risolto" mentre un bug può passare attraverso "nuovo - > assegnato - > - > revisione del codice - > funzionante - > revisione del codice - > distribuito - > chiuso "o qualcosa del genere. Ci sono probabilmente tanti flussi di lavoro quante sono le installazioni. Avere una relazione "bloccata da" dal problema al bug consente di collegare facilmente i due sistemi insieme.
Tutto ciò presupponeva che fosse accettabile avere un host di sistema entrambi, quindi ti ritroverai con due sistemi diversi: uno rivolto al cliente, uno rivolto allo sviluppatore. Ciò potrebbe comportare un po 'più di lavoro - in qualche modo, qualcuno deve colmare il divario tra i due - gli sviluppatori devono essere consapevoli dei bug che vengono scoperti dall'utente nel loro sistema di tracciamento dei bug.
Non ho trovato un moderno sistema di tracciamento dei bug che funzioni bene con gli altri. Tutto cerca di essere autonomo e quando i prodotti commerciali hanno sistemi di tracciamento dei bug, fanno in modo che sia facile migrare ad esso e utilizzare tutto all'interno della propria linea di prodotti. Potresti trovare un'API che ti consente di fare alcune cose, ma per la maggior parte - no.
La domanda qui diventa qual è il carico di lavoro e in che modo si desidera integrare i due (immagine due bambini viziati che si siedono a vicenda senza voler giocare)? Basta avere un collegamento da un sistema all'altro? La quantità di nuovi problemi è abbastanza bassa da poter essere eseguita a mano? o hai bisogno di iniziare ad esplorare un modo per sondare da uno e aggiornare l'altro?
Assicurarsi che quando si integrano i due sistemi si utilizza l'API piuttosto che cercare di andare dietro le sue spalle e armeggiare con il database con gli aggiornamenti direttamente. Ci sono dei pericoli: la struttura della tabella dei moderni bug tracker è molto grande e viene gestita nell'applicazione. Andare dietro il retro dell'applicazione potrebbe causare problemi con l'integrità dei dati. Come accennato in precedenza, invece di aggiornare e inserire nel database, utilizzare l'API pubblica per l'applicazione (l'API di Redmine per i problemi per esempio ).
L'estensione della logica aziendale e i punti di integrazione sono qualcosa che deve essere esaminato prima di saltare e farlo. In che modo il flusso di dati (a volte in entrambi i casi diventa molto interessante) e quali flussi di dati. Stai copiando i problemi in bug una volta raggiunto un certo stato? Come si tiene traccia per assicurarsi di non creare più volte lo stesso problema (è necessario aggiornare il modello di dati del sistema di tracciamento dei bug)? Che cosa accade quando un problema è contrassegnato come chiuso in un sistema di tracciamento dei bug - viene restituito?
Tutto sommato, è probabilmente più semplice provare a utilizzare lo stesso sistema e gestire le autorizzazioni / personalizzarlo in modo che funzioni nel modo in cui lo si desidera se non è gravemente negativo se trapelano alcune informazioni dagli sviluppatori .