Om ditt företag just introducerar DevOps eller CI/CD-verktyg kan det vara användbart för dig att bekanta dig med de vanligaste misstagen för att inte upprepa dem och inte trampa på någon annans rake.
Team översatte artikeln .
Oförberedelse för att förändra kultur och processer
Om man tittar på det cykliska diagrammet , är det tydligt att i DevOps praxis testning är en kontinuerlig aktivitet, en grundläggande del av varje enskild distribution.
DevOps Infinite Cycle Chart
Testning och kvalitetssäkring under utveckling och leverans är en väsentlig del av allt utvecklare gör. Detta kräver ett tankesätt för att införliva testning i varje uppgift.
Testning blir en del av det dagliga arbetet för varje gruppmedlem. Övergången till konstant testning är inte lätt, du måste vara beredd på det.
Brist på feedback
DevOps effektivitet beror på ständig feedback. Ständiga förbättringar är omöjliga om det inte finns utrymme för samarbete och kommunikation.
Företag som inte anordnar retrospektiva möten har svårt att implementera en kultur av kontinuerlig feedback i CI/CD. Retrospektiva möten hålls i slutet av varje iteration, under vilka gruppmedlemmarna diskuterar vad som gick bra och vad som gick dåligt. Retrospektiva möten är grunden för Scrum/Agile, men de är också nödvändiga för DevOps.
Detta beror på att retrospektiva möten ingjuter vanan att utbyta feedback och åsikter. En av de viktigaste punkterna i starten är att organisera återkommande retroträffar så att de blir begripliga och bekanta för hela teamet.
När det kommer till mjukvarukvalitet är alla teammedlemmar ansvariga för att underhålla den. Till exempel kan utvecklare skriva enhetstester och även skriva kod med testbarhet i åtanke, vilket hjälper till att minska risken från början.
Ett enkelt sätt att spegla förändringen i tänkandet kring testning är att anropa testare inte QA, utan mjukvarutestare eller kvalitetsingenjör. Denna förändring kan verka för enkel eller till och med dum. Men att kalla någon för "kvalitetssäkringsperson för mjukvara" ger fel uppfattning om vem som är ansvarig för produktens kvalitet. I Agile-, CI/CD- och DevOps-praxis är alla ansvariga för mjukvarans kvalitet.
En annan viktig punkt är att förstå vad kvalitet betyder för hela teamet och var och en av dess medlemmar, organisationen och intressenter.
Missförstånd av färdigställande av etapper
Om kvalitet är en kontinuerlig och generell process, behövs en gemensam förståelse för stegavslutning. Hur vet du när ett skede är över? Vad händer när ett steg markeras som avslutat på en Trello eller annan Kanban-bräda?
Definition of Done (DoD) är ett kraftfullt verktyg i samband med CD DevOps/CI. Det hjälper till att bättre förstå kvalitetsstandarderna för vad och hur teamet bygger.
Utvecklingsteamet måste bestämma vad "Klart" betyder. De måste sätta sig ner och göra en lista över egenskaper som måste uppfyllas i varje steg för att det ska anses vara komplett.
DoD gör processen mer transparent och gör det lättare att implementera CI/CD om det förstås av alla teammedlemmar och kommer överens om det.
Brist på realistiska, tydligt definierade mål
Detta är ett av de mest citerade råden, men det tål att upprepas. För att lyckas med någon större strävan, inklusive CI/CD eller DevOps, måste du sätta realistiska mål och mäta prestanda mot dem. Vad försöker du uppnå med CI/CD? Tillåter detta snabbare releaser med bättre kvalitet?
Alla uppsatta mål måste inte bara vara transparenta och realistiska, utan också vara förenliga med företagets nuvarande aktiviteter. Till exempel, hur ofta behöver dina kunder nya patchar eller versioner? Det finns inget behov av att överbelasta processer och släppa snabbare om det inte finns några ytterligare fördelar för användarna.
Dessutom behöver du inte alltid implementera både CD och CI. Till exempel får högt reglerade företag som banker och medicinska kliniker bara arbeta med CI.
CI fungerar som en bra utgångspunkt för alla företag som implementerar DevOps. När det implementeras förändras företagens tillvägagångssätt för leverans av programvara avsevärt. När CI väl har bemästrats kan du tänka på att förbättra hela processen, öka utrullningshastigheten och andra förändringar.
För många organisationer är CI enbart tillräckligt, och CD bör endast implementeras om det tillför värde.
Brist på lämpliga instrumentpaneler och mätvärden
Как только вы установили цели, команда разработчиков может создать панель мониторинга для измерения KPI. До ее разработки стоит провести оценку параметров, которые будут отслеживаться.
Olika rapporter och applikationer är användbara för olika teammedlemmar. Scrum Master är mer intresserad av status och räckvidd. Medan högre ledning kan vara intresserad av utbrändhet hos specialister.
Vissa team använder också instrumentpaneler med röda, gula och gröna indikatorer för att bedöma statusen för CI/CD för att förstå om de gör allt rätt eller om det finns ett fel. Rött betyder att du måste vara uppmärksam på vad som händer.
Men om instrumentpaneler inte är standardiserade kan de vara vilseledande. Analysera vilken data alla behöver och skapa sedan en standardiserad beskrivning av vad det betyder. Ta reda på vad som är mer meningsfullt för intressenter: grafik, text eller siffror.
Inga manuella tester
Testautomation lägger grunden för en bra CI/CD-pipeline. Men automatiserad testning i alla led betyder inte att du inte ska utföra manuell testning.
För att bygga en effektiv CI/CD-pipeline behöver du också manuella tester. Det kommer alltid att finnas vissa aspekter av testning som kräver mänsklig analys.
Det är värt att överväga att integrera manuella testinsatser i din pipeline. När den manuella testningen av vissa testfall är klar kan du gå vidare till distributionsfasen.
Försök inte förbättra testerna
En effektiv CI/CD-pipeline kräver tillgång till rätt verktyg, vare sig det är testhantering eller integration och löpande övervakning.
Att skapa en stark, kvalitetsorienterad kultur syftar till att , övervakar kundinteraktioner efter implementering och spårar förbättringar.
Här är några praktiska tips som du enkelt kan implementera:
- Se till att dina tester är lätta att skriva och tillräckligt flexibla för att inte gå sönder när du refaktorerar koden.
- Utvecklingsteam bör inkluderas i testprocessen - se en lista över användarproblem och förfrågningar som är viktiga att testa under CI-pipelines.
- Du kanske inte har full testtäckning, men se alltid till att flöden som är viktiga för UX och kundupplevelse testas.
Sist men inte minst viktig punkt
Övergången till CI/CD drivs vanligtvis nerifrån och upp, men i slutändan är det en transformation som kräver inköp av ledarskap, tid och resurser från företaget. När allt kommer omkring är CI/CD en uppsättning färdigheter, processer, verktyg och kulturell omstrukturering; sådana förändringar kan endast implementeras systematiskt.
Vad mer att läsa om ämnet:
- .
- .
- .
Källa: will.com