Re: [Python] Github flow e release dopo lo sprint
On Tue, Mar 5, 2019 at 11:03 PM Simone Federici wrote: > Karim: > >> Il branch dove sviluppi la feature quindi e' creato dal release branch, >> non dal develop branch, giusto? >> > > abbiamo un "develop" branch per ogni subset di feature che vanno insieme. > ad esempio: > dev-3.2.x-bpm-probes > dev-3.2.x-built-in-report > dev-3.2.x-eureka > dev-3.2.x-full-text-search > > sono tutte branch separati dove sviluppiamo le feature specifiche. > Una volta testate e approvate viene fatto il loro merge sul master-3.2.x > Grazie -- Karim N. Gorjux ___ Python mailing list Python@lists.python.it https://lists.python.it/mailman/listinfo/python
Re: [Python] Github flow e release dopo lo sprint
Karim: > Il branch dove sviluppi la feature quindi e' creato dal release branch, > non dal develop branch, giusto? > abbiamo un "develop" branch per ogni subset di feature che vanno insieme. ad esempio: dev-3.2.x-bpm-probes dev-3.2.x-built-in-report dev-3.2.x-eureka dev-3.2.x-full-text-search sono tutte branch separati dove sviluppiamo le feature specifiche. Una volta testate e approvate viene fatto il loro merge sul master-3.2.x ___ Python mailing list Python@lists.python.it https://lists.python.it/mailman/listinfo/python
Re: [Python] Github flow e release dopo lo sprint
On Tue, Mar 5, 2019 at 7:10 PM Simone Federici wrote: > Noi abiamo uno stato dei ticket ready to merge. > Ogni gruppo di feature che vive insieme viene sviluppata su un branch. Se > due feature dipendono l’una dall’altra vanno nello stesso branch. > Il qa fa i test e segnala quali sono pronte per andare in release. > a quel punto le spostiamo sul ramo stabile dove effettuiamo ogni release. > Il branch dove sviluppi la feature quindi e' creato dal release branch, non dal develop branch, giusto? (Grazie per la risposta) -- Karim N. Gorjux ___ Python mailing list Python@lists.python.it https://lists.python.it/mailman/listinfo/python
Re: [Python] Github flow e release dopo lo sprint
Noi abiamo uno stato dei ticket ready to merge. Ogni gruppo di feature che vive insieme viene sviluppata su un branch. Se due feature dipendono l’una dall’altra vanno nello stesso branch. Il qa fa i test e segnala quali sono pronte per andare in release. a quel punto le spostiamo sul ramo stabile dove effettuiamo ogni release. On Tue, 5 Mar 2019 at 01:24, Karim wrote: > 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. > > 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. > > Tutto bene, tutto ok a parte un problema. > > 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. > > 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. > > 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. > > Il problema potrebbe essere se feature2, ad esempio dipende da feature1, > ma in quel caso feature2 sarebbe un branch del branch di feature1. > > Voi come fate? > > > [1] https://nvie.com/posts/a-successful-git-branching-model/ > -- > Karim N. Gorjux > ___ > Python mailing list > Python@lists.python.it > https://lists.python.it/mailman/listinfo/python > ___ Python mailing list Python@lists.python.it https://lists.python.it/mailman/listinfo/python
[Python] Github flow e release dopo lo sprint
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. 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. Tutto bene, tutto ok a parte un problema. 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. 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. 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. Il problema potrebbe essere se feature2, ad esempio dipende da feature1, ma in quel caso feature2 sarebbe un branch del branch di feature1. Voi come fate? [1] https://nvie.com/posts/a-successful-git-branching-model/ -- Karim N. Gorjux ___ Python mailing list Python@lists.python.it https://lists.python.it/mailman/listinfo/python
