Skrevet af: CTO Martin Søndergaard
DevOps: Hvis du har erfaring med kodning og var med på IT-udviklingsholdet for bare 5-10 år siden, vil du vide, at der blev taget nogle heldige slag.
Er kodning og softwareprogrammering ikke din metier, vil jeg gerne fortælle dig en lille hemmelighed: For ganske få år siden var det mere held end forstand, at det software, som blev skubbet ud til brugerne, ikke var propfyldt med fejl. Det er måske en lidt for stor underdrivelse, for guderne skal vide, at meget af det software, som brugerne måtte slås med, faktisk var fyldt med programmeringsfejl og ofte manglede af håndtere en række forskellige brugerscenarier.
Tænk over det; der skal ikke mere til end et forkert komma eller et enkelt forsvundet kolon, før det, der skulle have været en simpel rettelse i koden, bliver til et større systemnedbrud, som kan tage mange timer at genoprette. Vi taler i bogstaveligste forstand om at skulle finde en nål i en høstak, når man bliver nødt til at gennemsøge 35 siders kode for én enkelt tastefejl.
Hvorfor det ikke gik værre, end det gjorde, og hvorfor brugerne simpelthen ikke bare boykottede IT-systemerne, det står hen i det uvisse, men lad mig bare sige, at jeg i hvert fald er glad for, at vi er kommet videre.
Kodning i gamle dage
Lad mig lige prøve at ridse programmeringsprocessen op, som den så ud i gamle dage, altså, for cirka 10 år siden.
Dengang kørte vi ikke efter de efterhånden velkendte Scrum-metoder, men efter den såkaldte “vandfaldsmodel”. Det er en model, som grundlæggende betyder, at ét stadie skal være afsluttet, før det næste kan begynde.
Et klassisk projekt havde således 4 stadier:
- Idé/ønske bliver formuleret og måske illustreret
- Programmeringen går i gang og afsluttes
- Test af det nye software
- Feedback, som grundlæggende set starter processen forfra
Problemet med den gamle metode er ganske enkelt, at der går enormt lang tid fra idé til endeligt produkt, og der kan opstå så mange ting i programmeringen, som kan gå galt, eller som bare ikke giver mening, når først brugerne ser på det.
Derfor er man også for længst gået væk fra vandfaldsmodellen i langt de fleste udviklingsteams rundt omkring i verden.
Kodning i dag
I dag er det Scrum, der har førertrøjen på, når vi taler om programmørernes arbejdsprocesser.
Men faktisk er heller ikke Scrum godt nok, hvis du vil holde en hurtig og agil tilgang til udviklingen, og hvis du vil i marken med brugbart software hurtigere end dine konkurrenter.
I dag er der brug for, at både brugerne og de supportere, der skal implementere systemerne, er involveret allerede fra starten.
Det kan nemlig ikke nytte noget, at udviklerne har siddet og arbejdet på en smart feature i et stykke software, men når den nye kode så skal leveres, så kaster man koden hen over “hækken”, ind til ”operations”-teamet, som for resten selv må finde ud af, hvordan hulen det hele hænger sammen.
Nej, i dag er der brug for en mere holistisk tilgang til softwareudvikling, hvis man vil lancere software produkter og -opdateringer, som har høj brugervenlighed og høj kodningskvalitet allerede fra begyndelsen.
DevOps: Svaret på, hvordan du leverer høj kvalitet igen og igen og igen
Det lyder som navnet på en Star Wars-karakter, men faktisk er netop DevOps svaret på, hvordan man som udviklingshus gang på gang kan levere software af høj kvalitet, som er let for brugerne at benytte, og som lanceres og implementeres helt uden problemer.
DevOps er nemlig en betegnelse for en arbejdsproces, hvor lanceringen af for eksempel en softwareopdatering tænkes ind helt fra begyndelsen af udviklingsarbejdet.
I modsætning til tidligere er DevOps idéen baseret på, at hvert et lille stykke kode, der skrives, skal kunne implementeres direkte i et Live-system, og altså virke med det samme.
Det betyder, at den tid – ofte flere måneder – man før måtte vente på, at programmørerne blev færdige med hele koden, er reduceret til, at programmørerne hver dag ved fyraften vil kunne udgive det stykke kode, de har skrevet i dag, og så vil den funktionalitet sådan set være tilgængelig for brugerne.
Selvfølgelig fungerer det ikke helt sådan, men i princippet kunne man gøre det.
Kvalitet på trods af høj fart?
Grunden til, at programmeringsprocessen er blevet så meget hurtigere, er, at man i dag bruger nogle programmer, som kan læse den ufærdige kode, og så bygge systemet så langt op, som det nu engang er kommet.
Lad mig prøve at illustrere med et eksempel.
Forestil dig, at du er tegneren bag Lego-manualerne. Med DevOps-systemet vil du kunne trykke på en knap, så et system bygger din model op, så langt som du er nået. Hvis det er en Lego-bil, du arbejder på, vil du altså kunne teste, om dørene kan åbne, selvom du ikke har tegnet – eller skrevet koden – til, hvordan hjulene fungerer.
Med DevOps-programmering er det meget det samme. Du kan altså hver dag bygge dit software op, så der kommer en live-version af den kode, som du har nået at skrive.
Automatiske tests giver konsistens i kodningskvaliteten
Det smarte ved denne form for softwareprogrammering skal ikke udelukkende findes i, at man kan få en visuel fremstilling af det, man laver.
Nej, det smarte er også, at du ved at bygge systemet ”on the fly” også kan opsætte automatiske tests, som forebygger, at der ikke er programmeringsfejl i det stykke kode, som du har arbejdet med.
Du kan altså opsætte en række mekanismer, som tjekker, om det, man forventer sker, også rent faktisk sker. Altså, sådan lidt forenklet; når jeg trykker på denne her knap, dukker det rigtige skærmbillede så op?
Hvis ja, så består koden testen, og hvis nej, så får programmøren med det samme en melding om, at der er en fejl i koden på præcis det sted, hvor fejlen opstår.
Denne type automatiserede test-flows er en væsentlig del af hele DevOps-tankegangen, for det er i disse tests, vi finder ud af, om den softwareopdatering, vi laver, rent faktisk også kan implementeres i systemerne, uden at der opstår problemer.
Og for lige at binde en smuk sløjfe tilbage til indledningen, er det jo også derfor, at vi i dag kan levere software af langt højere kvalitet og med langt færre fejl, end vi kunne for bare ganske få år siden.
Brugernes øjne sikrer brugbare løsninger
Det hører naturligvis med til historien, at gennemprøvningen af vores software ikke slutter ved en række automatiske tests og simulationer. Inden nye opdateringer går live, ryger det selvfølgelig forbi en testgruppe af faktiske brugere, som giver feedback på, hvordan systemet fungerer, og om det virker efter hensigten.
Selvom opdateringerne nødvendigvis skal forbi en menneskelig brugertest, er hastigheden og kvaliteten alligevel langt højere, ganske enkelt fordi brugerne kan fokusere på at teste brugervenlighed, og om det er de rette funktioner, fremfor at fokusere på, om selve programmeringen virker.
I sidste ende betyder det altså, at vi gang på gang er i stand til at levere færdigudviklede softwareløsninger og -opdateringer, som ikke bare virker, men som også løser brugernes behov på den mest optimale måde.
