Processo di distribuzione dello sviluppo agile. Dove testano il QA e i titolari di aziende?

9

Recentemente ho letto molto su vari processi di distribuzione di applicazioni Web usando SVN o GIT, al fine di ridisegnare il modo in cui attualmente implementiamo dove lavoro.

Come per molti gusti di Agile, si presume che tutto ciò che è destinato al padrone o al bagagliaio sia pronto per la produzione. Sia GitHub che Etsy, http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/ affermano di lavorare su questa base (sebbene Etsy abbia effettivamente un ambiente di gestione temporanea).

Questo processo presuppone che siano stati eseguiti tutti i test unitari e i test CI. Esegui i test localmente e su CI e quindi esegui il commit su trunk. Quindi, a questo punto il tuo codice è tecnicamente valido.

Il tuo codice potrebbe essere tecnicamente corretto, ma i test utente / funzionali potrebbero scoprire più bug, in particolare quando si tratta di test front-end.

La mia domanda è questa Dove testano i proprietari di QA e Business le modifiche alle funzionalità che hai implementato? Sul tuo computer di sviluppo locale prima di impegnarti nel trunk o in un QA / computer di gestione temporanea?

Se si dispone di una macchina di gestione temporanea che esegue il trunk e si presume che tutto il codice assegnato al trunk sia pronto per la produzione ... eh, allora a che punto il codice è stato firmato e buono per entrare in produzione sia da un punto di vista tecnico che aziendale prospettiva? Se hai solo una macchina di gestione temporanea, molti sviluppatori ed è qui che deve essere QA il codice, allora come puoi implementare dal trunk poiché molte modifiche degli sviluppatori possono essere in attesa di approvazione.

Sarei interessato a sapere come gli altri si sono avvicinati a questo?

— Bazza
fonte

6

Nel bene o nel male, di solito vedo che ciò viene fatto laddove i test vengono eseguiti sulla base delle filiali e la firma del business è ciò che il checkpoint deve unire alla distribuzione principale.

Ho visto questo fatto sia con lo sviluppo su "principale" con un ramo "distribuito" separato o un ramo "caratteristica" di sviluppo con un principale come "distribuito".

il flusso di lavoro finisce per assomigliare a questo:

codificare qualcosa
eseguire test locali
fare il check-in nella filiale di lavoro
(facoltativo) build server crea test ant
QA / Test aziendali
bugfixes (torna all'inizio)
unisci per distribuire ramo
Deploy

Alcune persone lavorano da un singolo ramo, ma se hai intenzione di avere test manuali diventa difficile. La maggior parte delle persone che ho incontrato lavorano sul presupposto che qualsiasi cosa possa essere distribuita su commit che funziona anche da un singolo trunk sta facendo qualcosa di piccolo, o ha una quantità enorme di test automatizzati, O considerano la "distribuzione" in questa conversazione per essere una build per un server di test e il processo di controllo qualità che si verifica tra il server di test e la produzione viene gestito separatamente.

— Conto
fonte

Grazie Bill. Lavoriamo in un ambiente in cui gli sviluppatori si impegnano e implementano costantemente funzionalità separate per il sito. Se si lavora su un ramo di funzioni, dopo aver verificato il ramo di lavoro, dove si vede che vengono eseguiti i test QA / Business? Se si dispone di un solo computer QA a cui gli sviluppatori eseguono il commit dei rami, è possibile testare realisticamente solo una funzionalità alla volta, a meno che non si disponga di un sito e di un'istanza separata del server delle applicazioni configurata per ogni sviluppatore sul computer QA, quindi il suo le modifiche potrebbero essere testate separatamente prima di impegnarsi nel trunk.

— Bazza,

nella mia esperienza con questo di solito non abbiamo creato un ramo di funzionalità separato per ogni sviluppatore, più simile a uno per ciascun team e abbiamo creato un host qa per ciascuno di essi, anche se era solo una macchina di sviluppo extra.

— Bill

Apprezzo i commenti. Mi ha dato alcune idee.

— Bazza,

2

Abbiamo test di accettazione automatizzati sullo stesso ramo di funzionalità. Quando si candida a una release, sono inclusi i test automatici eseguiti per verificare se la funzionalità è stata superata. Si verifica anche il candidato di rilascio. Quando tutto passa, lo promuovi quindi unendoti al master.

Maggiori informazioni su questo processo qui:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Controlla anche i commenti.

Spero che sia di aiuto,

Adamo

— adymitruk
fonte

@Adam - Grazie per quello, e il link. La discussione è stata interessante. Cibo per la mente.

— Bazza,

0

Come regola generale, attendere il commit prima che il codice sia perfetto è la metà del tempo per riprendersi i vantaggi del sistema di controllo della versione. (Senza troppe elaborazioni, direi che a meno che uno non sia autorizzato a effettuare più check-in su VCS, non c'è modo di ripristinare il mio lavoro!) Quindi, come pratica, chiediamo sempre alle persone di effettuare il check-in (all'interno della loro filiale per SVN oppure può essere un commit locale in caso di IDI) quanto vogliono. In effetti, meglio è.

Tuttavia, quando arriva il punto in cui tutto sembra essere fatto e testato, lo chiamiamo un rilascio e quindi viene unito al trunk. In sostanza, il QA può certificare il RC effettuando un nuovo check out sul HEADramo e, se lo fa Okey, lo stesso si fonde nuovamente con il trunk.

Quindi essenzialmente usiamo il concetto di rami di attività o rami privati in modo che le persone siano libere di fare il check-in di cui hanno bisogno. Allo stesso tempo, tronco è relativamente libera da qualsiasi rotti check-in.

— Dipan Mehta
fonte