Strategia per gestire i test A / B e Gitflow

Question

Strategia per gestire i test A / B e Gitflow

#1 da (11 voti)
#2 da (1 voti)
#3 da (0 voti)

8

Vorrei sapere quali strategie utilizzi per gestire i test A / B della tua app e gitflow.

Descrizione:

Siamo un team di 6 programmatori che sviluppano e gestiscono una grande app. Finora abbiamo lavorato su gitflow con alcuni add-on sul processo da noi aggiunto che ha funzionato perfettamente per un paio d'anni. In modo semplificato, usiamo:

master branch (solo codice delle versioni pubblicate)
release ramo che si fonde nel master dopo i test di ridondanza finali
hotfix che interagisce solo con il ramo principale in casi estremi
sviluppa che accumula i moduli sviluppati non appena terminati e testati, eventualmente unendosi nel rilascio.
/ feature che è un gruppo di funzionalità derivate dallo sviluppo e una volta che sono terminate e passano le diverse fasi di test si fondono di nuovo in sviluppare aggiungendo funzionalità
/ fix_develop che è un gruppo di funzionalità che contengono correzioni ai bug incontrati da versioni precedenti che non sono troppo urgenti per avviare un hotfix.

Ora, con l'evolversi dell'app, con il team UX e altri team di stakeholder stiamo adottando una strategia di testing A / B più strong, in cui le nuove versioni avranno 2 versioni e in base a come diventeranno i nostri utenti come una versione o l'altra la versione master finale per tutto il tempo che hanno senso per i nostri utenti.

Avendo spiegato che la domanda è : quali strategie hai utilizzato o consiglia di gestire il codice delle versioni di test A / B in gitflow?

Le opzioni che ho considerato sono in qualche modo incoerenti, ad esempio diramando i rami A e B dal master e poi unendo il ramo di rilascio all'uno o all'altro, dove non so come affrontare la separazione del codice contenuto dal rilascio ramo per caratterizzare i rami. Un'altra opzione consiste nel creare rami A e B e sviluppare rami A e B che sembrano troppi rami e confusione per i miei compagni di squadra.

Ho sentito le tue opinioni, grazie!

Aggiornamento: L'app che sviluppiamo è un'app per Android e stiamo implementando i test A / B utilizzando la piattaforma PlayStore per il test A / B, che richiede la creazione di due APK e il caricamento di uno di essi con una percentuale di implementazione. Inoltre, per semplificare le cose e poiché le modifiche potrebbero talvolta essere maggiori di una semplice posizione di un pulsante, abbiamo deciso di non aggiungere il nostro switch per i test A e B in un singolo APK.

gitflow acceptance-testing development

posta alexm 30.11.2017 - 17:03

fonte

3 risposte

Leggi altre domande sui tag gitflow acceptance-testing development

Come possiamo rendere le migliori pratiche di sviluppo del software più interessanti per le persone senza un background software? Filosofia sui test unitari sui metodi a catena?

score 11 · Answer 1

Il modo in cui l'ho sempre visto è di avere un unico code base in grado di servire entrambe le pagine / viste / moduli.

es. La sua funzione è contrassegnata e implementata con due o più configurazioni, oppure il metodo 'fa l'utente ottiene A o B' fa parte dell'app.

In questo caso hai solo l'unica versione del codice, quindi il tuo controllo sorgente non entra in gioco.

Questo è molto più preferibile rispetto all'alternativa di mantenere più versioni del codebase con caratteristiche diverse. Questi tendono a divergere molto rapidamente e si finisce per dover implementare le stesse funzionalità più volte.

In generale, farei attenzione e limitare l'ambito delle differenze che A e B possono avere entrambe in modo che possano essere inserite in un metodo switch generico (vista A o vista B per esempio) e in modo che tu possa capire le ragioni di qualsiasi statistica diversa dai test. ad esempio l'aumento delle vendite legato al colore del pulsante o alle formule di prezzo?

Modifica. per chiarimenti app

Puoi ancora avere i flag di funzionalità in un'app di Play Store e impacchettare il codebase in più di un apk.

score 1 · Answer 2

Sono d'accordo con @Ewan che le flag di funzionalità sono la strada da percorrere. In questo modo puoi aggiungere qualcosa nel processo di build che distribuirà l'APK per un test A o B. Ma se vuoi un'idea che non usi i flag di funzionalità, eccone uno che non ho provato.

È possibile estrarre il codice comune in una libreria separata in un repository separato. Quindi, ciascuna versione del test ha il proprio repository con il proprio gitflow e ramo principale che possono essere distribuiti.

Questo richiederà uno sforzo maggiore all'inizio in quanto tutto il codice comune dovrà essere estratto in una libreria (o più), quindi fatto riferimento nel repository. Ma dopo la configurazione iniziale, credo che questo possa semplificare lo sviluppo di nuove funzionalità nel test A / B.

** Ancora una volta, questa è solo un'idea e non qualcosa che ho fatto personalmente.

score 0 · Answer 3

Poiché la tua app è già in esecuzione e ha alcuni utenti, suggerisco una delle seguenti opzioni:

Ti suggerisco caldamente di fare un design thinking prima di implementare una nuova grande funzione;
Se hai ancora bisogno del test A / B, ti suggerisco di continuare con il normale gitflow e avere un ramo e un ramo B ;

Controllo sorgente

Considerando il test A / B, quello che voglio chiarire è che:

Un ramo : contiene il codice relativo a Una versione dell'app. EG: A_HomeActivity, A_SettingsActivity, ecc.
B branch : contiene il codice relativo alla versione B dell'app. EG: B_HomeActivity, B_SettingsActivity, ecc.

Da questo punto, potresti utilizzare 2 strategie:

Crea due versioni completamente diverse: A.apk e B.apk ; o
Fai in modo che il ramo B contenga il codice di un ramo e fornisca un'app in grado di utilizzare i due flussi . L'utente scarica solo un'app e ha la possibilità di attivare il nuovo flusso a scopo di valutazione. Ho visto qualcosa di simile fatto da Bitbucket , in cui una navigazione completamente nuova era disponibile per pochi utenti per la valutazione; dopo un certo periodo questa nuova navigazione è diventata quella predefinita.

In ogni caso, dopo l'esperimento rimuovi semplicemente il codice per la funzione / flusso obsoleto.