Sapendo cosa verrà rilasciato in gitflow

-1

Siamo un'azienda web SaaS che utilizza gitflow e JIRA. Dato che siamo "fatti" (approvato dal QA) con una funzione, spostiamo la storia / il biglietto in avanti in Jira a uno stato "finito". A quel punto, aspettiamo che venga approvato per il rilascio, il che significa che uno sviluppatore si fonde per svilupparlo e gli verrà assegnata una versione di correzione in JIRA. Quando i bug sono finiti, vengono assegnati anche a una versione di correzione.

Ciò significa che, in teoria, tutti i ticket in una versione di correzione dovrebbero corrispondere a ciò che è in fase di sviluppo e se viene creato un ramo di rilascio, corrisponderà perfettamente.

Tuttavia, in pratica, troviamo che naturalmente le persone dimenticano di aggiungere i ticket a una versione di correzione, o lo stato del ticket non è stato spostato in avanti ma è stato unito, ecc. Quindi abbiamo i ticket che sono in una versione di JIRA prevista essere rilasciato, ma sono ancora su un ramo, e altri ticket che vengono impegnati e saranno rilasciati, ma non ci si aspetta che lo facciano. Ciò obbliga uno sviluppatore che presta il rilascio a controllare manualmente i messaggi di commit per confermare che ogni ticket sia effettivamente rappresentato e non ne manchino alcuni. Questo è manuale e richiede molto tempo.

Ci sono strumenti o integrazioni o qualcosa che possa risolvere questo problema? O un cambio di processo (ovviamente, posso dire alle persone di fare un lavoro migliore, ma i processi manuali falliranno sempre ad un certo punto).

Ho iniziato a creare il mio strumento utilizzando le API JIRA e Bitbucket (o github) per farlo automaticamente, ma mi piacerebbe trovare qualcuno che abbia già risolto questo problema.

    
posta scojomodena 16.11.2018 - 08:49
fonte

1 risposta

-1

Dovresti testare il ramo di sviluppo piuttosto che il ramo della funzione.

Sai solo se una funzionalità funziona dopo essere stata unita alle altre funzionalità di una versione.

Ovviamente puoi anche testare il ramo della funzione per assicurarti che sia finito prima della fusione. Ma il QA principale deve essere fatto sullo sviluppo o su un ramo di rilascio.

Ora invece di testare e tenere traccia delle singole funzionalità e correzioni di bug, stai testando una versione del software con un elenco di modifiche. Lo saprai durante il test della versione di ciascuna funzione e non avrà questa disconnessione tra la finitura e "approvato di rilascio"

Inoltre, assicurati che i rami delle funzionalità includano il numero del biglietto JIRA, quindi sarai in grado di collegare l'unione con il ticket.

    
risposta data 16.11.2018 - 21:22
fonte

Leggi altre domande sui tag