DevOps – mer enn et buzzword? En utviklers beretning. Del 1

DevOps er et ord som i den senere tid har poppet opp i IT-verdenen. Det er lett å miste tråden når man snakker om DevOps, for det er brukt i forferdelig mange sammenhenger. Man hører DevOps som en stilling, mange søker etter “DevOps Engineer”, det er et produkt hos noen selskaper (bl.a Azure DevOps), noen tenker på det som en kultur man har i selskapet, mens blant annet wikipedia kategoriserer det som et sett med utviklingsmetoder.

I hine håne dager

Nå skal jeg gå veldig langt tilbake i tid, i en tid hvor selskaper hadde egne avdelinger som hadde ansvar for å drifte noe man kalte servere, disse stod i egne rom som man kalte server-rom. Disse avdelingene kalles på engelsk “Operations”, på norsk kalles det ofte “Drift”.

Det er kanskje ikke så galt, at man ikke har slike avdelinger lenger. Men med alle sky-leverandører man har, bare ett klikk unna, er det ikke det samme behovet som tidligere for å ha en “Drifts-avdeling”.

Enda lever vi i en verden hvor det er mennesker som skriver kommandoer til datamaskiner. Disse kalles på engelsk “Developers” og på norsk kaller vi de utviklere. I gamle dager var det ofte slik at utviklings-avdelingene lagde programvare. Når den var ferdig, da ga man den til “Drift” for at de skulle gjøre noe greier med den, og ble så satt i “Test” og noen gikk inn og testet at ting funket. Om - men som oftest når - alt var som forventet, kom programvaren i “Produksjon”. Og det var da brukerne kunne teste ut den helt nye versjonen man hadde jobbet så lenge med å få ferdig. Og «Produksjon», det var det bare (BARE) “Drift” som kunne røre.

Å ha slike skott som det blir med å ha avdelinger for Drift og Utvikling, det gjør ikke underverker for produktiviteten til et selskap. Ei heller forholdet mellom avdelinger.

Glidende overgang

Når smidig-gjengen, med Scrum, Kanban, Agile og Lean i spissen, startet å gjøre sitt inntog i organisasjoner rundtom i verden, da startet vel folk å forstå at man trengte organisasjoner som ikke gjenspeilet gamle metodikker for prosjektstyring, som Fossefall. Plutselig skulle avdelingene “Drift” og “Utvikling” hete “Drift og Utvikling”. Men man hadde ofte det samme ansvaret, Drift hadde ansvar for at ting kjørte i produksjon, og Utvikling hadde ansvar for at man lagde programvare. Forskjellen nå var at man brukte smidig-metodikker når man utviklet programvare. Og man startet å sende oppdaterte versjoner av applikasjonene sine til produksjon oftere, typ 6 uker.

Bare dryss litt DevOps over det

Jeg husker første gang jeg hørte om at det var noen som deployet flere ganger om dagen, jeg ble sjokkert. Hvordan skulle liksom kunder akseptere det? Ting kunne gå ned, databasen måtte kanskje gjenopprettes om noe gikk galt, helt uaktuelt at dette kunne funke i praksis! Men jeg visste at det funket, for jeg var kunden til denne tjenesten – til Flickr. Denne, den gang, flotte bildedelings- og backup-tjenesten. Ikke bare deployet de flere ganger om dagen, de hadde også noe greier man kalte for “Feature flags”. Som gjør at man kan snik-innføre nye ting eller endringer på enkelte brukere. Alle brukere som har et brukernavn som starter på “Z” får denne versjonen av web-siden, mens resten får den gamle vanlige, men all koden kjørte fra samme kode-base.

For å få til å deploye hele tiden hadde flickr implementert en helautomatisk build-, test- og deployment-pipeline. Noen kaller dette CI/CD-pipeline (Continuous Integration / Continuous Delivery / Continuous Deployment), andre kaller dette en “DevOps”-pipeline.

Sagt på en annen måte er dette automatiserte steg som tar kildekoden fra en plass, kjører den gjennom forskjellige type tester, alt fra kode-syntax, skrivefeil, og helt opp til store integrasjonstester mot eksterne systemer. Om alle disse testene passerer, da blir det automatisk sendt til produksjon.

Når flere forstod hva selskaper som flickr gjorde, at de hadde automatisert alt som skjer etter man skriver kode, da startet ballen å rulle. Tenk at man kan automatisere noe man tidligere måtte ha folk til å gjøre – profit!

Men det er jo ikke så enkelt

Å lage en ny tjeneste og bake inn automatisert test, deployment, monitorering, varsling osv, gjør ikke at det tar så mye lenger tid å lage tjenesten. Men å legge dette til for en eksisterende applikasjon, og passe inn i et eksisterende miljø, det er litt av en oppgave. Man blir møtt av teknologi og tjenester som ble lagd og satt opp av folk – og de er de verste (folk altså)! Folk kan gjøre feil, som f.eks skrivefeil, man kan finne på å kalle en tjeneste for “QWERTYASDFG”, når den soleklart burde hete “nor-krs-app-01”. Ikke lett å lage verktøy som skal automatiseres i en slik verden. Men vi prøvde. Og det ble litt så som så i begynnelsen.

end

Enda forvirret? La oss se om vi får samlet noen tråder i del 2?