Hvis dit firma lige er ved at implementere DevOps eller CI/CD værktøjer, kan det være nyttigt at lære om de mest almindelige fejl, så du ikke gentager dem og falder i andres fælder.
Kommandoen oversatte artiklen .
Manglende parathed til at ændre kultur og processer
Når man ser på den cykliske graf , er det tydeligt, at testing i DevOps-praksis er en kontinuerlig aktivitet, en grundlæggende del af hver enkelt implementering.
Uendelig cyklisk graf over DevOps
Testning og kvalitetssikring i udviklings- og leveringsprocessen er en obligatorisk del af alt, hvad udviklerne gør. Det kræver en ændring i tankegangen for at inkludere testing i hver opgave.
Testing bliver en del af den daglige arbejdsrutine for hvert medlem af teamet. Overgangen til kontinuerlig testning er ikke let, og der skal være en parathed til dette.
Manglende feedback
Effektiviteten af DevOps afhænger af konstant feedback. Kontinuerlig forbedring er umulig, hvis der ikke er plads til samarbejde og kommunikation.
Virksomheder, der ikke organiserer retrospektive møder, har svært ved at implementere en kultur for kontinuerlig feedback i CI/CD. Retrospektive møder afholdes i slutningen af hver iteration, hvor gruppens medlemmer diskuterer, hvad der gik godt, og hvad der gik dårligt. Retrospektive møder er fundamentet for Scrum/Agile, men de er også nødvendige for DevOps.
Dette skyldes, at retrospektive møder indfører vanen med at udveksle feedback og meninger. Et af de vigtigste punkter i starten er at organisere tilbagevendende retrospektive møder, så de bliver klare og almindelige for hele teamet.
Når det kommer til softwarekvalitet, har alle teammedlemmer ansvar for at opretholde den. For eksempel kan udviklere skrive enhedstest samt skrive kode med testbarhed for øje, hvilket hjælper med at reducere risici fra starten.
En af de enkle måder at reflektere ændringer i opfattelsen af testning er at kalde testere for ikke QA, men softwaretester eller kvalitetsingeniør. Denne ændring kan virke for simpel eller endda dum. Men hvis nogen kaldes 'softwarekvalitetsspecialist', giver det et misvisende indtryk af, hvem der er ansvarlig for produktkvaliteten. I Agile, CI/CD og DevOps er alle ansvarlige for softwarekvalitet.
En anden vigtig pointe er at forstå, hvad kvalitet betyder for hele teamet og hver enkelt medlem, organisationen og interessenterne.
Misforståelse af afslutning af et trin
Hvis kvalitet er en kontinuert og fælles proces, er der behov for en fælles forståelse af, hvornår et trin er afsluttet. Hvordan ved man, at et trin er færdigt? Hvad sker der, når et trin er markeret som komplet på Trello eller et andet kanban-board?
Definitionen af færdig trin (DoD) er et stærkt værktøj i sammenhæng med CD DevOps/CI. Den hjælper med bedre at forstå kvalitetsstandarderne for, hvad og hvordan teamet bygger.
Udviklerteamet skal beslutte, hvad 'Færdig' betyder. De skal sætte sig ned og lave en liste over de kriterier, som skal være opfyldt på hvert trin, for at det kan betragtes som fuldført.
DoD gør processen mere gennemsigtig og letter implementeringen af CI/CD, hvis den er forståelig for alle teammedlemmer og gensidigt aftalt.
Mangel på realistiske og klart definerede mål
Dette er et af de mest citerede råd, men det er værd at gentage. For at få succes med enhver større indsats, herunder implementeringen af CI/CD eller DevOps, er det nødvendigt at fastsætte realistiske mål og måle præstationen i forhold til dem. Hvad forsøger du at opnå med CI/CD? Gør det hurtigere at udgive versioner med bedre kvalitet?
Enhver fastsat målsætning bør være ikke kun gennemsigtig og realistisk, men også i overensstemmelse med virksomhedens nuværende aktiviteter. For eksempel, hvor ofte har dine kunder behov for nye rettelser eller versioner? Der er ingen grund til at overbelaste processerne og udgive versioner hurtigere, hvis det ikke giver yderligere fordele for brugerne.
Desuden behøver du ikke altid at implementere både CD og CI. For eksempel kan virksomheder med høj regulering, såsom banker og medicinske klinikker, kun arbejde med CI.
CI fungerer som et godt udgangspunkt for enhver virksomhed, der implementerer DevOps. Når det er implementeret, ændres tilgangen til softwarelevering markant. Når CI er behersket, kan man overveje at forbedre hele processen, øge udrulningshastigheden og foretage andre ændringer.
For mange organisationer er ét CI tilstrækkeligt, og CD bør kun implementeres, hvis det giver ekstra værdi.
Mangel på relevante overvågningspaneler og metrics
Når du har fastlagt målene, kan udviklingsteamet oprette et overvågningspanel til at måle KPI'er. Før udviklingen af dette panel er det værd at vurdere, hvilke parametre der skal overvåges.
Forskellige rapporter og applikationer er nyttige for forskellige medlemmer af teamet. Scrum Masters er mere interesseret i status og dækning, mens ledelsen kan være interesseret i specialisternes udbrændingshastighed.
Nogle teams bruger også dashboards med røde, gule og grønne indikatorer til at vurdere status på CI/CD, så de kan forstå, om de gør det rigtigt, eller om der er opstået en fejl. Rødt betyder, at der skal gives opmærksomhed til det, der sker.
Men hvis informationspanelerne ikke er standardiserede, kan de være misvisende. Analyser hvilke data alle har brug for, og opret dernæst en standardiseret beskrivelse af, hvad de betyder. Find ud af, hvad der giver mest mening for interessenterne: grafer, tekst eller tal.
Mangel på manuelle tests
Automatisering af test lægger grundlaget for en god CI/CD.pipeline. Men automatiseret test på alle trin betyder ikke, at du ikke skal udføre manuelle tests.
For at bygge en effektiv CI/CD.pipeline kræves også manuelle tests. Der vil altid være nogle aspekter af test, der kræver menneskelig analyse.
Det er værd at overveje at integrere bestræbelserne omkring manuelle tests i pipeline. Når manuelle tests af nogle testcases er afsluttet, kan du gå videre til udrulningsfasen.
Forsøg ikke at forbedre testene.
En effektiv CI/CD-kæde kræver adgang til de rette værktøjer, hvad enten det er testadministration eller integration og konstant overvågning.
Opbygning af en stærk, kvalitetsorienteret kultur sigter mod , overvågning af kundernes interaktioner efter implementeringen og sporing af forbedringer.
Her er nogle praktiske råd, som du nemt kan implementere:
- Sørg for, at tests er lette at skrive og tilstrækkeligt fleksible til ikke at bryde ved refaktorering af koden.
- Udviklingsteam skal inddrages i testprocessen - se listen over brugerproblemer og anmodninger, som er vigtige at teste under CI-kæder.
- Du har måske ikke fuld testdækning, men sørg altid for, at strømme, der er vigtige for UX og kundernes interaktion, er blevet testet.
Sidste men ikke mindst
Overgangen til CI/CD initiativt ofte fra bunden, men i sidste ende er det en transformation, der kræver ledelsesdeltagelse, tidsomkostninger og ressourcer fra virksomheden. For CI/CD indebærer det et sæt færdigheder, processer, værktøjer og en kulturel omstrukturering, og sådanne ændringer kan kun implementeres systematisk.
Andre artikler om emnet:
- .
- .
- .
Kilde: habr.com
