Utilizzo di test branch in Git

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

Stiamo usando Git e GitHub . masterdovrebbe essere / è sempre distribuibile ed developmentè il punto in cui commettiamo / uniamo nuove funzionalità o correzioni di bug, ma solo dopo che sono stati testati da Ted.

Il progetto è in PHP.

Vorrei che il processo di test procedesse così:

1. Uno sviluppatore vuole lavorare su una nuova funzionalità (diciamo la funzione / bug # 123 come documentato da Ted nel tracker dei problemi), quindi accede origin/developmental developmentsuo repository locale e crea un nuovo ramo (diciamo issue-123) da lì.
2. Una volta che è soddisfatto del suo lavoro, si impegna e spinge il suo nuovo ramo origin.
3. Ted si collega test.ourproject.com/choose-branche vede un elenco dei rami originattivi e sceglie di accenderlo issue-123(dovrebbe essere fattibile attraverso la pagina Web). Quindi continua test.ourproject.com, mette alla prova l'applicazione web (è davvero spietato) e dopo alcuni avanti e indietro con lo sviluppatore, è soddisfatto della funzionalità.
4. Ted dice lo sviluppatore che può immettersi issue-123sulla developmenton origin.
5. Risciacqua e ripeti.

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

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

Il flusso di lavoro del ramo suona molto simile a gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow e ci sono strumenti di supporto intorno. È altamente raccomandato.

Se esiste un solo tester, il flusso di lavoro dei test suona bene, ma se ci sono più persone lo sviluppo potrebbe spostarsi tra l'inizio e la fine e, naturalmente, i test dovrebbero idealmente essere eseguiti completamente dopo ogni fusione. È qui che i test automatici possono davvero aiutare o un tester lento (approfondito) potrebbe non finire mai!

Un altro problema è che con molte funzionalità e rami diventa allettante mescolare e abbinare le funzionalità in una versione (o scegliere di sfrattare dopo l'accettazione e l'unione) o forse se le funzionalità dipendono l'una dall'altra. Il problema è se si inizia a essere tentati di riscrivere la cronologia (rebase / eliminare un commit o unire) su un ramo PUBBLICATO che significa che è stato trasferito in un repository multidev. Questa è la riscrittura della 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 migliore pratica è di evitarlo in modo che la domanda non sorga mai. Tuttavia, alcuni flussi di lavoro del ramo di integrazione lo rendono molto allettante, quindi se hai una forte protezione su tali rami (ad es. Gitolite per le restrizioni del ramo dell'utente) e le persone si aspettano tale attività, quindi rifai sempre il loro codice su tale ramo, procedi con cautela!

Vorrei anche raccomandare di leggere http://sethrobertson.github.com/GitBestPractices/ che discute tutte queste questioni e ha molti buoni riferimenti.

Non sono sicuro che la pagina di commutazione stessa sia un modello comune. La maggior parte dei progetti probabilmente richiede semplicemente al tester di verificarlo 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 comporta sia la revisione che il test. Di solito è anche interconnesso con il server di integrazione continua che crea prima tutte le comunicazioni (non sono sicuro che utilizzino Jenkins in Google, ma credo di aver visto connettori appropriati da qualche parte).

Git stesso utilizza una leggera variazione sul tema. Il manutentore 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 che gli invii in sospeso vengono spesso rielaborati). Questo è testato da varie persone. Se va bene, le comunicazioni considerate complete vengono unite in next(è uguale alla tua development). In caso contrario, qualcuno verifica i singoli invii per vedere quale è rotto. Questo rende un po 'più facile per il tester poiché non devono cambiare ramo per la maggior parte del tempo; segnalano semplicemente se l'integrazione del test funziona.

Se il test viene eseguito automaticamente anziché manualmente, penso che Travis (un sistema CI per GitHub) farà praticamente quello che vuoi: esegue automaticamente test su tutte le richieste pull. ( Ulteriori informazioni su questo processo, compresi gli screenshot. )

Si noti che i test non vengono eseguiti sul ramo, ma sul ramo dopo che è stato unito nel master. (vale a dire ciò che otterresti dopo aver unito il ramo al master: sei sicuro che i test verranno eseguiti correttamente dopo la fusione).

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