DevOps er ikke kun et teknologisk skift; det er en ændring i tankegang og kultur, hvor samarbejde mellem udvikling og drift er i centrum. I denne ramme bliver testning ikke længere en isoleret aktivitet, der finder sted på bestemte tidspunkter i udviklingscyklussen, men en integreret og kontinuerlig proces. I en DevOps-kultur er testning et samarbejde, der involverer både udviklere, testere og driftsteam, der arbejder tæt sammen for at sikre høj kvalitet gennem hele udviklingslivscyklussen.

Teststrategien i en DevOps-verden kræver, at test ikke blot er en opgave for et dedikeret testteam, men et ansvar, der deles på tværs af organisationen. Det betyder, at man skal bryde de traditionelle siloer ned, hvor udviklere og testere arbejdede i adskilte faser, og i stedet se testning som en integreret del af alle faser af produktets livscyklus. Dette kræver et tæt samarbejde og en fælles forståelse af mål, værktøjer og processer.

Når man ser på testing i DevOps, er der flere elementer, der er essentielle for at opnå succes. Det første skridt er at definere en teststrategi, der ikke kun tager højde for de tekniske aspekter, men også for den kulturelle og organisatoriske kontekst, hvor testningen finder sted. Dette kan være gennem retrospektiver og evaluering af eksisterende teststrategier, hvor man sammen identificerer områder, der skal forbedres.

Automatisering er en nøglekomponent i testning i DevOps, og det skal integreres i pipeline-strukturen fra starten. Automatisk testning, herunder unit tests, integrationstests og end-to-end tests, gør det muligt at udføre tests hyppigere og hurtigere, hvilket er afgørende for at opretholde den høje hastighed, som DevOps kræver. Automatisering skal dog ikke betragtes som en erstatning for manuelle tests, især når det kommer til funktionel testning og brugeroplevelse. Her er det vigtigt at finde den rette balance mellem automatisering og manuelle tests.

Udforskning er også en central del af teststrategien i DevOps. Udforskende testning giver mulighed for at opdage problemer og uforudsete fejlsituationer, som automatiserede tests måske ikke fanger. Denne type testning kræver dygtighed og erfaring og bør opfordres i agile miljøer, hvor nye funktioner og ændringer implementeres hurtigt og kontinuerligt.

Der er også et stærkt fokus på feedback. I en DevOps-kultur er feedback ikke noget, der kun gives efter afslutningen af en testcyklus, men en konstant proces, hvor udviklere og testere løbende kommunikerer og justerer deres tilgang. Dette kan ske gennem daglige stand-up møder, kontinuerlige integrationstests og feedback-loop, der sker i realtid, når kode ændres.

En anden væsentlig overvejelse i DevOps-kulturen er testning i produktion. Testning bør ikke stoppes, når produktet går live. Snarere bør det fortsætte i produktionen, hvor feedback fra faktiske brugere kan anvendes til at forbedre systemet. Overvågning og alarmering spiller en vigtig rolle i at opdage problemer i realtid, og det giver mulighed for hurtig respons og løbende forbedringer. A/B-testning og beta-testning er praktiske metoder til at eksperimentere med nye funktioner i en kontrolleret produktion, før de bliver rullet ud til alle brugere.

En vigtig forståelse er nødvendigheden af at se på hele systemet og infrastrukturen som en del af testningen. I stedet for at kun fokusere på applikationslaget skal man også tage højde for infrastrukturen. Test af infrastrukturen, herunder automatiserede test af servere, netværk og cloud-ressourcer, er uundværlige. Destruktiv testning, som f.eks. chaos engineering, kan bruges til at afprøve systemets modstandsdygtighed over for fejl, hvilket er essentielt i en DevOps-kultur, hvor systemet konstant er i forandring.

Endelig er det vigtigt at forstå, at testning i DevOps ikke kun handler om at finde fejl, men også om at sikre, at systemet fungerer som forventet i et dynamisk og hurtigt udviklende miljø. Det er en balancegang mellem at sikre hurtig levering og opretholde høj kvalitet. Uden en effektiv teststrategi vil man hurtigt blive overvældet af det konstante flow af kodeændringer, og kvaliteten vil lide under det.

For at kunne implementere disse praksisser effektivt i DevOps er det afgørende at have de rette værktøjer og infrastruktur på plads. Værktøjer til automatisering af test, CI/CD-pipelines, overvågningssystemer og feedback-mekanismer er nødvendige for at kunne opretholde den hastighed og kvalitet, som DevOps stræber efter.

Det er også nødvendigt, at alle parter i organisationen forstår, at testning ikke er en aktivitet, der finder sted på et bestemt tidspunkt i livscyklussen, men noget, der sker kontinuerligt og i alle faser af udviklingen, lige fra planlægning til produktion og videre. Denne forståelse er nøglen til succes i en DevOps-kultur, hvor testning er en integreret del af arbejdet med at opbygge og vedligeholde applikationer.

Hvad er en Canary Release, og hvordan anvendes det i softwareudvikling?

En "Canary Release" stammer fra historien om kanariefugle, der tidligere blev brugt i miner for at advare om tilstedeværelsen af giftige gasser. På grund af deres mindre størrelse og følsomhed var kanariefuglene mere modtagelige for gas, hvilket gjorde dem til en effektiv advarsel for minearbejdere. Hvis kanariefuglen døde, var det et signal til minearbejderne om at evakuere. På samme måde bruges en canary release i softwareudvikling som en teknik til at opdage problemer tidligt i udviklingsprocessen ved at rulle den nye version ud til en lille gruppe brugere, før den gøres tilgængelig for alle.

En canary release er en metode, der langsomt introducerer ændringer i et softwaremiljø ved kun at rulle den ud til en lille delmængde af brugerne, hvilket reducerer risikoen for større problemer i produktionen. Ideen er at opdage fejl og problemer, før de får omfattende konsekvenser. Denne metode kan implementeres ved at begrænse infrastrukturen, der kører den nye kode, så ændringerne først implementeres på et mindre antal servere. For eksempel benytter Facebook denne tilgang ved at indføre nye opdateringer på et lille antal servere, som kun bliver synlige for en lille del af deres brugere. Dette giver udviklerne mulighed for at observere, hvordan opdateringen klarer sig under reelle produktionsforhold, uden at påvirke den overordnede brugerbase.

Fordelen ved en canary release er, at ændringerne hurtigt kan afprøves, og problemer kan opdages tidligt. For eksempel, hvis den nye kode forårsager fejl eller nedbrud på en server, kan kun de berørte brugere mærke problemet, og den nye kode kan rulles tilbage uden at påvirke alle brugere. Facebooks metoder til release engineering tillader netop denne form for kontrolleret og systematisk eksponering af nye opdateringer.

En anden metode, der kan anvendes, er staged rollout. Her er fokuset at rulle ud til en begrænset delmængde af brugere, men i modsætning til canary releases, er målet ikke nødvendigvis at begrænse infrastrukturen, men snarere at begrænse den specifikke brugergruppe, der får adgang til den nye version. Et eksempel på dette kan ses hos Google, der benytter staged rollouts til at udrulle opdateringer af Android-applikationer gradvist til deres brugere. Hvis den nye version fungerer godt, kan procentdelen af brugere, der modtager opdateringen, gradvist øges.

Dog er staged rollouts ikke uden deres egne udfordringer. Hvis en stor del af brugerne vælger at springe opdateringen over, kan eksperimenterne, der blev designet til at indsamle data om ændringerne, blive forvrænget. Dette kan føre til en mindre repræsentativ testgruppe og dermed et misvisende resultat. Desuden giver staged rollouts ikke den samme kontrol over eksperimentelle A/B-tests, som en canary release kan tilbyde, hvor to versioner af softwaren kan testes mod hinanden på en kontrolleret måde.

En anden tilgang, der anvendes til at teste nye softwareversioner, er dogfooding. Dette refererer til praksisen, hvor softwareudviklerne selv bruger deres egen software, ofte i betaform, for at finde og rette fejl. Denne metode var for første gang dokumenteret i 1988, da Microsoft opfordrede sine egne ansatte til at "spise deres egen hundemad", hvilket betød at bruge deres egen software for at opdage eventuelle problemer. Dogfooding kan være en effektiv metode til at finde problemer hurtigt, men den har sine begrænsninger, da medarbejdere måske ikke altid er repræsentative for den gennemsnitlige bruger. Dette kan føre til, at udviklerne overser fejl, som vil være mere synlige for en bredere brugerbase.

For at implementere en canary release effektivt er der flere faktorer, der skal overvejes. Datahåndtering kan være en af de største udfordringer, da det kræver, at softwareteamet skriver kode, der er kompatibel med både den nye og den gamle version af systemet. Dette betyder, at dataopdateringer og migrering af databaser skal udføres i flere trin for at sikre, at systemet forbliver stabilt og funktionelt. For eksempel kan ændringer som at flytte data fra en MySQL-tabel til en anden kræve flere opdateringer og testtrin for at sikre, at dataene ikke går tabt, og at systemet fortsat fungerer korrekt.

Samtidig er det vigtigt at huske, at selvom en canary release reducerer risikoen for fejl, skaber det samtidig en ekstra administrativ byrde. Softwareudviklere og operations teams skal kunne overvåge to forskellige versioner af softwaren, hvilket kan være en kompleks opgave, især når der er behov for at holde styr på, hvilken version af softwaren der kører på hvilke servere, og hvilke brugere der er påvirket.

Selvom en canary release minimerer risikoen ved at introducere nye versioner af software, er det ikke en metode, der er uden omkostninger. Udviklingsteams og operationsafdelinger skal finde den rette balance mellem at teste nye funktioner hurtigt og effektivt, samtidig med at de sikrer, at systemet forbliver stabilt og pålideligt for alle brugere. Det er også nødvendigt at overveje, hvordan man håndterer brugernes feedback fra en canary release og hvordan man bruger disse data til at forbedre den endelige version af softwaren.

Hvordan Etsy og Spotify håndterer softwareudrulning og overvågning i stor skala

Når man arbejder med softwareudvikling på stor skala, er det essentielt at have en robust og effektiv løsning til overvågning, test og deployment. Etsy og Spotify, to af de mest succesfulde tech-virksomheder, har begge udviklet innovative metoder til at håndtere disse udfordringer, og deres erfaringer kan give værdifuld indsigt for både små og store udviklingsteams.

Etsy, en af de mest kendte online markedspladser, er et fremragende eksempel på, hvordan man kan anvende overvågningsløsninger til at opretholde stabiliteten af et komplekst system. Etsy udfører dagligt mere end 25 udrulninger af kode, hvilket kan føre til en betydelig kompleksitet i at forstå årsagen til eventuelle fejl eller nedbrud. Mike Brittain, tidligere Lead Software Engineer hos Etsy, beskriver, hvordan man i begyndelsen kan få et signal om et problem – for eksempel en stigning i PHP-fejl – men uden at kunne identificere den præcise årsag med det samme. Etsy bruger derfor en metode, hvor de monitorerer hver enkelt ændring og kobler den direkte til eventuelle systemændringer. Dette gør det muligt at finde ud af, om et problem stammer fra menneskelige fejl i applikationskoden eller fra eksterne faktorer som hardwarefejl eller problemer med tredjeparts-API'er.

Ved at anvende et såkaldt "deployment overlay" på deres overvågningsgrafik, markerer Etsy specifikt, hvornår der er sket en ny udrulning, hvilket gør det lettere at spotte eventuelle problemer. Noah Sussman, Test Architect hos Etsy, forklarer, hvordan de bruger denne overvågning til at finde og løse problemer hurtigt. "Hvis der er et pludseligt spike eller dyk i en måling efter en udrulning, ved vi, at vi har et problem," siger han. Denne tilgang til kontinuerlig udrulning og overvågning gør det muligt for Etsy at finde og rette fejl på få timer, hvilket er en vigtig del af deres risikoafhjælpnings- og modstandsdygtighedsstrategi.

Spotify, der oprindeligt blev startet som en svensk opstart, har også udviklet en sofistikeret tilgang til softwareudrulning og drift af deres platform. Med over 100 millioner aktive brugere og en kompleks, distribueret infrastruktur har Spotify været tidlig til at adoptere containerteknologi, som f.eks. Docker, til at håndtere deres mange tjenester. Rohan Singh, en infrastrukturingeniør hos Spotify, forklarer, hvordan Docker har givet dem mulighed for at skabe en standardiseret og gentagelig infrastruktur, hvor den samme container kan bruges i udvikling, test og produktion. Dette har ikke kun forbedret ressourceudnyttelsen, men også givet Spotify mulighed for hurtigt at komme sig efter fejl, da de kan starte forfra med en ny container, hvis en deployment fejler.

Men Spotify stødte på problemer med at håndtere de mange forskellige tjenester, de havde i drift, og de opfandt derfor et værktøj kaldet Helios. Dette er en orchestration framework, der gør det muligt at deployere og holde styr på tjenester på flere servere på én gang, uden at det bliver for kompliceret. Ifølge Evgeny Goldin, en anden Spotify-ingeniør, er Helios "ikke prøvet på at være for sofistikeret", men løser et meget konkret problem effektivt.

Disse eksempler på Etsy og Spotify illustrerer vigtigheden af at have en velkoordineret tilgang til softwareudrulning og overvågning i komplekse systemer. En vigtig komponent i både Etsy og Spotifys strategier er automatisering, som ikke kun hjælper med at øge effektiviteten, men også sikrer, at potentielle problemer kan opdages og løses hurtigt.

For et udviklingsteam kan det være fristende at fokusere på én løsning, som man tror løser alle problemer. Dog viser erfaringerne fra Etsy og Spotify, at en kombination af flere løsninger – som overvågning, automatiserede tests og containerteknologi – er nøglen til succes. Det er nødvendigt at udvikle en kultur, hvor fejl ikke kun ses som noget negativt, men som en mulighed for hurtigt at forbedre systemet og håndtere risici proaktivt. Hertil kommer den vigtige forståelse af, at hurtigt deployment kan være en fordel, så længe man er i stand til at monitorere og rette eventuelle fejl hurtigt.

Desuden er det essentielt at have de rette værktøjer til at håndtere store mængder data og målinger. Det er nemt at blive overvældet af de mange data, som moderne systemer producerer, og derfor er det vigtigt at kunne filtrere og fokusere på de målinger, der virkelig betyder noget. Den menneskelige faktor spiller stadig en afgørende rolle i beslutningsprocessen, især når det drejer sig om at identificere, hvilke målinger der er de vigtigste, og hvordan man bedst kan reagere på anomalier.

Hvordan opbygger man en teststrategi i et tværfagligt team?

I et tværfagligt team kunne man fristes til at tro, at det er specialist-testeren, der alene definerer teststrategien, givet at testing er deres primære kompetence. Dog er det måden, hvorpå strategien besluttes og deles, der er vigtig. En tester, som ikke tydeligt forklarer processen bag deres strategiske beslutninger, påtager sig en stor risiko ved at tage ejerskab over valg, der muligvis ikke bør være deres at træffe. Under testningen vil specialist-testeren træffe bevidste valg, der ændrer teamets teststrategi. De vil aktivt overveje afvejningen af at vælge en praksis frem for en anden, indvirkningen på testdækning og konsekvenserne for produktets samlede kvalitet. Men ofte træffer de disse beslutninger alene uden at dele ændringerne med teamet. Det er muligt, at andre også træffer beslutninger, der påvirker teststrategien, men mindre bevidst. I et agil team kan testing blive betragtet som åben for alle, men den strategiske overvejelse omkring testning er ikke altid det. Det betyder, at de, der tester, måske adopterer en praksis uden helt at forstå hvorfor.

En retrospektiv for teststrategien hjælper teamet med at forstå, hvilken teststrategi der anvendes, og hvilke beslutninger der ligger til grund for den. Denne retrospektiv bør være både engagerende og interaktiv for at få ikke-testere til at tænke over, hvilke testaktiviteter der udføres, og hvorfor. Den bør vare cirka en time. Specialist-testeren bør facilitere retrospektivet, men ikke deltage i visualiseringen af strategien. Dette forhindrer teamet i at blive ledet af facilitatorens mening og sikrer, at alle får mulighed for at bidrage.

For at gennemføre en retrospektiv for teststrategien skal du bruge: én time, hvor hele teamet er tilgængeligt, post-its i fire forskellige farver og en stor flade at placere post-its på. Et stort mødebord er ideelt, da det giver teamet mulighed for at samle sig om alle fire sider. En stor, tom væg er et godt alternativ.

Start retrospektivet med klart at angive formålet til deltagerne. Forklar, at I skal visualisere teststrategien og skabe en fælles forståelse af, hvilke testaktiviteter der finder sted. Placer to post-its – én mærket "IDEA" og den anden mærket "PRODUCTION" – i øverste venstre og højre hjørne af fladen for at skabe en tidslinje, der afspejler softwareudviklingsprocessen fra idé til implementering af applikationen.

Farven på post-its betyder følgende:

  • Lilla: Aktiviteten er en del af teststrategien, og vi udfører den.

  • Pink: Aktiviteten er en del af teststrategien, men vi udfører den ikke.

  • Gul: Aktiviteten er ikke en del af teststrategien, men bør være.

Hver deltager placerer deres post-its på tidslinjen, hvor de mener, at testaktiviteten finder sted. Efter fem minutters arbejde vil der være en uordnet samling af post-its. Bed teamet om at samarbejde om at gruppere de post-its, der omhandler samme testaktivitet, og blive enige om placeringen af aktiviteterne på tidslinjen. Hvis forskellige termer er blevet brugt til at beskrive den samme aktivitet, bør de holdes adskilt. Når teamet er tilfredse med visualiseringen, eller når samtalen begynder at gå i ring, stopper du.

En diskussion om teststrategien kan derefter åbnes med spørgsmål som:

  • Er der grupper med post-its i forskellige farver? Hvorfor?

  • Har folk brugt forskellige termer til at beskrive den samme testaktivitet? Hvorfor?

  • Er der aktiviteter i teststrategien, som ikke bliver udført? Hvorfor?

  • Er der aktiviteter, som mangler i strategien? Skal vi inkludere dem?

  • Er der aktiviteter, som slet ikke er nævnt i visualiseringen? Hvilke er de?

Disse spørgsmål afslører misforståelser omkring den nuværende teststatus og belyser de beslutninger, der har formet den nuværende strategi. Visualiseringen er et produkt af hele teamet, og de vil være mere investerede i det. I et tidligere tilfælde, hvor jeg gennemførte dette med et team, viste det sig, at end-to-end testning blev betragtet forskelligt: nogle mente, at det var en del af teststrategien og blev udført, andre mente, at det var en del af strategien, men ikke blev udført, og nogle mente, at det slet ikke var en del af strategien. Teamet arbejdede i en kompleks arkitektur, som involverede flere interne og tredjepartssystemer. De forskellige farver af post-its afslørede uenigheder om, hvad end-to-end betød for deres miljø.

En alternativ tilgang blev udviklet af Sean Cresswell, der ændrede måden at visualisere teststrategien på. I stedet for at sammenligne den nuværende test med den oprindeligt definerede strategi, bad Sean hvert medlem om at skrive en række post-its, hvor hver post-it beskrev en testaktivitet. Farven på post-its viste, hvem der udførte aktiviteten: tester, udvikler eller andre roller. Resultaterne blev derefter placeret på en matrix, der viste, hvor ofte aktiviteten blev udført i forhold til, hvor ofte den burde blive udført. Denne tilgang skaber en lidt anderledes diskussion, da fokus er på at sammenligne den nuværende test med den ideelle test, frem for den oprindeligt planlagte strategi. Det kan dog være svært at spotte huller i strategien, da der ikke er samme fokus på rækkefølgen af aktiviteter.

For et tværfagligt team, hvor alle kan udføre testning, er det essentielt at have en fælles forståelse af både den praktiske tilgang til testopgaverne og den underliggende teststrategi. Enighed om testaktiviteterne betyder, at enhver, der påtager sig en testopgave, forstår den bredere kontekst, de arbejder indenfor. Det hjælper dem med at forstå opgavens grænser: hvad de skal teste, og hvad der hører til en anden aktivitet.

Jak MathComp-Analysis využívá klasické axiomy a teorie množin
Jak najít správného učitele a třídu pro váš zdravý životní styl
Jak dětská zvědavost vede k nečekaným následkům