Tracciamento di build interne contro build pubbliche

Naviga le tue risposte
3

Nel nostro ufficio, utilizziamo JIRA per tenere traccia delle problematiche segnalate dai nostri team di controllo qualità. Abbiamo anche Bamboo che costruisce ogni volta che ci impegniamo per il nostro repository Git (Stash). Il QA sceglie una build di Bamboo e lavora con quella build per circa una settimana. Una volta risolti tutti i problemi che hanno archiviato su quella build, selezionano un'altra build e regrediscono / fumano di nuovo fino a quando non trovano una build completamente passante (ovvero, non sono stati segnalati problemi).

Il problema è che vogliono essere in grado di tenere traccia dei changelog tra le build interne che scelgono (la build che scelgono dal bamboo) e la nostra versione pubblica che è stata pianificata.

Quindi, ad esempio, se la nostra versione "public release" è 1.0, le nostre build interne saranno 1.0.1, 1.0.2 e così via. Potrebbero scegliere una build in build di Bamboo 50 più tardi e contrassegnarla come release pubblica. Pertanto, anche se abbiamo commercializzato il nostro prodotto come versione 1.0, la versione attuale è 1.0.50 (50 è il nostro numero di build interno).

Vogliono tenere traccia dei changelog tra ogni round interno di test e anche tracciare i changelog sull'edizione pubblica nel suo complesso. Quindi diciamo che hanno scelto le seguenti build per i loro round di test settimanali: 

1.0.1 -> 1.0.25 -> 1.0.50

Vogliono vedere quali problemi JIRA sono risolti tra 1.0.1 e 1.0.25, e allo stesso modo tra 1.0.25 e 1.0.50. L'unica soluzione a cui posso pensare per questo problema è di aggiungere 4 versioni al nostro progetto in JIRA: 

1.0
1.0.1
1.0.25
1.0.50

1.0 non è rilasciato e ogni volta che il QA aggiunge una build interna, verrà immediatamente contrassegnato come rilasciato. Ciò consentirà loro di assegnare 2 affetti o correggere le versioni per problema: 1.0 e 1.0.25 (o qualsiasi altra build interna su cui è stato segnalato)

Questo sembra goffo, non mi piace l'idea di aggiungere versioni in JIRA per le build interne. Sembra che a JIRA dovrebbero interessare solo le pubblicazioni pubbliche (ad esempio 1.0 in questo caso). C'è un modo migliore per gestire questo tipo di integrazione continua / consegna continua?

    
posta void.pointer 17.11.2014 - 17:03
fonte

2 risposte

1

Presumibilmente, la build 1.0.50 si è verificata in una certa data e qualsiasi ticket Jira risolto prima di quella data rappresenta le correzioni o le funzionalità contenute in quella build (in caso contrario, lo stato "risolto" viene probabilmente utilizzato in modo improprio). Quindi dovrebbe essere possibile farlo rendendo filtri personalizzati che elencano tutti i ticket risolti tra alcune date (e influenzando la v1.0). In questo modo, Jira non deve conoscere i numeri di build e i tester possono semplicemente utilizzare il filtro "QA Week 2".

    
risposta data 11.01.2015 - 22:42
fonte
0

I problemi possono essere filtrati per tipo, versione fissa, versione interessata, stato ecc in JIRA e si può salvare il filtro, condividerlo con altri e collegarlo a una dashboard per una rapida panoramica.

Tutte le informazioni di cui hai bisogno sono già presenti in Jira, se non è così, QA probabilmente non dovrebbe preoccuparsene. Supponiamo che il tuo team addetto al QA stia testando una build alla volta da build CI del ramo di sviluppo ed esegua uno scenario.

  • Il problema viene rilevato e registrato dal QA in JIRA insieme alla versione di build interessata sotto test
  • Il problema passa attraverso il triage, viene assegnato a uno sviluppatore
  • Lo sviluppatore riproduce il problema, inizia a lavorare su e una volta risolta è stato testato localmente, è trasferito al ramo dev e il build CI passa .
  • Gli sviluppatori mettono lo stato del problema su FISSO e imposta la versione della correzione è la stessa della versione build in CI (Bamboo)! Importante
  • Lo sviluppatore assegna il problema al QA
  • Il QA utilizza i filtri JIRA per filtrare tutti i problemi che sono stati corretti e assegnati a loro e potenzialmente controlla anche se la versione della correzione è uguale a quella che stanno testando al momento e o è un numero più alto, in entrambi i casi possono inizia a ritestare il problema. Se il problema supera il test, il ticket viene impostato su CLOSED.
  • Una volta raggiunta la versione di build che è pronta per la produzione. ci vuole mezzo minuto per creare un filtro Jira che filtra i cambiamenti che stanno entrando nella build.

In entrambi i casi, il QA ha tutti gli strumenti di cui hanno bisogno all'interno di Jira, se non lo è, suggerirei di rivedere l'attuale processo di tracciamento e allinearlo alle raccomandazioni di Atlassian sul loro wiki.

    
risposta data 22.01.2015 - 02:53
fonte

Leggi altre domande sui tag

Tecniche comuni per integrare l'accesso ai social media a un sito Web che richiede la registrazione dell'account Cercando di comprendere meglio le interfacce