Christian @christian@deff.no

@erlendaasland har forsøkt å gjøre litt begrepsavklaring for å tydeliggjøre hva jeg mente: https://parenteser.mattilsynet.io/kontinuerlig-integrasjon/

@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 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.