@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?
@erlendaasland "Kall det gjerne dev" - hva er dette? Enda flere brancher? For hver branch du lager tar du et skritt bort fra kontinuerlig integrasjon.
@erlendaasland Det hjelper ikke at du har mange små atomiske commits i en PR som utvikles på en branch på siden over flere dager.
@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.
@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 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 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 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 jeg mener kontinuerlig integrasjon: alles kode integreres med alles kode kontinuerlig. Når alle jobber på hver sin branch skjer dette ikke kontinuerlig, men i batch. Du må gjerne kaste systemer på situasjonen, men det blir ikke kontinuerlig integrasjon av det.
@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.
@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 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.
@glenjamin yes, everything goes directly to production. Since this happens many times per day it becomes less scary, and mostly problems are easily correlated with very few commits. Highly recommended!
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/
@lettosprey @forteller for noe rør. Jeg kjører fra sone 2S. Selv med 4 dager på kontoret i uka (vanlig uke, av og til færre) er månedskort dyrere enn reis...
@forteller hva, skal de kutte ut rabatten? 🤬
A very Norwegian defn #clojure episode with @magnars and @christian is out
You don't have to rewrite your apps every 3-5 years. You just need to design it with some care. I recently gave a presentation about the architecture that helped our frontend codebase stay in kick ass shape, even after 9 years of continuous work: https://vimeo.com/861600197
@headius it was very interesting and well presented, thanks!
I play guitar and board games, I write Clojure for work and fun, and I bake bread, cook and occasionally brew beer.