Etter å ha skrevet om pull requests innså jeg at jeg burde ha starta med å skrive om kontinuerlig integrasjon. Aldri for sent, si: https://parenteser.mattilsynet.io/kontinuerlig-integrasjon/
Det er såklart mye mulig her at mitt hode er for preget av en tankegang der man må kjøre test/bygg på en byggeserver for å være "sikker" og at det i ditt hode er en selvfølge at alt slikt gjøres før en commit, slik at man ikke er "avhengig" av en byggeserver som gatekeeper main
Men jeg veit ikke?
@atlefren jeg har ikke adressert detaljene i arbeidsflyten jeg mener er best nei, det får bli en ny oppfølger 😊 men kort sagt opererer vi uten å være helt sikker. Ingenting deployes om testene feiler. Ideelt sett pusher man ikke kode som ikke er prod-klart, men det skjer. Da må man bare fikse det så fort som mulig. Kjører noe tester lokalt, men hender absolutt at jeg glemmer det. Og noen ganger går det feil i prodbygget. Så lenge man fikser kjapt er det ikke noe stort problem.
@christian jeg leser gjerne den bloggposten også!
Men det du skriver her gir jo absolutt mening!
@christian
Gode poster både denne og den forrige.
Og kanskje du egentlig svarer på det, men et spørsmål jeg sitter igjen med er: "mange har automatisert kjøring av tester og diverse andre sjekker som skal kjøres før kode deles med andre (merges til main hvis vi snakker PR-sjargong).
I en CI-kontekst slik du beskriver den, er det da slik at alt dette gjøres på den enkelte utviklers maskin? Slik at man ikke har sjekket inn kode som feiler tester etc?
For feil vil jo skje, ting vil brekke?