Hvorfor har det blitt så populært å jobbe med pull requester når vi vet at kontinuerlig integrasjon gir økt kvalitet? Jeg har skrevet litt om hvorfor jeg mener PRs er en dårlig match for teamarbeid https://parenteser.mattilsynet.io/pull-requests/
@christian Det er jo ingen motsetnad mellom kontinuerleg integrasjon, parprogrammering og PR, slik eg ser det. Kanskje problemet eigentleg er at det er manglande retningslinjer for utviklingsflyten (korleis bruke bugtracker? kva skal ein commit innehalde? kva er eit bra PR? korleis skal review gjerast? etc.)
@erlendaasland hvis du har en arbeidsflyt der du kjører alle endringer via PR så har du ikke kontinuerlig integrasjon. Koden blir ikke integrert i main før du har gått gjennom en manuell prosess. Det er det motsatte av kontinuerlig integrasjon.
@erlendaasland du kan selvfølgelig bøte på den mindre smidige prosessen med retningslinjer og kortere responstid, men det er like fullt en fundamentalt annerledes måte å jobbe på. Dersom alt går på main og så rett i prod får du helt andre spaker å dra i.
@erlendaasland Forøvrig: en god PR inneholder ingen kode, bare en skissert løsning før man starter kodingen. Det er den eneste måten å diskutere løsningen før det allerede er investert tid og energi i ett mulig spor, sunk cost melder seg osv. Men jeg syns parprogrammering er en bedre løsning.
@christian Det du snakkar om der er ein issue-tracker. Eit bra PR er kopla til eit issue i bugtracker; løysninga vert diskutert i issuet først.
@erlendaasland poenget mitt er at diskusjonen om koden må foregå før eller mens den skrives. Ikke etterpå. Ergo har en pull request lite for seg (i miljøer med høy tillit).
@christian Vel, det er jo derfor ein har nyttige verktøy som spesifikasjon og bugtracker; ein diskuterer design og implementasjonsstrategi først, deretter skriv ein kode, som gjerne kan kome i form av PR, og gjerne som produkt av parprogrammering; eg ser ingen motsetnadar her.
@erlendaasland Siste forsøk på forklare poenget mitt:
Du skal bygge en ny feature. Det tar tre dager. Med pull requests lever du på en branch i tre dager. Du kan jevnlig rebase med main, men du går glipp av kode på andre brancher. Når PR-en din er klar ser du at det er en stor konflikt med en annen PR. Førstemann i mål!
@erlendaasland I kontrast: kontinuerlig integrasjon. Alt arbeid committes løpende (kontinuerlig, kan du si) til main. Jeg rebaser jevnlig med main, hvor alle andres pågående arbeid kontinuerlig dukker opp, og pusher mine endringer jevnlig. Alle endringene fra den store konflikten kommer som små bruddstykker som lett flettes sammen underveis.
@christian Sjølvsagt er atomiske og små commits å føretrekka. Poenget mitt er at å jobba med PR ikkje er nokon motsetnad her.
@erlendaasland Det hjelper ikke at du har mange små atomiske commits i en PR som utvikles på en branch på siden over flere dager.
@christian Du antar at ein PR automatisk går over fleire dagar; slik er det jo ikkje.
@erlendaasland Sånn er det nok mange steder! Jeg vil ihvertfall anta at de aller færreste PR-er består av én bitteliten commit. Og om de er, så har du ikke engang kontinuerlig integrasjon med eget arbeid, ettersom du kommer til å produsere PR-er raskere enn de blir reviewet... Hva er galt med å pushe til main, og så lese commits når du rebaser med main?
