Processo di distribuzione dello sviluppo agile. Dove testano il QA e gli imprenditori?

Question

Processo di distribuzione dello sviluppo agile. Dove testano il QA e gli imprenditori?

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

9

Ultimamente ho letto molto su vari processi di distribuzione di applicazioni Web utilizzando SVN o GIT, con l'obiettivo di ridisegnare il modo in cui attualmente distribuiamo il mio lavoro.

Come è il modo con molte versioni di Agile, si presume che tutto ciò che è impegnato su master o trunk sia pronto per la produzione. Sia GitHub che Etsy, link dicono che lavorano su questa base (sebbene Etsy effettivamente avere un ambiente di staging).

Questo processo presuppone che tutti i test di unità e CI siano stati eseguiti. Si eseguono i test localmente e su CI e quindi si esegue il commit to trunk. SO, a questo punto il tuo codice è tecnicamente sound.

Il tuo codice potrebbe essere tecnicamente corretto, ma i test utente / funzionali potrebbero portare alla luce altri bug, in particolare quando si tratta di test di front end.

La mia domanda è questa. Dove controllano i cambiamenti di funzionalità che hai implementato il QA e gli imprenditori? Sul tuo computer di sviluppo locale prima di eseguire il commit to trunk, o su un QA / staging machine?

Se si dispone di un sistema di gestione temporanea che funziona fuori dal trunk e si presuppone che tutto il codice impegnato per il trunk sia pronto per la produzione ... eh .. allora a che punto il codice è stato firmato e valido per la produzione da entrambi prospettiva tecnica e commerciale? Se si dispone di una sola macchina di gestione temporanea, molti sviluppatori e questo è il punto in cui il codice deve essere sottoposto a QA, allora come si può eseguire la distribuzione dal trunk in quanto molte modifiche degli sviluppatori possono attendere la disconnessione.

Sarei interessato a sapere in che modo gli altri si sono avvicinati a questo?

git testing unit-testing svn deployment

posta Bazza 12.10.2011 - 19:01

fonte

3 risposte

Leggi altre domande sui tag git testing unit-testing svn deployment

Regole generali per scrivere un compilatore X su Z in Y Qual è un buon metodo per eseguire una valutazione dell'architettura leggera?

score 6 · Answer 1

Per il meglio o per il peggio di solito vedo che questo è stato eseguito quando il test è stato eseguito sulla base del ramo e il business sign off è ciò che il checkpoint deve unire al principale di distribuzione.

Ho visto questo fatto sia con lo sviluppo su "main" con un ramo "deployed" separato o con un ramo "feature" di sviluppo con un main come "distribuito".

il flusso di lavoro ha un aspetto simile a questo:

codice qualcosa
esegui test locali
accedi al ramo di lavoro
(facoltativo) build server crea ant test
Controllo qualità / Business test
bugfix (loop torna all'inizio)
Unisci per distribuire il ramo
deploy

Alcune persone lavorano fuori da una singola filiale, ma se hai intenzione di fare test manuali diventa difficile. La maggior parte delle persone che ho incontrato lavorano sul presupposto che tutto ciò che può essere distribuito su commit che funziona anche su un singolo trunk sta facendo qualcosa di piccolo, o hanno una quantità enorme di test automatici, OPPURE considerano il "deploy" in questa conversazione a essere una build per un server di test e il processo di QA che avviene tra il server di test e la produzione viene gestita separatamente.

score 2 · Answer 2

Abbiamo test di accettazione automatizzati sullo stesso ramo di funzionalità. Quando si rilascia un candidato alla versione, include i test automatici che è stato eseguito per verificare se la funzionalità viene superata. Test anche il candidato al rilascio. Quando tutto passa, lo promuovi, unendoti al master.

Ulteriori informazioni su questo processo qui:

link

Esegui anche il checkout dei commenti.

Spero che questo aiuti,

Adam

score 0 · Answer 3

Come regola generale, in attesa di eseguire il commit prima che il codice sia perfetto, la metà delle volte recupera i vantaggi del sistema di controllo delle versioni. (Senza molta elaborazione, direi che a meno che non sia permesso un check-in multiplo a VCS, non è possibile ripristinare il mio lavoro!) Quindi come pratica chiediamo sempre alle persone di tenere il check-in (all'interno della loro filiale per SVN oppure può essere un commit locale in caso di GIT) quanto vogliono. In effetti, tanto meglio è.

Tuttavia, quando arriva il punto in cui tutto appare è fatto e testato - lo chiamiamo un rilascio e allora viene unito al tronco. Essenzialmente, il QA può certificare il RC prendendo un nuovo check out sul HEAD del ramo e se lui / lei Okey lo fa, lo stesso si fonde con il tronco.

Quindi essenzialmente utilizziamo il concetto di branch di attività o rami privati in modo che le persone siano libere di effettuare il check-in tanto quanto necessario. Allo stesso tempo, il trunk è relativamente gratuito da qualsiasi check-in non corretto .