Ja til devops, nej til automatisk deployment?
I Aety bruger vi en stor del af vores tid på at hjælpe organisationer med deres udviklings- og driftsprocesser.
Vi oplever en stor interesse for DevOps, og fortæller gerne om hvorfor det er smart at standardisere og automatisere. Til gengæld støder vi også ind i forbehold, når vi anbefaler at automatisere idriftsættelse af software. Det sker ofte fordi man som organisation typisk har fastsat nogle processer i forbindelse hermed, f.eks. ITIL. De processer indebærer typisk at alle ændringer til produktionssystemet behandles på et Change-Advisory Board (CAB) møde, hvis formål er at vurdere ændringens virkning på det samlede system – både fra et teknisk og forretningsmæssigt perspektiv.
Få alle med
Det er naturligt og nødvendigt at vide hvilken tilstand systemet er i, derfor giver CAB-møderne fin mening. Udfordringen er at de sænker kadencen for release af ny funktionalitet hvilket giver forretningsmæssige udfordringer.
Når vi så foreslår at en ny release af software skal foregå uden det manuelle trin er det klart at driftsorganisationen reagerer med afvisning. Men hvad skal man så gøre?
Først og fremmest er det vigtigt at anderkende behovet for at “der er styr på det”. Driften skal være kritisk overfor ændringer, ellers kan de ikke garantere stabilitet i de services de har ansvaret for.
Bliv enige om formålet
Men derefter er det vigtigt at blive enige om hvorfor processen eksisterer, nemlig for at sikre kvaliteten, dokumentere ændringerne og dermed minimere risikoen for at tingene går galt. Og hvis de går galt, kan man nemmere fejlsøge, fordi man kan fokusere på de enkelte changes der er foretaget på systemet.
“State of Devops” rapporten (https://puppet.com/blog/2020-state-of-devops-report-is-here/ ), som er en årlig publikation der tager temperaturen på organisationers modenhed i forhold til at levere software, havde sidste år fokus på Change Management. Her var resultatet at organisationer får effektiviseret deres changeprocesser ved at automatisere processen. Ligeledes resultarede rapporten i en afklaring af at vanetænkning – “den måde vi altid har gjort det på” – gør processerne ineffektive.
Hvad betyder det, og hvordan skal vi komme videre herfra?
Så det første budskab er at automatisering af deployments ikke er det samme som at vi rider rundt i Cowboy-land. Udviklingsprocessen skal sikre, at vi præcist ved hvilke ændringer, der er i en given release, og på den måde kunne dokumenterer ændringerne. Sporbarheden kan (og bør) være på kodeniveau, så vi kan sige nøjagtigt hvilke ændringer, der er foretaget i hvilke filer i en given release.
Dernæst er der selve kvaliteten. En automatiseret pipeline muliggør test på mange niveauer, lige fra unittest af den enkelte metode til verifikation af om koden til provisionering af infrastruktur indeholder mulige problemer. Og lad det være sagt: Det er en kæmpe udfordring at sikre gode automatiserede test på alle niveauer, så organisationen skal derfor enes om, hvad der er vigtigst og foretage hårde prioriteringer. Der skal aftales kvalitetsmål for hvad der skal være på plads, inden at en ændring kan føres op til næste miljø. Ligeledes skal ændringerne være små og mange, fremfor få og store.
Hvis man skal opsummere tankegangen, kan den lyde sådan her:
Automatisering er en driver for standardisering, og standardisering giver forudsigelighed.
Til sidst: Start med at blive enige om hvad målet skal være. Del målet op i flere delmål, og acceptér at det hele ikke falder på plads med det samme. Hold fokus på samarbejdet, og få derigennem tilliden til, at det kan lade sig gøre.
Og ring til os på 70 70 72 71, hvis I skal bruge hjælp.
