Quale parte della base di origine dovrebbero testare gli utenti?

Nel nostro progetto, le filiali vengono create per rilasci specifici, al blocco del codice. Quindi non c'è più uno sviluppo regolare su un ramo, solo correzioni di bug (per i bug trovati durante il test di rilascio). Quindi tutte le funzionalità / correzioni di bug richieste dagli utenti e incluse in quella versione specifica sono già presenti nel ramo.

Questa è la versione che viene poi distribuita per UAT / staging, quindi gli utenti possono testarla. È anche possibile distribuire una versione di sviluppo (trunk) nell'ambiente UAT per consentire agli utenti di testare, ma raramente lo facciamo in pratica. Di solito solo i nostri tester ottengono l'accesso alla versione di sviluppo (trunk) della nostra app. Questo viene distribuito su server di sviluppo separati, fisicamente non accessibili per gli utenti finali.

Usiamo JIRA per il tracciamento dei problemi, che semplifica la gestione dei rilasci, quindi (quasi) sappiamo sempre (quasi) con precisione quali caratteristiche / correzioni di bug include una versione specifica. Nel caso in cui non si abbia traccia di problemi, si consiglia di prenderne uno in uso. JIRA è commerciale, ma ci sono anche alternative gratuite.

Hai menzionato gli utenti, quindi questo potrebbe significare che si tratta di una sorta di beta test. Supporrei quindi che questa sia una versione importante di qualche tipo. Quindi era un ramo dal tronco.

Oppure sono dei tester interni, quindi testeranno qualcosa prima che venga aggiunto al ramo o al tronco.

In ogni caso gli utenti dovrebbero testare ciò che viene loro dato, o concesso l'accesso a. Prima di iniziare il test, viene data a una build specifica per testare.

Poiché è possibile che gli errori si insinuino dopo che un ramo di funzionalità è stato fuso in una linea o in un ramo di rilascio, non avrei mai eseguito UAT in base a una build da un ramo di funzione. Crea una build dal tuo baule o dal tuo ramo di rilascio se li usi; e chiedi a UAT di costruire quella build.

Dipende dal modello di ramificazione / fusione, da ciò che viene inserito nel bagagliaio e da quanto sono grandi i rami delle funzioni. Dipende anche dal tuo modello di rilascio, se i tuoi utenti ricevono una versione "test" speciale del tuo prodotto prima della versione finale, o se c'è sempre una sola versione del software in produzione, che contiene sempre le funzionalità più recenti (forse instabili) .

Da quello che hai scritto, suppongo che una feature venga unita nel trunk quando lo sviluppatore sul posto pensa che la funzionalità sia completamente implementata. Lasciando che l'utente test solo la versione trunk ha quindi vantaggi e svantaggi:

Pro:

• riceverai feedback dai tuoi tester non solo se una funzionalità è ok, ma anche quando c'è un bug causato dall'integrazione nel trunk
• se applichi correzioni di errori direttamente nel bagagliaio, sarai sicuro che anche gli utenti le otterranno

Con:

• se hai bisogno di diversi giorni o settimane per sviluppare una funzione prima di reintegrarla nel bagagliaio, non riceverai feedback dagli utenti in questo periodo, poiché non possono vedere la funzione durante questo periodo.

La soluzione a questo sembra piuttosto semplice: prova a suddividere le funzionalità in piccole feature slice che possono essere sviluppate in pochi giorni e fonderle in anticipo e spesso. Se temi di avere troppe cose "semi-cotte" in produzione usando questo modello, ti suggerirei di implementare qualcosa come una modalità di test nella tua applicazione. In questa modalità, le nuove funzionalità "instabili" possono essere attivate in fase di esecuzione e testate dai tuoi utenti di test, senza la necessità di fornire / sviluppare due rami diversi del tuo programma.