Come pubblicare 2 feature branch sul QA?

Question

Come pubblicare 2 feature branch sul QA?

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

2

Ho il seguente scenario:

Joe sta lavorando sul ramo feature-xx .
Richard sta lavorando in un altro ramo feature-yy .
La loro azienda ha un ambiente qa.myapp.com in cui i tester lavorano.
Joe inserisce il codice nel repository Github. Costruisci passaggi. qa.myapp.com viene aggiornato con il nuovo ramo di Joe, quindi i tester possono testare il suo lavoro.
Richard ha anche spinto la sua filiale. Genera passaggi e qa.myapp.com è ora aggiornato con il ramo di funzionalità di Richard. I tester ora possono lavorare, ma non possono testare il lavoro di Joe.

Esiste un modo per creare un "test-url" per ciascuna delle diramazioni di cui sopra per il team addetto al controllo qualità utilizzando gli strumenti "Continuous whatever" là fuori? In tal caso, qual è il termine che dovrei cercare?

Fondamentalmente quello che voglio è avere diversi Q.A. attivi. URL.

Qualcosa come:

feature-xx .qa.myapp.com < contenente solo codice per feature xx
feature-yy .qa.myapp.com < contenente solo codice per feature xx
qa.myapp.com < contenente correzioni di errori.

Entrambi i test url / ambienti devono essere generati dopo la generazione dei passaggi. Pertanto, una volta che il controllo qualità ha approvato le funzioni, tali URL dovrebbero essere eliminati.

A volte uno sviluppatore sta lavorando su una correzione di bug e ha bisogno che venga testato. Ma a volte un altro sviluppatore sta lavorando in una funzione e vuole anche che venga testato allo stesso tempo e non vogliono aspettare che la macchina QA sia libera di testare la sua funzionalità.

Penso che usare Docker + Containers sia la strada da percorrere.

branching qa acceptance-testing

posta Daniel Lima 07.02.2017 - 16:50

fonte

2 risposte

Leggi altre domande sui tag branching qa acceptance-testing

Comunicare gli avvisi nel contesto dell'elemento della configurazione: Nodejs, Grunt, Slack Applicare le operazioni matematiche sulla colonna della tabella

score 1 · Answer 1

Il modo in cui risolverei i tuoi problemi è costruendo da ogni ramo anziché da master. Tuttavia, ciò richiederebbe che il master venga unito in ciascun ramo prima se si sono divergenti. Quindi potresti facilmente fare in modo che jenkins costruisca un'immagine docker di ciascun ramo e che le immagini vengano distribuite in un modo che si adatti al tuo team di QA.

Tuttavia , e questo è un commento sul processo, quindi sentiti libero di ignorarlo:

Per me sembra molto controproducente per il tuo team di QA testare separatamente il codice di Joe e Richard. Se Joes ha un qualche impatto sul lavoro di Richards o viceversa, quando lo saprai? In produzione? Oppure hai una terza iterazione del QA in cui testano che entrambe le funzioni funzionano all'unisono? Sembra solo che Lika abbia un sacco di lavoro extra non avendo il QA testare il risultato reale.

score 0 · Answer 2

Non cambierò il nome host, ma il percorso di contesto, ad es. qa.myapp.com/feature1 invece di feature1.qa.myapp.com.

Se questa è una webappp Java, puoi facilmente ottenere ciò cambiando il nome di .war e distribuendolo nello stesso contenitore.

Ma poi affronterai la prossima domanda: hai modifiche DB incompatibili. O altre risorse come code di messaggi. Puoi anche risolverlo, ma di solito è più complicato, complesso e soggetto a errori.

In conclusione: se hai la libertà di farlo, vai con la finestra mobile.