Newsgroup: it.lavoro.informatica
Titolo: Trunk-based development

Una lettura molto interessante:
 
https://trunkbaseddevelopment.com/
 
 
 

 
https://trunkbaseddevelopment.com/
 
 
Mi sembra molto simile al Github flow, branch sul master e PR per
richiedere code review.
https://guides.github.com/introduction/flow/
 
 
  ngw
 
 

 
https://guides.github.com/introduction/flow/
 
 
Si`, infatti qui (
https://trunkbaseddevelopment.com/alternative-branching-models/
) dicono di GitHub flow: "This is sooooo close to PR-centric Trunk-Based Development".
 
 
 


non proprio. a quanto leggo il principio è che tutti si committa sul ramo 
principale, il github flow è "compatibile" (che vorrà dire...) ma non è 
istituzionalizzato nel processo che si usino branch tantomeno pr.
 
noi ormai da anni utiliziamo gitlab privato in azienda che ha un flusso 
simile solo che parte dalla issue. issue -> branch -> merge request 
(equivalente delle pr di github). di overhead non ne vedo, ci sono dei 
vantaggi indubbi (per esempio, la possibilità di fissare delle mailstone, 
monitorare la durata degli sviluppi, changelog, code review, etc...) per 
cui non vedo la necessità di saltare a piè pari i passaggi. abbiamo fatto 
tranquillamente anche due/tre rilasci al giorno.
 
 

 (equivalente delle pr di github). 
 
Ma qual e` il ciclo vitale dei vostri branch? Per cosa vengono creati e quanto a lungo vivono?

 monitorare
 
fissare *mailstone" ?
Non ti facevo cosi' forbito! ;-)
 
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)


nun te preoccupa' so scalabili!



si creano a partire dalla issue e solitamente vivono poco, da poche ore a 
qualche giorno.
 

 qualche giorno.
 
E le code review le fate con l'analogo delle PR?
 
La cosa che non mi piacerebbe di un metodo di lavoro del genere e` che giorni di vita di un branch sono un periodo potenzialmente troppo lungo... 
 


Partono da una story su pivotal che viene portata su cucumber, finita
l'implementazione si posta su Slack la PR e si aspetta la review dei
colleghi, e al merge e' Github che chiede se cancellare il branch (e si
cancella).
 
  ngw
 
 

 E le code review le fate con l'analogo delle PR?
 
si.
aggiungo poi che per la ci, laddove la applichiamo, usiamo le pipeline 
sempre di gitlab su tutti i branch. è vero ci può essere disallineamento 
fra il branch e il ramo principale, ma vige l'obbligo che il 
programmatore faccia un rebase prima di fare la merge request (si 
controlla prima di accettare quest'ultima) inoltre le merge request 
vengono normalmente accettate subito.  

 cancella).
 
Stesso meccanismo di BitBucket.

 sempre di gitlab su tutti i branch.
 
Interessante il CI integrato in GitLab. Ho sempre e solo usato Jenkins e TeamCity, esterni all'hosting, ma nella mia nuova azienda si usa Bamboo integrato in Bitbucket e sono curioso di vederlo all'opera.
 

 E` per quello che trovo il trunk-based development interessante. A meno ovviamente di avere pull requests minuscole (quindi feature branch short-lived). Alcuni propongono di evitare le code review quando si e` in pochi e ognuno si fida. Da sviluppatore, pero`, non so se mi fiderei mai di altri sviluppatori :)
 
Beh, le review sono molto utili se non sono di mero controllo, ma
risultano in suggerimenti che riguardano anche la qualita' del codice.
Si impara parecchio sotto quel punto di vista
 
  ngw

 Si impara parecchio sotto quel punto di vista
 
Condivido.

 C'e` una ragione precisa per cui prediligete rebase al merge?
 
Cazzata, scusa. E` chiaro che il rebase in quel caso e` per aggiornare il branch agli ultimi sviluppi su master.

 C'e` una ragione precisa per cui prediligete rebase al merge?
 
perché preserva la storia corretta delle commit.