For å få til kontinuerlig leveranse i Team Mat, vil vi minimere herk knyttet til hver leveranse.
Det krever at vi tar tak i det som lugger når vi leverer.
Dagens tekst beskriver et steg som lugget, og hvordan git-worktree var del av løsningen.
Jeg vil skrive god kode.
Jeg vil være stolt av koden—både koden jeg har skrevet selv, og koden andre har skrevet.
Dit kan man komme med parprogrammering!
Å oppleve lynraske modultester i bruk har endret på hvordan jeg liker å strukturere og jobbe med kode.
Kanskje lynraske modultester er noe for deg også?
Hva gir det mening å fokusere på når man starter i en ny jobb?
Hva driver Øyvind, Christian og Magnar med fra dag til dag?
Jeg deler mine erfaringer fra mine første to uker.
Git-historikk kan by på verdifull kontekst som hjelper oss å forstå hvorfor
koden vår er som den er. Særlig hvis den består av gode commits. Men hva utgjør
en god commit?
På årets JavaZone holdt jeg et innlegg om hvordan vi får til å levere
kontinuerlig. Fokuset var på de små detaljene. Jeg viste hvordan vi bryter opp
arbeidet sånn at vi kan jobbe rett på main og rett i prod, enten vi gjør litt
refaktorering eller bygger en helt ny innloggingsløsning.
Vi dytter kode rett til main, som bygges rett ut i prod. Ingen feature branches.
Ikke noe staging-miljø. Men hvordan funker det når vi skal lage omfattende funksjonalitet?
Står pull requests i kontrast til kontinuerlig integrasjon? Er kontinuerlig
integrasjon det samme som CI? Hva med CI/CD? Jeg forsøker å oppklare noen
uklarheter fra mitt forrige innlegg om pull requests.
Pull requests har blitt en så vanlig arbeidsform at det for mange er synonymt
med å bruke git. Men er det en bra ting? Må alle endringer komme via en pull
request? Jeg er ikke så sikker.