<div dir="auto">Noi abiamo uno stato dei ticket ready to merge.</div><div dir="auto">Ogni gruppo di feature che vive insieme viene sviluppata su un branch. Se due feature dipendono l’una dall’altra vanno nello stesso branch. </div><div dir="auto">Il qa fa i test e segnala quali sono pronte per andare in release.</div><div dir="auto">a quel punto le spostiamo sul ramo stabile dove effettuiamo ogni release.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 5 Mar 2019 at 01:24, Karim <<a href="mailto:lemieliste@gmail.com">lemieliste@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Ciao lista, ho scritto questo messaggio su django italia su telegram, ma ho pensato che la mailing list sia anche un buon spunto per poterne discutere.</div><br></div><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Seguendo il gitflow[1] mi ritrovo a lavorare prendendo da `develop` (QA) l'ultimo codice, lavorare nel mio branch e poi rilasciare su `develop` per far si che possa essere testato sull'env di QA.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Tutto bene, tutto ok a parte un problema.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Seguendo lo scrum, alla fine dello sprint, il product owner dovrebbe fare decidere cosa e' pronto per andare in release e cosa non lo e'. Qui sta il problema. Non sempre tutte le feature che sono state lavorare durante lo sprint sono promosse per la release, succede a volte che qualcosa deve essere cambiato e viene rimandato allo sprint successivo.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Se ad esempio abbiamo feature1, feature2, feature3, feature4 che sono state sviluppate partendo dal branch develop, a meno che non si fa il merge di develop in release con tutte le feature[1-4] allora puo' diventare impegnativo fare un release selezionata.</div></div><div dir="ltr"><br></div><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">La prima cosa che mi viene in mente e' di sviluppare le feature partendo i propri branch da release invece che da develop e ovviamente rendendo le feature completamente indipendenti. Questo significa che le varie feature* possono essere applicate senza ripercussioni sia su develop che su release senza rompere i branch.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Il problema potrebbe essere se feature2, ad esempio dipende da feature1, ma in quel caso  feature2 sarebbe un branch del branch di feature1.</div><br></div><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Voi come fate?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><div dir="ltr"><br></div><div dir="ltr"><span class="gmail_default" style="font-family:verdana,sans-serif">[1] </span><a href="https://nvie.com/posts/a-successful-git-branching-model/" target="_blank">https://nvie.com/posts/a-successful-git-branching-model/</a></div></div><div dir="ltr"><div dir="ltr">-- <br><div dir="ltr" class="m_7890610329117590808gmail_signature"><div dir="ltr">Karim N. Gorjux<br></div></div></div></div>
_______________________________________________<br>
Python mailing list<br>
<a href="mailto:Python@lists.python.it" target="_blank">Python@lists.python.it</a><br>
<a href="https://lists.python.it/mailman/listinfo/python" rel="noreferrer" target="_blank">https://lists.python.it/mailman/listinfo/python</a><br>
</blockquote></div></div>