Team kjøremiljø steller i stand utviklingsfesten!
Vårt oppdrag er å lage en felles verktøykasse for produksjonsmiljø som er sikker og brukervennlig, slik at utviklere i Origo får mer tid til å fokusere på sine produkter 🎉
Vi løser oppdraget vårt ved å lage konfigurerbar infrastruktur som produktteamene i Origo kan benytte for å selv sette opp det de trenger. Vi har latt oss inspirere av Spotifys “golden path” og Netflix’ “paved road”, og har lagd vår egen “brolagte sti”.
Teamene kan benytte den brolagt sti for eksempel for å kjapt komme i gang med å kjøre en containerbasert applikasjon med ECS (Elastic Container Service) i AWS, med et ferdig og sikkert oppsett ut av boksen som tilbyr persistens, logging, monitorering, alerts, og så videre.
Teknisk sett består den brolagte stien blant annet av et sett av Terraform-moduler og templates som teamene kan importere og konfigurere. I tillegg satser vi på god og brukervennlig dokumentajson som gjør det lett for teamene å bruke den brolagte stien.
Vi lager også et kommandolinjeverktøy som gjør det enklere å komme i gang og utføre vanlige oppgaver. Foreløpig er verktøyet bare en minimal prototype skrevet i Bash, men den skal over i Golang.
Tanken bak
Vi kommer helt sikkert til å treffe på noen hindre, men noen av målene med denne løsningen er
- Det gjør det lett for utviklere å komme i gang med et produksjonsklart kjøremiljø.
- Fleksibilitet: Teamene kan lett eksperimentere med infrastrukturen for å dekke sine behov. Slike eksperimenter kan team kjøremiljø vurdere å ta inn i den brolagt stien.
- Vi vil unngå å lage en komplisert, selvutviklet plattform som ikke klarer å følge med på den raske tekniske utviklingen. Vi ønsker at utviklerne våre heller lærer seg Terraform og AWS enn en egenutviklet platform.
- Transparens: Det er kort vei for teamene for å kunne se på og forstå infrastrukturen de bruker.
Smidighet og lav-formalitet
Metoden vår er: smidig? Men det er så 2010. Vi følger på ingen måte en smidig metode blindt etter boka. Vi tror ikke helt at det finnes én riktig måte å jobbe på, men kanban er nok den metodikken som ligner mest på det vi driver med.
Standup løser vi med en daglig “slack-up” i tekstlig format, men vi tar stadige småprater eller videomøter for å sparre og finne ut av ting.
Vi verdsetter å være åpne og imøtekommende folk, så vi har for eksempel:
- (Nesten) åpen GitHub Projects
- Ingen privat kanal på slack
- Åpne møter hvor hvem som helst kan stikke innom
- Utrolig lav terskel for en prat, fjas, et support-spørsmål eller en meme i Slack-kanalen vår
Support, innsikt og samarbeid
Om noen lurer på noe, så er det takhøyde for de fleste spørsmål i vår support-kanal. Vi hjelper gjerne med ting som går utover det som er relatert til infrastruktur.
Innsikt fra brukere er i stor grad med på å prioritere oppgavene våre. Vi snakker med teamene jevnlig, vi bruker teknikker fra tjenestedesign som brukerreiser, og gjør mye brukertesting på det vi lager.
En gang i blant jobber vi også sammen med et team, hvor alle er med samtidig. Da er det ofte for å migrere infrastruktur eller liknende. Dette kaller vi mob-opsing – det samme som mob-programming, men for operations. Vi har erfart at når flere jobber sammen blir resultatet bedre og alle lærer mer.
