Perché testare sul rilascio, non sviluppare

1

Usiamo il flusso git descritto qui . In questo modo, abbiamo 3 rami principali: sviluppo, master, release e feature branch.

Lo sviluppo è sviluppo. Dopo l'avvio dello sviluppo e l'implementazione delle funzionalità da sviluppare, i certificati di qualità si fondono per rilasciare dallo sviluppo per testare l'ambiente di controllo qualità.

Quindi le correzioni vanno a rilasciare, non a sviluppare. Il rilascio è ora il ramo principale.

Quindi il master viene creato dal rilascio e viene inserito nel preprod. Correzioni di bug sono andati a padroneggiare ora.

Quindi il rilascio viene creato dal master e anche unito per lo sviluppo.

Ma abbiamo bisogno di un ramo di rilascio? Possiamo farlo senza un ramo di rilascio?

    
posta vegan 22.07.2017 - 23:19
fonte

2 risposte

7

Se hai uno sviluppatore potresti essere in grado di farlo senza un ramo di rilascio. Tuttavia, si finisce con potenziali tempi di inattività durante l'attesa per il test. Git Stash rende più facile tornare indietro e correggere i bug. Dovrai monitorare attentamente il codice su cui stai lavorando.

L'errore / caso normale quando su un ramo è:

  • Lo sviluppatore si impegna a lavorare e richiede il test.
  • Alcuni sviluppatori impegnano più lavoro.
  • I tester costruiscono e testano (non il codice previsto).

L'utilizzo di due o più rami consente di testare e correggere i bug di un rilascio continuando allo sviluppo di nuove funzionalità. È comune avere un ramo di rilascio per versione.

Un altro motivo per utilizzare un ramo separato è che i bug possono richiedere un lavoro completo per la corretta correzione, ma possono avere un semplice work-around. La soluzione viene applicata al ramo di rilascio. Quindi la correzione corretta viene eseguita in fase di sviluppo. Il lavoro attorno potrebbe non essere ricollegato allo sviluppo.

    
risposta data 23.07.2017 - 01:00
fonte
2

Sono completamente in disaccordo con la risposta accettata.

Ciò che hai descritto è in realtà molto desiderabile. Il difetto nel modo di pensare dietro la risposta è il presupposto che la cosa testata sia il codice sul ramo in isolamento rispetto ad altri lavori, ma non è vero.

Dovresti testare il codice completamente integrato ogni volta che puoi.

In altre parole, l'idea di "non il codice che era destinato" è sbagliata. Diciamo che il sistema è testato e supera tutti i test. Se passa tutti i test con il codice sia quelli commessi dal primo sviluppatore sia il codice che è stato commesso dal secondo sviluppatore, è fantastico. Hai appena salvato un ciclo di test in più per dirti che il codice di entrambi i commit va bene.

Se il codice del secondo commit fa fallire i test, allora va anche bene. Hai appena salvato un ciclo di prova in più per dirti che il codice ha bisogno di una correzione.

Se il codice del primo commit causa il fallimento del test, hai imparato ciò che dovevi sapere indipendentemente dal secondo commit.

Se il codice dall'integrazione del primo e del secondo commit fa fallire il test, allora è grandioso. Hai salvato un ciclo di prova in più per dirti che i due sviluppatori devono collaborare per risolvere il problema di integrazione.

Essenzialmente non c'è alcun svantaggio nel testare il secondo commit e il primo. Non capisco da dove nel settore sia nata questa idea da un punto di vista tecnico. L'unica ragione per cui posso pensare a qualcuno a cui interesserebbe è che vogliono essere in grado di assegnare la colpa a un particolare sviluppatore per un test fallito. E questo suona piuttosto disfunzionale per me.

Tutto quello che stai facendo con questo tipo di strategia di sviluppo e ramificazione sta rendendo il processo di sviluppo più lento e più costoso.

    
risposta data 23.07.2017 - 02:48
fonte

Leggi altre domande sui tag