Feedback fra udforskning kommer fra mennesker. Hvilken type information kan disse mennesker give, og hvordan kan vi indsamle den? Testning, der finder sted under udviklingen, er bedst brugt til udforskning: at lede efter de ukendte elementer i systemet, vedtage forskellige personaer for at tilbyde varieret subjektiv feedback, forsøge at underminere sikkerhedsforanstaltninger gennem ondsindet aktivitet eller udforske applikationens præstationsgrænser. Fokus bør være på områder, hvor menneskets hjerne er nødvendig for at tænke: generere ideer, bearbejde resultater og danne meninger. Resultaterne af udforskning under udvikling bliver mest sandsynligt indsamlet gennem samtale. I et miljø, hvor udviklingsteamet samarbejder tæt, kan problemer og spørgsmål rejses direkte. En interessant opdagelse kan føre til en interessant diskussion.

Ændringer i testpraksis under udvikling er ikke nødvendigvis ændret af at implementere en DevOps tilgang, men DevOps udvider omfanget af både automatisering og udforskning, samtidig med at feedbackcyklussen bliver hurtigere. Et tættere forhold til operations-teamet vil integrere deres færdigheder og bekymringer i deployeringspipen. Det sidste skridt i pipen kan rykkes tættere på produktionen, eller "skifte til højre", og inkludere udførelse af automatiserede tests i produktionsmiljøet. I stedet for at implementere kode i dedikerede testmiljøer kan pipen ændres til at opbygge nye miljøer på efterspørgsel. For at understøtte praksisser som test i produktion – A/B testning, beta-testning og overvågning som testning – vil udviklingsteamet ændre deres tilgang. De kan begynde at bruge funktionstoggles som et eksempel på disse ændringer. Disse ændringer i tilgangen vil påvirke både udviklings- og operations-teamets testarbejde. Antallet af personer, der udfører testning, kan vokse fra udviklingsteamet til en bredere målgruppe. Dette kan ske gennem en bug bash eller en intern beta-release. Tidlig feedback kan også indhentes fra personer udenfor organisationen, der er potentielle eller eksisterende brugere af produktet, og crowdsourcing-testning kan nå et bredt publikum for generel feedback. En brugeroplevelsessession kan indsamle dybdegående feedback fra en individuel repræsentant for en bestemt brugergruppe.

Udviklingspipen kan inkludere automatiseret feedback, der tager koden fra commit til produktion. Pipen indeholder alt automatiseret tjek, sammen med bygge- og deploymentscripts, der flytter koden gennem forskellige miljøer. På et abstrakt niveau er en deploymentspipeline en automatiseret manifestation af din proces for at få software fra versionskontrol til slutbrugeren. Et pipelineværktøj giver både udviklings- og operations-teams mulighed for at tjekke opførsel, mens de samarbejder om at skabe et fælles forståelsesgrundlag for det system, der er under udvikling. Dette giver et bedre overblik, hvor hver afdeling kan se, hvad den anden gør, og derved fremmer en mere effektiv arbejdsgang.

Traditionelt begynder pipen, når et medlem af udviklingsteamet begår en ændring af applikationskildekoden, og slutter, når koden deployeres til produktion. Mellem disse to punkter kan pipen indeholde: statisk analyse af kodekvalitet, opbygning af kildekode til et deployerbart produkt, enhedstests, integrationstests, end-to-end testautomation, funktionelle og ikke-funktionelle test, samt deploymentscripts for forskellige miljøer. Denne tilgang er allerede velkendt og en integreret del af agile testmetoder. Der er en tydelig tendens mod fuldt automatiserede deployments, hvor processen fra commit til produktion bliver fuldstændig automatiseret. Denne metode kan føre til, at udforskning flyttes til begge ender af pipen. Udviklingsteamet kan engagere sig i anvendelsen af systemet, for eksempel ved at holde en bug bash eller engagere en større gruppe via crowdsourcing. Når softwaren er i produktion, kan organisationen adoptere A/B testning eller beta-testning.

I nogle DevOps-miljøer tilføjes en ekstra udforskningsfase til pipen. Pipen kan køre statisk analyse og enhedstests på koden, oprette en build, der deployeres til et testmiljø, køre funktionelle tests og derefter stoppe. På dette tidspunkt har udviklingsteamet mulighed for at udforske produktet i testmiljøet. Denne tilgang muliggør en meget mere integreret testpraksis, der omfatter både udviklings- og operations-kontakter.

I en DevOps-orienteret organisation kan pipen udvikle sig i to centrale retninger: infrastruktur som kode og testautomation i produktion. I stedet for deploymentscripts, der installerer kode på dedikerede testmiljøer, kan pipen nu inkludere on-demand opbygning af infrastruktur. Efterhånden som operations-teamet får mere erfaring med udviklingspraksis som programmering og kildekodestyring, kan de begynde at skrive infrastruktur som kode. Dette fjerner afhængigheder fra specifikke miljøer og hjælper udviklingsteamet med at skalere pipen for hurtigere og parallelle tests.

En anden udvikling er, at slutningen af pipen kan skubbes, så den sidste fase handler om at køre automatiserede tests i produktionsmiljøet. Udviklingsteamet kan nu overvåge opførsel og præstation af applikationen efter hver ændring. Det giver også operations-teamet hurtig feedback på implementeringen af overvågning, alarmer, analyser og logning.

At teste selve pipen bliver mere og mere vigtigt, især når den indeholder skridt, der påvirker produktionen. Udviklingsteamet skal nøje overveje, hvad der udføres i produktion, og hvor ofte. De skal forstå, hvordan pipen kan fejle og hvordan de kan afbøde sådanne problemer. Hvis pipen inkluderer rollback-scripts, er det vigtigt at teste, at de fungerer korrekt, inden de er nødvendige. Denne overvejelse bliver endnu vigtigere, når pipen arbejder tættere sammen med produktion.

Endelig kræver denne ændring i testpraksisser en forståelse for, hvordan både udviklings- og operations-teams skal arbejde tættere sammen, især i konteksten af produktion, og hvordan feedback fra virkelige brugere kan ændre tilgangen til både design og implementering. Forståelsen af, hvordan nye teknologier og praksisser kan opstå og blive en del af testarbejdet, bliver en integreret del af DevOps-kulturen og hjælper med at sikre en hurtigere, mere robust og brugervenlig softwareudvikling.

Hvordan feedback og logfiler kan forbedre softwareudvikling i produktion

En god logføring kan være en uvurderlig ressource til at forstå og fejlsøge software i produktion. Det er dog vigtigt at have passende logbeskeder, da utilstrækkelig logning eller alt for omfattende logning kan gøre det vanskeligt at finde og isolere problemer. Hvis du kan identificere en fejl ved at analysere logfilerne, bør du også sikre, at dit supportteam kan drage samme konklusion ud fra de samme logs. Det kan være, at der kun findes begrænset analyse af produktionslogfiler, typisk efter hændelser, men disse logfiler kan afsløre interessant brugeradfærd og skjulte problemer i applikationen.

Et konkret eksempel på dette blev set i en produktionslog, hvor der var en række ensartede fejlsituationer. Det viste sig, at brugere havde vænnet sig til at klikke på en knap to gange, fordi en fejl i applikationen forhindrede det første klik i at virke. Den første klikhandling genererede en undtagelse, der kun var synlig i loggen. I sådanne tilfælde bør logfilerne bruges som et værktøj til at opdage adfærd og problemer, som udviklingsteamet måske ikke umiddelbart har overvejet. Matthew Skelton fremhæver, at logning bør ses som en kanal, der gør distribuerede systemer mere testbare. Han anbefaler at koncentrere testene af logfiler omkring tre hovedpunkter:

  1. Forventede hændelser skal vises korrekt i logstrømmen.

  2. Transaktionsidentifikatorer (eller korrelations-ID’er) skal flyde korrekt igennem logstrømmen.

  3. Hændelser skal logges på det rette niveau (Info, Error, Debug osv.) hvis konfigurerbare logniveauer anvendes.

I komplekse systemer, hvor en enkelt brugerhandling behandles af flere systemer, er det især nødvendigt at have en metode til at sammenkoble logfilerne fra de forskellige systemer. Uden en sammenhængende visning af hændelserne kan det være svært at opdage anomalier, som ellers kunne indikere potentielle problemer.

Desuden bør loghåndtering ikke undervurderes. Politik for logrotation og opbevaring bør implementeres. Meget store logfiler bliver besværlige at søge i og kan være tunge at overføre. For at undgå overdreven diskforbrug og sikre, at logfiler ikke ophober sig uden kontrol, bør logfiler arkiveres, når de når en vis størrelse, og slettes, når de bliver for gamle. Det er også vigtigt at sikre, at arkiverede logs kan gendannes korrekt. Afhængigt af hvordan loghåndtering er implementeret i organisationen, kan det være nødvendigt at teste selve loghåndteringssystemet.

Brugerfeedback er en anden vigtig kilde til information. I et softwareprodukt er der flere måder at indsamle feedback på – det kan være gennem en "Kontakt os"-knap på hjemmesiden, en indlejret feedbackformular eller en live chat med supportteamet. Alle disse kanaler giver værdifuld feedback fra brugerne. Hver dag opdager brugerne nye udfordringer og oplevelser, som udviklingsteamet måske aldrig har overvejet. Feedbacken kan omfatte alt fra frustration og forvirring til ros, tilfredshed eller forslag til forbedringer.

Kvantitative data som analyser fortæller os, hvad folk gør, og hvilken indflydelse deres handlinger har på systemet, mens de kvalitative data fra brugerfeedback giver indsigt i, hvordan brugerne føler, hvorfor de vælger bestemte veje gennem produktet, og deres reaktioner på funktionaliteter. Dette kan give et dybere og mere nuanceret perspektiv end hvad analyser alene kan vise, men det kan være svært at bearbejde og anvende på en meningsfuld måde.

Feedback fra brugerne skal ikke nødvendigvis altid føre til ændringer i softwaren. Det kan også blot være en opmærksomhed, som udviklingsteamet bør tage i betragtning. En feedback giver en mulighed for forbedring, men det er vigtigt at forstå, at ikke al feedback nødvendigvis peger på et konkret problem, som kræver ændringer i softwaren. Nogle gange kan det blot være et udtryk for en følelsesmæssig reaktion på en funktion. Den vigtigste læring fra brugerfeedback er, at det bør opfattes som en gave, ikke som en forpligtelse.

Test i produktion er også et vigtigt aspekt af moderne softwareudvikling. I traditionelle udviklingsprojekter udføres test i produktion som en afsluttende kontrol efter større udgivelser for at sikre, at ændringerne er blevet implementeret korrekt. I en DevOps-tilgang bliver test i produktion en løbende proces, som giver konstant input til udviklingsteamet og dermed påvirker fremtidige iterationer af softwaren.

Der er tre centrale testmetoder i produktionen, som er almindeligt anvendt: A/B-test, beta-test og overvågning som test. A/B-testning er en metode, hvor to versioner af softwaren præsenteres for brugerne i et kontrolleret eksperiment for at se, hvilken version der giver bedst resultater. For eksempel kan en avis teste en ændring af teksten på en abonnementsknap for at se, om den ændrede version fører til flere abonnementer. A/B-testning giver et indblik i, om en ændring i softwaren faktisk har den ønskede effekt.

Det er dog vigtigt at overveje, hvad man måler under A/B-testning. Hvilken variabel er det, vi ønsker at påvirke? Hvor længe vil eksperimentet løbe? Hvordan vil vi sikre, at eksperimentet har statistisk signifikans? I A/B-testning er det grundlæggende antagelsen, at begge versioner af softwaren er verificerede, og at testningen ikke bruges til at finde fejl. I stedet er det en validering af, om den valgte løsning faktisk har den ønskede effekt.

Endelig er det værd at huske på, at selv om feedback fra brugerne kan være utroligt værdifuld, er det ikke altid muligt at implementere ændringer ud fra hver enkelt kommentar. Nogle gange vil feedbacken ikke føre til et konkret resultat, men kan hjælpe udviklingsteamet med at få en bedre forståelse af, hvordan brugerne interagerer med systemet. At bruge feedback som en kontinuerlig læringsmulighed for udviklingsteamet, er afgørende for at skabe et softwareprodukt, der er både stabilt og brugercentreret.

Hvordan Docker og Cloud Computing Forandrer DevOps

Docker blev lanceret i 2013 og har siden da fået en næsten eksplosiv adoption. Dette skyldes i høj grad det tætte forhold til DevOps-bevægelsen, som har ændret måden, udvikling og drift integreres på. Docker gør det muligt for udviklingsteams at få adgang til et hidtil uset antal ensartede miljøer, samtidig med at driftsteamet kan bevare integriteten af systemkonfigurationer. Docker kan tilpasses de fleste populære DevOps-værktøjer som Puppet, Chef, Vagrant og Ansible, eller bruges selvstændigt til at håndtere udviklingsmiljøer. Den primære fordel ved Docker er, at det forenkler mange af de opgaver, som normalt udføres af disse værktøjer, og gør det muligt at sætte lokale udviklingsmiljøer op, der er præcist som en live-server.

Dette muliggør, at flere udviklingsmiljøer kan køre på samme vært, hver med sin egen software, operativsystem og konfigurationer, og det sikrer, at alle arbejder med de samme indstillinger uanset deres lokale miljø. Docker eliminerer også behovet for, at alle i udviklingsteamet skal have de samme versioner af software installeret på deres maskiner, hvilket kan være en stor tidsbesparelse.

Cloud computing og Docker har skabt en synergi, der i høj grad er drevet af behovet for skalerbarhed og fleksibilitet. Cloud computing deler hardware mellem flere brugere via virtualisering og internettet. Dette giver organisationer mulighed for at vælge mellem offentlige, private eller hybride clouds afhængigt af deres behov. En offentlig cloud som Amazon Web Services (AWS) tilbyder databehandlingstjenester fra datacentre rundt om i verden, hvilket giver stor skalerbarhed og redundans.

En privat cloud derimod er vedligeholdt af en organisation selv og giver fuld kontrol over både infrastrukturen og de data, der opbevares. Selvom dette kan have betydelige omkostninger, tilbyder det en højere sikkerhed, som kan være nødvendigt i visse industrier. En hybrid cloud kombinerer begge løsninger, hvor nogle systemer og data håndteres via den private cloud, mens andre kører på den offentlige cloud. Et eksempel på dette kan være en bank, som lægger sin offentlige hjemmeside på en offentlig cloud, men opbevarer de mere følsomme oplysninger om kunder på en privat cloud for at opretholde højere sikkerhed.

Docker og cloud computing går hånd i hånd med DevOps-praksis ved at tilbyde den fleksibilitet og skalerbarhed, der er nødvendig for at understøtte hurtigere udvikling og integration. De traditionelle udviklingsmodeller, hvor udviklere og driftsfolk arbejder i separate siloer, har givet plads til et mere sammenhængende og hurtigt reagerende arbejdsmiljø. DevOps-filosofien bygger på automatisering, og Docker er et kraftfuldt værktøj i denne proces, da det gør det muligt for udviklere at bygge og implementere applikationer hurtigt og konsekvent.

Når man arbejder med Docker og cloud computing, er det vigtigt at forstå, hvordan disse teknologier ændrer måden, vi tænker på systemadministration og udvikling. De ændrer fundamentalt, hvordan software deployeres og vedligeholdes, og hvordan teams kan arbejde på tværs af forskellige miljøer uden at skulle bekymre sig om miljøforskelle. Docker og cloud computing muliggør, at udviklings- og testteams kan køre deres applikationer i virtuelle miljøer, der efterligner produktionssystemer, hvilket reducerer problemer forårsaget af miljøforskelle.

En vigtig pointe at forstå er, hvordan Docker og cloud computing understøtter det, der ofte refereres til som "infrastruktur som kode". Dette begreb betyder, at hele infrastrukturen til at køre applikationer kan beskrives og administreres gennem kode, hvilket gør det muligt at automatisere oprettelsen og vedligeholdelsen af de systemer, applikationerne kører på. Docker gør det muligt at definere miljøer som kodestykker, der kan versionkontrolleres, testes og implementeres på en pålidelig måde.

Det er også vigtigt at være opmærksom på de udfordringer, som Docker og cloud computing kan medføre. Selvom de tilbyder stor fleksibilitet, kan de også skabe kompleksitet, især når det kommer til at sikre, at alle systemer fungerer korrekt på tværs af forskellige miljøer. Docker og cloud computing kræver en højere grad af automatisering og integration mellem forskellige systemer for at sikre, at systemerne forbliver konsistente og pålidelige.

En af de største ændringer, som Docker og cloud computing bringer, er, at servere ikke længere behandles som unikke enheder, men som en del af en "flok". I en DevOps-kontekst refererer man ofte til servere som "kvæg" i stedet for "kæledyr". Dette betyder, at servere kan oprettes, destrueres og erstatte hurtigt og effektivt, hvilket reducerer behovet for at have faste, langvarige infrastrukturer. Denne tankegang ændrer den måde, vi håndterer testmiljøer på, og hvordan vi organiserer vores infrastruktur.

Derudover betyder det, at udviklingsteams nu kan oprette deres egne testmiljøer på en øjeblikkelig og konsistent måde. Når testkørsler kan udføres på præcist samme måde på tværs af alle teammedlemmers lokale maskiner, bliver testprocesserne mere pålidelige og lettere at skalere. Dette gør det muligt for organisationer at implementere kontinuerlig integration og kontinuerlig levering (CI/CD) på en langt mere effektiv måde.

En vigtig afsluttende bemærkning er, at Docker og cloud computing forvandler, hvordan vi ser på infrastruktur. Det er ikke længere nødvendigt at have dedikerede og langvarige servere for hvert udviklings- eller testmiljø. I stedet kan organisationer hurtigt og effektivt oprette og nedlægge virtuelle miljøer efter behov, hvilket giver en højere grad af fleksibilitet og effektivitet i udviklingsprocessen.

Hvordan skaber man samarbejde på tværs af discipliner i teams?

De stier, vi skaber, er i begyndelsen skrøbelige, da de formes mellem to individer. Hvis nogen på en af enderne forsvinder, vil stien blive helt afbrudt. De næste skridt i at bane en vej handler om at modne forbindelsen ved at involvere andre og arbejde hen imod et samarbejdende udveksling mellem discipliner. For at udvide stien og gøre den mere robust bør man invitere flere mennesker til at bruge den ved at udvide publikummet for sin informationsudveksling. Når du har opbygget et forhold til én person i et team og delt noget nyttigt med dem, kan du afholde en session, hvor du deler den samme information med deres kolleger. Når de har delt noget nyttigt med dig, kan du bede dem om at afholde en session for dine kolleger. Marker din sti, så folk kan finde deres egen vej. Dette hjælper både de nuværende teammedlemmer, de der senere vil slutte sig til teamet, og interesserede parter fra andre teams. Det er også vigtigt at optage den viden, der deles, så den kan tilgås senere. Det kan være så enkelt som at gemme PowerPoint-præsentationer i en delt mappe, eller du kan optage viden-delingssessioner for at fange både de visuelle og verbale elementer. Dem, der har mere tid, kan skabe læringsressourcer, der er specielt designet til on-demand-forbrug, som f.eks. en læringsvej, et online kursus eller en bog.

For at udvide stien yderligere kan du invitere forskellige perspektiver til at bidrage. Inden for din organisation kan dette inkludere: at invitere andre til at præsentere deres viden, inddrage personer fra andre discipliner i peer review og debriefing-aktiviteter eller krydsdisciplinært parring og samarbejde om opgaver via mobbing. Du kan også udvide stien ved at invitere folk til at deltage i præsentationer eller konferencer inden for områder, der ligger udenfor deres sædvanlige disciplin.

For at bygge disse tværfaglige forbindelser, som kan hjælpe dig med at forstå og teste bedre, er det vigtigt at starte med at identificere de personer, der arbejder i operationer, support, business intelligence, analyse, callcentre mv. Alle der arbejder uden for udviklingsteamet, men som har forbindelse til det, du leverer. Dette uafhængige brainstorming-aktivitet kan være en god indikator for dit eksisterende netværk. Hvis du har svært ved at komme på navne, så har du enten meget arbejde foran dig eller en dårlig hukommelse! Bed dit udviklingsteam og din leder om at hjælpe med at udvide listen. I en stor organisation kan du også bruge tid på at gennemse det interne virksomhedsregister eller organisationsdiagrammer for at finde personer med jobtitler, der kan være interessante. Det er vigtigt at kaste nettet vidt. Der vil være et naturligt filter, når du begynder at tale med folk og finde ud af, hvilke stier der tilbyder de største muligheder.

Når du har identificeret en gruppe mennesker, bør du forsøge at opbygge en individuel forbindelse med hver af dem. Hvis du er heldig, vil din liste inkludere personer, du allerede har et godt forhold til. Måske er de en tidligere kollega, en ven eller nogen, du interagerer med uden for arbejdet gennem fælles aktiviteter. Hvis dette er tilfældet, kan du springe eller minimere dette skridt i opbygningen af dit arbejdsmæssige forhold til dem. Hvis du ikke har haft nogen direkte interaktion med de personer, du identificerer, kan det være nok at starte med at stille dem et par generelle spørgsmål via e-mail: Hvad laver du til daglig? Hvilke værktøjer bruger du? Hvem interagerer du oftest med? Hvad ved du om min rolle? Hvordan tror du, at jeg kan hjælpe dig? At stille spørgsmål kan være en proaktiv måde at skabe forbindelse på, men det kan også være en skræmmende opgave. Et alternativ, eller noget du kan gøre samtidig, er at skabe muligheder for folk uden for dit team til at komme i kontakt med dig. En måde at gøre dette på er at være opmærksom på at beskrive dine aktiviteter med tilstrækkelig detaljer, så andre kan forstå, hvordan de kan tilbyde hjælp til at fuldføre en opgave.

En af de frustrationer, der kan opstå i agile miljøer, er den dovenskab, der nogle gange viser sig i stand-up møder. Folk giver opdateringer, der skaber en illusion af, at der udveksles information, når der i virkeligheden er meget lidt gennemsigtighed om, hvad folk egentlig laver. Forestil dig, at du er tester i et agile stand-up møde. I samler jer alle omkring jeres visuelle management board, og hver person deler en opdatering. Det er din tur at tale: “I går testede jeg story 19574 og fandt ingen fejl,” siger du og flytter denne story til Done. “I dag tester jeg story 19572,” fortsætter du og flytter den til Doing. “Der er ingenting, der blokkerer mig, så det var det.” Kender du scenariet? Hvis du spørger dem, hvad de har forstået af det, så vil de måske sige, at du tester. Du er testeren. Du har bare fortalt dem, at du tester. Men hvad betyder det egentlig? Har du bekræftet, at acceptkriterierne er opfyldt? Har du undersøgt, hvordan denne story håndterer fejlsituationer? Har du testet fra perspektivet af de forskellige forretningsbrugere? Har du prøvet nogle enkle penetrationstests? Vi kan gøre vores testning mere synlig ved at være mere præcise i vores stand-ups. Det er vigtigt at skabe et klart billede i folks sind af de aktiviteter, du foretager dig. Hvis du ikke er konkret i din beskrivelse, vil det være svært for folk at forstå, hvad du laver, og dermed finde muligheder for at samarbejde med dig.

Hvis den person, du prøver at opbygge en forbindelse med, ikke deltager i dit stand-up møde, er det stadig nyttigt at gøre en vane ud af at beskrive dit daglige arbejde. Regelmæssig øvelse i at forklare, hvad du laver, kan gøre det langt lettere at gentage denne information for en person uden for dit udviklingsteam. På samme måde kan visualisering af information og synliggørelse af den invitere til interaktion. Optagelser, der markerer den fælles forståelse i en bestemt gruppe, kan vække nysgerrighed hos dem, der ikke er en del af gruppen, men som bliver interesseret i, hvad der bliver vist. Det er på denne måde, at du kan invitere til samarbejde på tværs af discipliner.

Jak naučit psa různým trikům a jak na problémy během trénování
Jak komunikují a brání se zvířata v přírodě?
Jaká je cena proklatí a jak moc může оно změnit život člověka?
Jak správně analyzovat rychlosti v mechanismech: analytická a grafická metoda