Utilizzo dei rami di test in Git

Question

Utilizzo dei rami di test in Git

#1 da (4 voti)
#2 da (2 voti)
#3 da (1 voti)

9

Abbiamo qualcuno (chiamiamolo Ted) che è responsabile per testare nuove funzionalità e correzioni di bug.

Stiamo utilizzando Git e GitHub . master deve essere / è sempre distribuibile e development è il punto in cui vengono commesse / unite nuove funzionalità o correzioni di errori, ma solo dopo che sono state testate da Ted.

Il progetto è in PHP.

Mi piacerebbe che il processo di test si svolgesse in questo modo:

Uno sviluppatore vuole lavorare su una nuova funzione (diciamo la funzione / bug # 123 come Ted documentata nel tracker del problema), quindi tira origin/development a development sul suo repository locale e crea un nuovo ramo ( diciamo issue-123 ) da lì.
Una volta che è contento del suo lavoro, commette e spinge il suo nuovo ramo a origin .
Ted si connette a test.ourproject.com/choose-branch e vede un elenco dei rami su origin e sceglie di attivare issue-123 (dovrebbe essere fattibile attraverso la pagina web). Poi va su test.ourproject.com , mette alla prova l'applicazione web (è davvero spietato) e dopo un po 'avanti e indietro con lo sviluppatore, è contento della funzionalità.
Ted dice allo sviluppatore che può unire issue-123 in development in origin .
Risciacqua e ripeti.

Per il terzo passaggio, potrei hackerare qualcosa che fa il lavoro (mostrare e cambiare rami da una pagina specifica), ma sento che quello che ho descritto è un modello molto comune.

Quindi la mia domanda è: Si tratta di un flusso di lavoro buono / sostenibile / gestibile per la ramificazione? Puoi eseguire il backup della tua risposta citando alcuni esempi di altri progetti che seguono questo flusso di lavoro?

git testing integration

posta cpa 22.02.2013 - 12:25

fonte

3 risposte

Leggi altre domande sui tag git testing integration

Che cos'è un buon libro di matematica da tenere sulla mia scrivania mentre studi Haskell? [chiuso] Devo risolvere piccoli problemi o lasciarli andare? [chiuso]

score 4 · Answer 1

Il flusso di lavoro delle filiali suona molto simile a gitflow link e ci sono strumenti di supporto in giro esso. È altamente raccomandato.

Se esiste un solo tester, il flusso di lavoro del test sembra valido, ma se ci sono più persone, lo sviluppo potrebbe spostarsi tra inizio e fine e, naturalmente, il test dovrebbe idealmente essere eseguito completamente dopo l'unione. È qui che i test automatici possono davvero aiutare o un tester lento (completo) potrebbe non finire mai!

Un altro problema è che con molte funzionalità e rami diventa interessante mescolare e abbinare le funzionalità in una versione (o scegliere di sfrattarle dopo l'accettazione e l'unione) o forse se le funzionalità dipendono l'una dall'altra. Il problema è se inizi a essere tentato di riscrivere la cronologia (rebase / cancella un commit o unisci) su un ramo PUBLISHED, cioè uno che è stato inviato a un repository multidev. Questo sta riscrivendo la storia pubblica. Può essere fatto per il bene o il male e anche se fatto per il bene può causare problemi agli incauti, e la miglior pratica è evitarla, quindi la domanda non verrà mai fuori. Tuttavia, alcuni flussi di lavoro di integrazione rendono questo molto allettante, quindi se si dispone di una strong protezione su tali rami (es. Gitolite per restrizioni sui rami utente) e le persone si aspettano che tale attività rebase sempre il loro codice su tale ramo, procedere con cautela! / p>

Mi piacerebbe anche consigliare di leggere il link che discute tutte queste questioni e ha molte buone referenze.

score 2 · Answer 2

Non sono sicuro che la stessa pagina di commutazione sia un modello comune. La maggior parte dei progetti probabilmente richiede al tester di controllarlo con il comando git.

L'approccio generale sembra decisamente ragionevole.

Google ha persino scritto Gerrit per supportare uno stile simile; si tratta più di rivedere il codice, ma l'approvazione dell'integrazione normalmente implica sia la revisione che il test. Di solito è anche interconnesso con il server di integrazione continua che crea prima tutte le submission (non sono sicuro che usino Jenkins in Google, ma io credo di aver visto connettori appropriati da qualche parte).

Git stesso usa una leggera variazione sul tema. Il maintainer ha uno script che unisce tutti gli invii in sospeso in un ramo chiamato pu (presumibilmente per "aggiornamenti proposti", il ramo viene eliminato e ricreato ogni volta in quanto le submission in sospeso vengono spesso ridefinite). Questo è testato da varie persone. Se va bene, gli invii considerati completi vengono uniti in next (è uguale al development ). In caso contrario, qualcuno verificherà le singole comunicazioni per vedere quale è stata interrotta. Questo rende un po 'più facile per il tester, dato che non devono cambiare ramo la maggior parte del tempo; segnalano semplicemente se l'integrazione del test funziona.

score 1 · Answer 3

Se i tuoi test vengono eseguiti automaticamente anziché manualmente, penso che Travis (un sistema CI per GitHub) farà praticamente ciò che voglio - esegue automaticamente i test su tutte le richieste di pull. ( Ulteriori informazioni su questo processo, inclusi gli screenshot . )

Si noti che i test vengono eseguiti non sul ramo, ma sul ramo dopo che è stato fuso in master. (vale a dire cosa otterresti dopo aver unito il ramo in master: sei certo che i test continueranno a essere eseguiti con successo dopo l'unione).

Se i commit vengono aggiunti al ramo, i test vengono rieseguiti. (Anche se per qualche ragione l'aggiunta di commit al master non sembra rieseguire i test.)