Der tales meget om continuous delivery(CD) for tiden – nok ikke mindst fordi SAFe rammeværket er blevet meget populært, og CD er en central del af SAFe, og er en af nøglerne til virkelig at få værdi ud af SAFe. Der findes mange definitioner af CD, men generelt er det noget i stil med:
Continuous delivery er en metode, der lader teams hurtigt, sikkert og fortløbende levere ændringer til slutbrugere når forretningen ønsker det.
Måden man gør det på er ved at lave en eller flere processer, der mere eller mindre automatisk kan skubbe en lille ændring af softwaren op igennem en række testmiljøer der ligner produktionssystemet mere og mere og til sidst frigiver ændringen ud i produktionsmiljøet.
Der er naturligvis mange dele i sådan en proces, og det jeg vil dele her er de vigtigste erfaringer jeg har gjort mig i forhold til at implementere testen i CD.
ERFARING 1: LAD IKKE TEST BLIVE EN SILO (IGEN)
I agile giver man teamet ansvar for kvaliteten. Der kan dog stadig godt være en tendens til at det er specifikke personer på teamet der tager ansvaret – specielt hvis man har dedikerede testere på teamet. Det er helt fint, hvis man releaser hver 14. dag, og på mange måder giver det god mening, at de personer der brænder mest for test også står for det meste af testen. Når man går over til en proces der potentielt kan release flere gange dagligt, bliver det ofte en eller to personer der driver en ændring hele vejen igennem, og så bliver det dog enormt vigtigt, at det er hele teamet der føler ansvar for kvaliteten. Ikke bare at acceptkriterierne på en userstory er opfyldt, men også at slutbrugeren får en god oplevelse med at bruge softwaren.
ERFARING 2: FOKUSER PÅ PRODUKTDÆKNING FREM FOR KODEDÆKNING
Når vi skal release ofte kan man ikke nå at teste alt – heller ikke selvom testen er automatiseret! Det er en kamel der lige skal sluges, men når man har gjort det, så er der nogle ting man kan gøre i stedet. Den første er en gammel kending: risikobaseret test! En af nøglerne for mig har været at få produktrisikoanalysen integreret dybt ind i den agile proces. Ikke i den traditionelle form med møder og skemaer, ved at gøre det til en vane i teamet at vurdere og løbende diskutere sandsynlighed og konsekvens hver gang vi arbejder med en story eller feature. Den anden ting jeg har gode erfaringer med, er at fokusere testen på de dele af produktet der er vigtige for slutbrugerne. Hvis man ellers laver sin risikoanalyse rigtig, så kommer normalt også til at teste der hvor konsekvensen for brugerne er høje, men jeg har fået god værdi ud af, også at bruge lidt tid på, at finde ud af, hvilke brugere der er vigtigst, og hvilke dele af applikationen der er vigtigst for dem.
ERFARING 3: MÅL KVALITETEN VIA FLERE KANALER
De fleste af os er vant til at måle kvalitet via manuel eller automatisk test, og evt. fra værktøjer der kan udføre statisk analyse på koden. Hvis vi skal release hurtigt og ofte, så er dog vigtigt at få flere andre kilder med. Dels bliver det endnu vigtigere løbende at overvåge ikke funktionelle karakteristika som svartider, men logfiler og produktionssystemet bliver også vigtige kilder. Ligesom med erfaring 2 er der lidt en kamel der skal sluges i forhold til, at man også “tester” i produktion. Det er ikke fri leg, men når man releaser så ofte, vil der nogle gange slippe fejl igennem. Ved at overvåge svartider, logfiler osv. kan man spotte de fejl inden brugerne oplever dem. Traditionelt har driftsorganisationen måske gjort det samme, men i CD bliver det et vigtigt værktøj for teamet.
Det er et stort emne, og ikke alle teams vil få lige store mængder af adgang til produktion, men løbende overvågning af logfiler og svartider på testmiljøerne i forbindelse med test, vil alle kunne få gavn af. Man kan evt. overveje at bruge aggregerings værktøjer som ELK-stack der kan indsamle logs og metriker fra flere kilder, for at gøre det lettere at overskue.
ERFARING 4: TEST LØBENDE, OG IKKE I SLUTNINGEN
Jo hurtigere vi finder fejlen, jo hurtigere kan vi rette den. Derfor er det vigtigt at teste ting så hurtigt, som muligt. Det betyder normalt, at man tester detaljer på de lavere miljøer – dvs. dem uden så mange integrationer, og sammenhænge og værdi for slutbrugere på de højere miljøer. Det er derfor vigtigt at fokusere på, hvad der testes hvornår i de enkelte features og stories. Husk også at teste de mere operationelle sider af applikationen. Husk f.eks. at udarbejde og teste effektive roll-back rutiner, så man kan rulle en ændring tilbage. Det gør det langt mindre risikofyldt at release noget til produktion, hvis man kan tage det af igen.
ERFARING 5: FÅ INFRASTRUKTURKOMPETENCER IND I TEAMET
Når man kører CD skal teamet være endnu mere tværfunktionelt end tidligere. Der kræves mere viden om netværk, firewalls, scripting, osv. end normale applikationsudviklere typisk har. Ved at få personer fra infrastruktur eller drift ind på teamet, får man de kompetencer, og samtidig får man folk der er vant til at håndtere produktionssystemer, og har fokus på kvaliteten af de føromtalte operationelle sider af en applikation.
Det var mine fem bud på, hvordan du får en god og effektiv test når du kører continuous delivery. Den her slags indlæg er i sagens natur aldrig udtømmende, og vil ofte skulle justeres til den kontekst man er i, men jeg håber de kan inspirere. Flere af dem laver også nogle forudsætninger om uafhængige teams, og løst koblede systemer, som ikke altid er opfyldt. Hvis du er i den situation, kan du måske få gavn af det her indlæg: Continuous Delivery i en ikke perfekt verden