Recent searches
Search options
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).
@erlendaasland@fosstodon.org@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.