Det skal være lett å gjøre rett — del 3
I forrige artikkel i serien så vi på noen av verktøyene vi bruker til utvikling. Nå skal vi se mer på noe som er minst like viktig, nemlig å få koden ut i produksjon.
Som vi vet fra blant annet Accelerate er en av tingene som skiller organisasjoner med høy og lav ytelse er hvor ofte kode rulles ut til produksjon. Hyppige produksjonssettinger fører til færre produksjonsfeil, kortere mean time to recovery (Tiden det tar fra en feil oppstår til den er fikset) og kortere ledetid fra commit til prodsetting.
Men det er ikke nok å rulle ut kode til produksjon ofte, det må gjøres på en forutsigbar og trygg måte. Det må kunne gjøres med lave skuldre. Og som de fleste som har vært med på kvartalsvise eller halvårsreleaser som gjøres manuelt kan si: Det å prodsette sjeldent gjør veldig vondt.
Det finnes mange artikler som sier noe om hvorfor store releaser gjør vondt, men i bunn og grunn handler det om at dersom du prodsetter mange endringer samtidig, så er sannsynligheten for at det er feil i en av de stor. Og da må hele leveransen rulles tilbake, prosjektledere og interessenter må informeres og du må jobbe overtid for å fikse det. Så må ny produksjonssetting planlegges og driftsressurser må bookes på nytt. Kanskje det til og med blir nattarbeid.
Dersom endringssettet du prodsetter er mindre, så er det også mindre som må rulles tilbake, og konsekvensen blir lavere. I tillegg så blir mulighetsrommet for feil lavere. Det er færre endringer, og dermed færre mulige syndere som må sjekkes ut.
Applikasjonsarkitektur og verktøy spiller sammen
Hvis du skal kunne levere kode hyppig, må du også ha en applikasjonsarkitektur som støtter opp under dette. Det finnes flere måter å angripe problemstillingen på, men det vanligste i dag er å dele opp i mindre tilstandsløse applikasjoner som tilsammen utgjør et system.
Vi har valgt å basere våre containerbaserte applikasjoner på manifestet The Twelve-Factor App. Det er et manifest som er skrevet av folkene bak tjenesten Heroku. Manifestet beskriver 12 egenskaper de mener at moderne applikasjoner bør ha. Dette setter en del krav til applikasjonene vi deployer:
Applikasjonene må være tilstandsløse. Det gjør at applikasjonene er lettere å forvalte og forstå, de blir enklere å skalere horisontalt og det gjør at de passer bedre inn i en verden hvor de kan bli revet ned og startet opp i løpet av sekunder.
Hemmeligheter, som er typisk api-nøkler, sertifikater og passord, injiseres fra miljøet rundt. Vi har i tillegg valgt å gjøre løsningen for å legge inn hemmeligheter i en app selvbetjent, slik at om du er en DBA som har generert en databasebruker, legger du den selv inn i applikasjonen som skal ha hemmeligheten. Dermed slipper vi å sende hemmeligheter rundt på mer eller mindre kreative måter som sms, epost eller post-it lapper.
Deployment
Vi har opp gjennom årene hatt flere verktøy for deployment. Felles for disse er at de som regel har løst et spesifikt problem i et spesifikt miljø. Da vi skulle ha et verktøy til containerplattformen vår, ville vi ha et verktøy som kunne løse deployment i alle miljøer. Vi valgte til slutt å lage vårt eget deploymentverktøy, som var tilpasset våre prosesser og vårt miljø.
Resultatet ble Shifter! Som noen sikkert vet er Shifter også en karakter fra Byggmester Bob, og han er ganske god på å flytte rundt på containere.
Litt av grunnen til at vi valgte å utvikle vårt eget deployment-verktøy var fordi vi ville tilpasse det til våre behov og våre verktøy. Blant annet så ønsket vi å kunne vise relevante metrics fra applikasjonen direkte i grensesnittet, slik at man enkelt kan følge med på hva som skjer når man prodsetter en endring.
Her har du relevante metrikker for responstid, feilrater og ressursbruk.
I tillegg til det grafiske grensesnittet har Shifter et restbasert API som kan benyttes fra jenkins og andre script for å bygge og deploye applikasjoner. Derfor har shifter blitt en viktig del av både utvikling og produksjonsetting hos oss, som hjelper oss å sove godt om natten.
I del fire av denne serien skal vi skrive litt om hvordan vi organiserer oss for å kunne jobbe godt med kontinuerlig forbedring av verktøyene våre.
