Devops er ikke en tjeneste du kan kjøpe

Devops er ikke en tjeneste du kan kjøpe

KRONIKK: Computerworld hadde den 6. november en lengre artikkel om Devops kalt "Fjerner tuene mellom utvikling og drift". Her var det mye bra, men også flere ting som fikk meg til å riste på hodet.

Under det første bildet sto det: ”Når sprinten er ferdig føres resultatet opp på en ny oppgavetavle for testing, kvalitetssikring og produksjonssetting. Produksjon overvåkes og avvik meldes tilbake til utvikling.” Hvilke tuer har de valgt å fjerne her? Slik jeg leser dette, så har de valgt å beholde skillene mellom utvikling, test og drift, og da mangler de noe vesentlig i forhold til Devops.

Ett av suksesskriteriene for smidig har vært å plassere utviklere sammen med forretning slik at de kan gi hverandre raske tilbakemeldinger på jobben som blir gjort. For å få enda bedre og raskere tilbakemeldinger har de mest fremoverlente organisasjonene sett at også utvikling og drift må jobbe tettere sammen. Dette er for meg kjernen til Devops. Det handler om mennesker, kultur og kommunikasjon. Og ikke minst organisasjon. Dette er stikkord som fikk liten plass i artikkelen, og er ikke noe du bare kan kjøpe.

Da jeg begynte i bransjen for 15 år siden var det akseptabelt med noen få leveranser i året, og vi kunne bruke en hel helg på å rulle ut en ny versjon. Slik er det ikke lenger; endringene skal rulles ut fortløpende og brukerne forventer at det gjøres uten nedetid.

Devops er på mange måter en videreføring av smidig slik flere i artikkelen var inne på. Mens smidig (tilbake i 2001, da Agile manifesto ble laget) snakker om to til åtte uker mellom hver leveranse, tar Devops det ett skritt lenger og snakker om flere leveranser hver dag.

Tradisjonelt har utvikling hatt fokus på å levere mest mulig ny funksjonalitet, mens drift har hatt fokus på sikker og stabil drift. Dette skaper fort en interessekonflikt om de da ikke greier å se utfordringene fra den andre siden og ikke bare fokusere på seg selv.

Devops handler først og fremst om å rive ned skillet mellom utvikling og drift, og sette fokus på felles mål for bedriften og brukernes beste. Mindre oss og dem – mer vi. Vi snakker ett team med felles ansvar. En frase som ofte trekkes frem er "You build it – you run it".

Hvis du skal ønske DevOps velkommen i din organisasjon, må du være forberedt på å måtte gjøre flere organisatoriske endringer.

Det første du bør være innstilt på er å fjerne siloene mellom drift og utvikling som vi allerede har vært inne på.

For det andre bør du se på hvordan teamene dine er organisert. "Conway´s law" sier i korte trekk at arkitekturen din blir et speil på hvordan organisasjonen din er bygget opp. For å kunne bygge den arkitekturen som er best egnet for å støtte forretningen, må du være innstilt på å organisere deg deretter. I tillegg bør du forsøke å organisere teamene dine slik at de får færrest mulig koplinger til hverandre. Vi kaller gjerne dette "feature teams" noe som innebærer at teamene på egen hånd er i stand til å utvikle og levere funksjonalitet uten å måtte koordinere unødvendig med andre.

I Norge er det ganske vanlig å levere ny funksjonalitet gjennom prosjekter, mens forvaltningen tar seg av de daglige problemstillingene i produksjon. Prosjektet overleverer et sett med applikasjoner til forvaltningen når det er ferdig, og ved behov for nye investeringer så startes et nytt prosjekt.

Denne modellen blir utfordret når leveransehyppigheten går opp. Hvis prosjektet leverer ny versjon hver dag – hvem skal da forvalte denne kodebasen i produksjon?

Med hyppige leveranser og tilbakemeldinger fra sluttbrukere, passer Devops veldig godt til en modell hvor produktet er i fokus. Bedriften investerer i produktet, løpende, helt til de beslutter å ta produktet ut av produksjon. Det vil fremdeles være behov for prosjekter, men da først og fremst når det er behov for mye koordinering på tvers av team og avdelinger. Den daglige iterative utviklingen gjøres best i produktteamet som kjenner både domenet og sluttbruker best.

Uten verktøy og automatisering kan det bli vanskelig å få til den endringstakten og kvaliteten vi ønsker. De er derfor viktige byggeklosser i Devops, men dette er ting vi som utviklere og driftere er ganske flinke på. Derfor bør vi i større grad fokusere på at vi som mennesker skal organiseres tettere, kommunisere bedre og få en felles kultur. Det er dette som er den største utfordringen, og slik vil det også være med Devops.

Terje Heen, seniorkonsulent i Webstep

Les om: