DevOps processer – et spadestik dybere

Hvilke metodikker og processer kan understøtte implementeringen af DevOps i organisationen?

Vi har tidligere overordnet gennemgået hvad DevOps, GitOps og DevSecOps er. Denne gang vil vi grave et spadestik dybere og beskrive forskellige DevOps processer og metodikker, der kan implementeres for at understøtte metoden i praksis og sikre et succesfuldt udviklings- og driftsprojekt.

Artiklen er skrevet af Bjarne Dollerup, som er development-konsulent i Globeteam. 

DevOps processer i praksis

Et væsentligt element i DevOps er, at der er strukturerede arbejdsgange og deling af information imellem interessenterne (typisk udviklere og drift) for at sikre:

• Ensartethed (det er samme proces, hver gang vi ruller noget nyt ud).
• Sporing (vi kan se, hvem der har udført en ændring og hvornår).
• Godkendelse (vi har en proces for godkendelse af enhver udrulning.

I praksis hviler ”Dev”-delen af DevOps på det grundprincip, at alle kodefiler er tekstfiler, og at alt skal beskrives i kode. Ideen er, at alle udviklere på et projekt opbevarer deres kodefiler samme sted, og vi kan holde styr på de ændringer, som de hver især foretager i filerne. Dermed kan vi let og hurtigt rulle tilbage til en tidligere version, hvis den nyeste viser sig at volde problemer.

”Ops”-delen af DevOps hviler på et lignende princip: Alle infrastruktur elementer til en applikation eller server skal ligeledes være beskrevet i tekst, så de kan rulles ud automatisk.

Når vi har både drifts- og udviklingsafdelingens elementer beskrevet og versioneret, kan vi – ved hjælp af services som fx Azure DevOps, GitHub eller Jenkins – skabe et komplet automatiseret udrulningsforløb (oftest kaldet en pipeline). Dette forløb vil kunne kopiere den korrekte version af koden fra projektet, kompilere den, teste den, og til slut rulle den færdig testede applikation ud på de servere, som driftsafdelingen har stillet til rådighed. Dette kaldes ”CI/CD” (Continuous Integration/Continous Delivery).

Hver gang vi bygger en ny version af applikationen, vil dette CI/CD forløb (pipeline) blive aktiveret. Det betyder, at hver eneste gang vi ændrer i koden, kan vi teste applikationen af på en kopi af den korrekte infrastruktur med de korrekte services etc. Det betyder også, at vi automatisk får givet feedback til udviklerne, hvis der er noget, der fejler undervejs i vores tests.

I den perfekte verden kan udvikleren trykke på ”rul ud”-knappen i sit udviklingsværktøj, gå ud og hente en kop kaffe, og når han/hun kommer tilbage til sin PC, ligger der en besked om, hvorvidt ændringen gik godt. Hvis den skulle have resulteret i fejl, medfølger en beskrivelse af fejlen(e).

Test, udrulning og monitorering

Med ovenstående kan vi nu også etablere forskellige versioner af et udrulningsforløb.

For eksempel kan vi have et forløb til ”kun” at teste applikationkodens integritet, hvor vi ikke ruller applikationen ud på et sæt af servere. Vi kan have et QA-forløb, hvor vi udover at teste kodens integritet også ruller den ud på et sæt af testservere og udfører belastnings- og andre driftstests. Og kronen på værket kan så være et forløb, der ruller applikationen ud i et produktionsmiljø.

Hele ”applikationskomplekset” bliver sikret imod eventuelle ændringer i den underliggende infrastruktur, da alt hele vejen igennem et udviklings- og driftsforløb refererer til specifikke versioner af alle komponenterne. Fx kunne applikationen være bygget til en specifik version af .NET, JAVA eller Javascript, en specifik version af web serveren på Windows Server med en specifik ORACLE database, en specifik browser version etc.

Hvis alle kommenterer deres ændringer og opsætninger i kodefilerne, bliver det også nemmere at se baggrunden for de ændringer, der er foretaget i både udvikling og drift. Faktisk vil jeg argumentere for, at et velkommenteret projekt (inklusiv udvikling, test og opsætning) udgør et solidt grundlag for dokumentation af hele forløbet.

Et sidste element, der er værd at nævne i relation til DevOps processer, er brugen af instrumentering, monitorering og logning. Hvis alle elementer i såvel kode som driftsmiljø monitoreres og logges, kan vi konstant følge med i applikationers og driftsmiljøers ”livskvalitet”. Det gør det nemmere at finde eventuelle problematikker og rapportere disse tilbage til udviklingsteamet. Mere om det i en anden artikel.

Konklusion

DevOps processer og metodikker giver os en lang række muligheder i forhold til at ensarte og styre, hvordan vi udvikler, tester og idriftsætter vores applikationer/services. Vi får også mulighed for at dele opgaverne op. Fx vil det typisk være driftsafdelingen, der definerer, hvordan afviklingsmiljøet ser ud, mens sikkerhedsafdelingen definerer penetrations og tjek for sårbarheder. Udviklere vil så definere, hvorledes de generelle tests skal se ud. Og alle disse tests vil kunne afvikles hver gang, der ændres i applikationens infrastruktur og/eller kode.

Det kunne lyde som om, at DevOps er en næsten magisk ingrediens, som man ”bare” kan sætte i drift, men virkeligheden er, at det at sikre et succesfuldt udviklings/driftsprojekt kan være komplekst.

Det fører mig til det sidste afsnit:

Hvordan kan Globeteam hjælpe med DevOps?

Globeteam har erfarne, certificerede konsulenter med speciale i DevOps, Agile og SCRUM og SAFe og vi tager gerne en uforpligtende snak om, hvordan din organisation bedst kan drage nytte af disse teknologier.
Læs mere om, hvordan vi kan hjælpe jer med DevOps her