Af Peter Høygaard, Expert Director
Devoteam offentliggjorde i efteråret 2017 en markedsundersøgelse omkring danske virksomheders anvendelse af DevOps. Formålet med undersøgelsen var at få klarhed over, hvor udbredt anvendelsen af DevOps er, og om målet med DevOps – hurtigere Time to Market for ny software – er opnået. Markedsundersøgelsen er blevet fulgt op af en række besøg hos danske virksomheder, hvor resultaterne af undersøgelsen er blevet diskuteret, og vurderet.
Konklusionen af disse besøg er, at der stadig er et behov for at slå fast, hvad DevOps egentlig er, og hvornår DevOps er velegnet. Men hertil har en række virksomheder, der har haft succes med DevOps givet nyttigt input omkring, hvad de har gjort for at opnå de gode resultater.
I denne artikel sættes begrebet DevOps derfor på plads, og de nyttige erfaringer succesfulde virksomheder har gjort sig videregives.
Hvad er DevOps og hvorfor DevOps?
Kort fortalt er DevOps agil udvikling (Dev) suppleret med automatisk idriftsættelse af det udviklede software (Ops).
Agil udvikling illustreres i nedenstående figur (her med SCRUM som metode):
Figur 1 – Den agile udviklingsmetode SCRUM
Ideen er – groft sagt – at spise elefanten i småbidder. Men hver ”bid” skal ideelt set i sig selv have værdi!
Figuren viser repræsentant fra forretningssiden (Product Owner), som ønsker udviklet nyt software. Det samlede ønskede produkt opdeles i features, og der udvælges et sæt af disse, som skal udvikles. Det sker så i et såkaldt sprint af en varighed på 1-2 uger. Sprintet afsluttes med et delprodukt, som ideelt set er klar til ibrugtagning, og dermed kan stilles til rådighed for brugerne. I næste sprint tilføres yderligere features, som så stilles til rådighed for brugerne osv.
Traditionelt set idriftsættes software ved at det udviklede produkt overleveres til it-driftsafdelingen. It-driftsafdelingen arbejder typisk efter ITIL®:
Figur 2 – Idriftsættelse med ITIL-principper
Fokus er stabilitet i it-driftsmiljøet og deraf følgende grundighed i vurderingen af produktets modenhed i forhold til it-drift. Der skal forelægge installationsprocedurer, driftsinstrukser og teknisk dokumentation, dokumentation for tests og meget andet. Endvidere er der fra it-driftsafdelingen et ønske om at samle flest mulige idriftsættelser i pakker for derved at minimere behovet for servicevinduer, hvor systemer ikke er tilgængelige.
Alt dette er glimrende – men strider mod et behov for hurtige og hyppige idriftsættelser. Og ved agil udvikling har vi jo potentielt et idriftsættelsesbehov hver til hver anden uge – endda for hvert projekt, der måtte køre et agilt udviklingsforløb.
Her kommer DevOps ind i billedet:
Figur 3 – Idriftsættelse med DevOps
Ideen er, at idriftsættelsen (release, deploy i figuren) automatiseres, og dermed kan indlejres i de enkelte sprints. Det kræver automatiseringsværktøjer, der har en funktionalitet og kvalitet, der er tilstrækkelig til at skabe den samme sikkerhed for stabilitet i it-driftsmiljøet, som ITIL-processerne sikrer.
Sådanne værktøjer findes på markedet og anskaffelsen og ibrugtagningen af disse er en afgørende forudsætning for succes med DevOps.
Hvornår DevOps?
For virksomheder, der lever godt med standardsystemer (eksempelvis ERP-løsninger), der understøtter rimelig stabile forretningsprocesser, er der ingen grund til at overveje DevOps. Behov for tilpasninger af sådanne systemer kan nemt samles til bunke, og frigives til brug kvartalsvis uden at forretningen trues af den grund.
Men det er de færreste virksomheder, der i vore dage kan nøjes med det! Virksomhedernes kunder stiller krav om digitaliseringsløsninger – for eksempel indsigt i status på en afgivet ordre, løbende opdatering af forventet leveringstidspunkt osv. Og for hvert kundebehov der dækkes, opstår der lynhurtigt et nyt.
Tilsvarende vil også virksomhedens medarbejdere stille krav. De er vant til løbende og hyppige opdateringer på de services, de forbruger på deres mobile enheder, og forventer derfor samme agilitet omkring de forretningssystemer, de måtte benytte.
Svaret på denne udfordring er at tænke IT og digitalisering bi-modalt. Der er brug for et ”mode”, hvor eksempelvis ERP-løsninger behandles traditionelt, mens kunde- og medarbejderrettede ”apps” udvikles med DevOps:
Figur 4 – Mode 1 er det traditionelle, Mode 2 er DevOps
DevOps hvordan?
Afslutningsvis oplister vi det væsentligste af, hvad virksomheder, der succesfuldt anvender DevOps, har gjort.
IT-Driftskompetencer er afgørende at inddrage
Hvem ved mere om at sætte it-systemer i drift end de it-driftsfok, der har arbejdet med det i årevis? Derfor er det selvfølgelig helt afgørende at inddrage deres kompetencer i arbejdet. De vil bidrage med at udvælge de rigtige automatiseringsværktøjer, og stille disse til rådighed for de (agile) udviklingsprojekter. I flere organisationer har vi set, at der dannes et lille team af it-driftsmedarbejdere, som supporterer alle udviklingsprojekter med gode værktøjer. Endvidere overvåger de markedet, finder nye og bedre værktøjer, tester disse, og stiller dem til rådighed.
Automatisering skal tænkes bredere end idriftsættelse
Som det er fremgået af Figur 3 – Idriftsættelse med DevOps indgår test naturligvis i det samlede billede. Succesfulde virksomheder har tillige automatiseret testopgaverne. Herved har de opnået endnu større hastighed i softwareudviklingen, men også et kvalitetsløft! For testværktøjer fungerer kun, hvis den kode, der skal testes, er udviklet efter præcise forskrifter. Hvis disse ikke er overholdt, afvises testen simpelthen.
Almindelig projektledelse er stadig vigtigt
Selvom vi kører agilt, og automatisk får idriftsat, er de gode projektledelsesdiscipliner stadig aktuelle:
- Styring og rapportering: tid, kvalitet og økonomi
- Sikring af overholdelse af virksomhedens standarder:
- Arkitektur
- Teknologi
- Sikkerhed
- Brugergrænseflade
- Koordinering med øvrige projekter, herunder beslutninger om nødvendige integrationer
Governance skal være på plads
Ved brug af DevOps vil Product Owner og hans team have ”næsen i sporet” og gå målrettet efter at få udviklet netop deres produkt gennem en række sprints. Men hvert sprint tilfører jo principielt værdi, så hvad nu hvis eksempelvis de første seks sprints ud af otte tilfører 95 % af værdien? Er de to sidste så ulejligheden værd? Der skal være fora, der ser på tværs af projektporteføljen, og afgør sådanne spørgsmål.
ITIL® is a registered trade mark of AXELOS Limited
Vil du vide mere?
Så er du velkommen til at kontakte Peter.
Vi stiller gerne op til faglige indlæg og individuelle møder om emnet.
