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.
@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.
@erlendaasland I tillegg til de åpenbare fordelene i den kontinuerlige flyten så vil denne måten å jobbe på tvinge deg til å skrive koden din på en måte som tåler å gå i prod. Da lager man ny kode på siden først, gjør noen refaktoreringer for å "lage plass", og kobler på nye features helt til slutt. Kanskje med en feature toggle, men ikke nødvendigvis. PR-flyten tillater i mye større grad å begi seg utpå langt mer ambisiøse prosjekter og mangler rettesnoren om å holde seg "prod-kompatibel".
@erlendaasland I tillegg: Siden du hele tiden er på main er det lett å kontekst-svitsje over til å ta unna små bugfikser eller andre ting som dukker opp underveis, uten å måtte gjøre unødige git-armhevinger, eller i verste fall - å la være å fikse ting på main, fordi du vet det kommer til å gå i konflikt med branchen din.
@christian Eg trur me er einige i dei store linjene her; å jobbe på main (eller kall det gjerne dev) heile tida er fint. Atomiske og konsise commits er bra. Men eg ser framleis ingen motsetnad med dette og PR.
@erlendaasland "Kall det gjerne dev" - hva er dette? Enda flere brancher? For hver branch du lager tar du et skritt bort fra kontinuerlig integrasjon.
@christian Nei, du misforstår meg; eg snakkar ikkje om å laga eit virvarr av greiner. Eg trur ikkje me kjem nokon veg vidare her; du meinar bestemt at PR ikkje har noko med CI å gjera. Eg meiner desse tinga kan kombinerast. Lukke til vidare!
@erlendaasland Vi snakker forbi hverandre. Kanskje du mener automatiserte bygg? "CI"/kontinuerlig integrasjon er prosess og ikke verktøy. Mitt poeng er at PR er en prosess med mer byråkrati enn å jobbe rett på main - uavhengig av om det er automatisert bygg i etterkant eller ikke. Men vi blir nok ikke enige som du sier 😊
@erlendaasland har forsøkt å gjøre litt begrepsavklaring for å tydeliggjøre hva jeg mente: https://parenteser.mattilsynet.io/kontinuerlig-integrasjon/
@christian Ser ut til at du har moderert deg litt ;) Pragmatismen lenge leve. Eg er som sagt einig i den overordna filosofien. Berre så det er sagt, så meinte eg ikkje verktøy, men metodikk, då eg sa «CI».
@erlendaasland tja, jeg står på at PR per definisjon står i kontrast til CI. Jeg burde uansett startet med noen definisjoner, noterer meg til neste gang 😊
@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?
@christian Sjølvsagt skal ein ha diskusjon både kode og feature/bugfiks i forkant. Det er jo på kanten til implisitt i ein moderne utviklingsflyt. Her er ingen motsetnad med bruk av pull request.
@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.