Best practice per la clonazione di bug

Naviga le tue risposte
1

Sto cercando di pensare a un modo semplice e facile per farlo, ma ho pensato di farlo passare per alcune persone per una seconda opinione:

Supponiamo di avere 8 clienti (un progetto per ciascun cliente) e ogni progetto deriva da un progetto principale. Se viene sollevato un bug che deve essere corretto in core, il nostro attuale approccio è creare un bug e clonarlo per ogni cliente (usando Bugzilla). Un sacco di sviluppatori stanno trovando il tempo necessario per clonare manualmente i bug su tutti i client e assicurarsi che siano posizionati su ogni tracker di rilascio per cliente.

Suppongo che si tratti di un problema di flusso di lavoro, quindi qualcuno ha suggerimenti sul modo migliore per gestire i bug di clonazione per più clienti? Forse Bugzilla non è lo strumento migliore per questo. La maggior parte di noi crede che non possa essere completamente automatizzata e richiederà un intervento manuale a prescindere dallo strumento che usiamo.

Un'idea che ho avuto è stata quella di creare un singolo problema di bug. Se si tratta di un bug di base e quando lo si assegna per una versione, non viene contrassegnato come completamente risolto poiché non è stato testato per tutti i progetti client derivati dal progetto principale. Il problema con questo è che avrei bisogno di un modo per collegare il singolo bug a tutti i clienti e far sapere quando impostarlo automaticamente per risolverlo una volta che l'ultimo cliente ha avuto un rilascio. Non credo che Bugzilla abbia una funzionalità del genere.

Qualsiasi idea o idea sarebbe gradita.

    
posta Desolate Planet 02.04.2011 - 23:15
fonte

2 risposte

1

Non conosco una funzionalità automatica in bugzilla per fare ciò (la bugzilla api è potente e può fornire alcuni posti per lo script ... ma non ne ho abbastanza familiarità per essere sicuro)

Ma sono d'accordo sul fatto che il problema sembra essere correlato al flusso di lavoro ... Se ci pensi sembra che ci sia una dipendenza quasi ciclica ... Per finire il rilascio del componente principale richiediamo la validazione del prodotto client, ma per risolvere il rilascio del prodotto client è necessario rilasciare il componente principale.

Invece di preoccuparsi di ogni client che convalida una correzione, cosa succede se si dispone di test di funzionalità / regressione per il componente stesso (che verrebbe aggiornato secondo necessità). Il problema con il componente principale può bloccare il rilascio del componente principale, che può bloccare i bug per il rilascio di ciascun progetto client.

Una volta completata la correzione e superato i test delle funzionalità, è possibile risolvere il problema. Quando tutti i problemi sono stati risolti e il componente è stato sottoposto a test di regressione, è possibile rilasciare il componente e chiudere i bug di errore. Quando il test è completo per il progetto client (compresa la convalida di tutte le modifiche incluse), il bug di rilascio del client può essere risolto.

Ora, per quanto riguarda la convalida dei progetti dei clienti, è qui che l'integrazione continua pagherebbe immensamente. La creazione di sviluppo di ciascun prodotto client potrebbe richiedere lo sviluppo di build del componente principale e la convalida del funzionamento di tali elementi, nonché la scoperta di problemi relativi al componente principale durante lo sviluppo. Se viene rilevato un problema dopo il rilascio del componente principale, si avvia il processo con un nuovo bug di problema e un nuovo bug di rilascio per il componente principale, bloccando le versioni client.

Sembra quasi un rilascio anticipato, rilascia spesso mantra se questo ha senso.

Sì, questo è un processo manuale, ma forse ridurrà la clonazione di bug se questo ha senso ... non so come se sarebbe jive con i tuoi requisiti / regolamenti però.

    
risposta data 03.04.2011 - 00:16
fonte
1

Potresti confondere il CRM con il monitoraggio dei problemi del software. I report di utente / client dovrebbero essere ricercati contro una knowledge base e quindi triaged e spostati a monte se non risolti con quello. È ciò che fanno aziende con migliaia o milioni di clienti.

  1. Se il triage di un errore punta al core, crea un problema per il core e contrassegna il problema per il client con l'id del problema principale.
  2. Se altri client non hanno segnalato lo stesso problema e il problema non è grave (business-wise, legally), quindi fermarsi a questo punto. Se lo segnalano, quindi registra un problema come in precedenza, contro lo stesso problema principale.
  3. Se il bug ti mette nei guai o nei tuoi clienti, informa i tuoi clienti con qualsiasi mezzo, informandoli dei rischi e quando ti aspetti di risolvere il problema e nel loro ambiente di produzione.

Sì, è un problema di flusso di lavoro.

L'approccio che stai utilizzando potrebbe essere perfezionato per evitare la duplicazione se il problema è andato a un sistema CRM come una singola istanza che è stata aggiornata quando il problema nella base del problema del software è stato chiuso.

Ancora una volta, immagina di avere un milione di utenti e che un centinaio di loro ha segnalato un problema. Cosa faresti? Impostare un processo che costa un K * 10 ^ 6 o uno che costa M * 10 ^ 2?

    
risposta data 03.04.2011 - 03:20
fonte

Leggi altre domande sui tag

Model-view-presenters e interazioni dell'utente che coinvolgono finestre di dialogo separate MVC 3 - Eventuali nuove funzionalità da esplorare per un'applicazione MVC 2 esistente?