Hvis din virksomhed bare implementerer DevOps eller CI/CD værktøjer, kan det være nyttigt for dig at sætte dig ind i de mest almindelige fejl, så du ikke gentager dem og træder på andres rake.
Team oversatte artiklen .
Uvilje til at ændre kultur og processer
Ser på cyklusdiagrammet , er det klart, at i DevOps-praksis er test et kontinuerligt arbejde, en grundlæggende del af hver enkelt implementering.
DevOps Endless Cycle Diagram
Test og kvalitetssikring under udvikling og levering er en væsentlig del af alt, hvad udviklere gør. Dette kræver en mindset-ændring for at inkludere test i hver opgave.
Test bliver en del af det daglige arbejde for hvert teammedlem. Overgangen til kontinuerlig test er ikke let, du skal være forberedt på dette.
Mangel på feedback
Effektiviteten af DevOps afhænger af konstant feedback. Løbende forbedringer er ikke mulige, hvis der ikke er plads til samarbejde og kommunikation.
Virksomheder, der ikke arrangerer retrospektive møder, har svært ved at implementere en kultur med kontinuerlig feedback i CI/CD. Retrospektive møder afholdes i slutningen af hver iteration, hvor gruppemedlemmerne diskuterer, hvad der gik godt, og hvad der gik galt. Retrospektive møder er grundlaget for Scrum/Agile, men de er også essentielle for DevOps.
Dette skyldes, at retrospektive møder indgyder vanen med at udveksle feedback og meninger. Et af de vigtigste momenter i starten er tilrettelæggelsen af tilbagevendende retromøder, så de bliver forståelige og velkendte for hele teamet.
Når det kommer til softwarekvalitet, er alle teammedlemmer ansvarlige for at vedligeholde den. For eksempel kan udviklere skrive enhedstests samt kode med testbarhed i tankerne, hvilket hjælper med at mindske risikoen fra starten.
En nem måde at afspejle de skiftende opfattelser af test er at kalde testere ikke QA, men softwaretester eller kvalitetsingeniør. Denne ændring kan virke for enkel eller endda dum. Men at kalde en "software kvalitetssikringsspecialist" giver en forkert idé om, hvem der er ansvarlig for produktkvaliteten. I Agile-, CI/CD- og DevOps-praksis er alle ansvarlige for softwarekvalitet.
Et andet vigtigt punkt er at forstå, hvad kvalitet betyder for hele teamet og hvert af dets medlemmer, organisation, interessenter.
Misforståelse af faseafslutning
Hvis kvalitet er en kontinuerlig og delt proces, er der behov for en fælles forståelse af færdiggørelsen af et trin. Hvordan forstår man, at scenen er forbi? Hvad sker der, når en milepæl er markeret som afsluttet på et Trello-tavle eller et andet kanban-tavle?
At bestemme en gennemført milepæl (DoD) er et kraftfuldt værktøj i forbindelse med CD DevOps/CI. Det hjælper til bedre at forstå kvalitetsstandarderne for, hvad og hvordan teamet bygger.
Udviklingsteamet skal beslutte, hvad "Udført" betyder. De skal sætte sig ned og lave en liste over de egenskaber, der skal opfyldes på hvert trin, så det kan betragtes som komplet.
DoD gør processen mere gennemsigtig og letter implementeringen af CI/CD, hvis det er klart for alle teammedlemmer og gensidigt aftalt.
Mangel på realistiske, klart definerede mål
Dette er et af de oftest citerede tips, men det er værd at gentage. For at enhver seriøs virksomhed skal lykkes, herunder implementering af CI/CD eller DevOps, skal du sætte realistiske mål og måle ydeevnen i forhold til dem. Hvad forsøger du at opnå med CI/CD? Tillader det hurtigere udgivelser med bedre kvalitet?
Ethvert mål skal ikke kun være gennemsigtigt og realistisk, men også i overensstemmelse med virksomhedens nuværende aktiviteter. For eksempel, hvor ofte har dine kunder brug for nye patches eller versioner? Der er ingen grund til at overbelaste processer og frigive hurtigere, hvis der ikke er yderligere fordele for brugerne.
Du behøver heller ikke altid at implementere både CD og CI. For eksempel må stærkt regulerede virksomheder som banker og lægeklinikker kun arbejde med CI.
CI er et godt udgangspunkt for enhver virksomhed, der implementerer DevOps. Når det implementeres i en virksomhed, ændres tilgange til softwarelevering markant. Når CI er mestret, kan du overveje at forbedre hele processen, øge udrulningshastigheden og andre ændringer.
For mange organisationer er én CI tilstrækkelig, og CD bør kun implementeres, hvis det tilføjer værdi.
Mangel på relevante dashboards og målinger
Når du har sat mål, kan udviklingsteamet oprette et dashboard til at måle KPI'er. Før dets udvikling er det umagen værd at evaluere de parametre, der vil blive overvåget.
Forskellige rapporter og apps er nyttige for forskellige teammedlemmer. Scrum-mestre er mere optaget af status og rækkevidde. Mens den øverste ledelse kan være interesseret i graden af udbrændthed af specialister.
Nogle hold bruger også dashboards med røde, gule og grønne indikatorer til at vurdere status for CI/CD, for at forstå, om de gør alt rigtigt, eller om der er opstået en fejl. Rød betyder, at du skal være opmærksom på, hvad der sker.
Men hvis dashboards ikke er standardiserede, kan de være vildledende. Analyser, hvilke data alle har brug for, og lav derefter en standardiseret beskrivelse af, hvad det betyder. Find ud af, hvad der giver mere mening for dine interessenter: grafik, tekst eller tal.
Mangel på manuelle tests
Testautomatisering lægger grundlaget for en god CI/CD-pipeline. Men automatiseret test på alle stadier betyder ikke, at du ikke skal lave manuel test.
For at bygge en effektiv CI/CD-pipeline er der også behov for manuelle tests. Der vil altid være nogle aspekter af test, der kræver menneskelig analyse.
Det er værd at overveje at integrere manuel testindsats i pipelinen. Når den manuelle test af nogle testsager er afsluttet, kan du gå videre til implementeringsfasen.
Forsøg ikke at forbedre tests
En effektiv CI/CD-pipeline kræver adgang til de rigtige værktøjer, hvad enten det er teststyring eller integration og løbende overvågning.
At skabe en stærk, kvalitetsorienteret kultur sigter mod , overvåg kundeoplevelse efter implementering og spor forbedringer.
Her er nogle praktiske tips, som du nemt kan implementere:
- Sørg for, at testene er nemme at skrive og fleksible nok til ikke at gå i stykker, når koden refaktoreres.
- Udviklingsteams bør inkluderes i testprocessen - se en liste over brugerproblemer og anmodninger, som er vigtige at teste under CI-pipelines.
- Du har måske ikke fuld testdækning, men sørg altid for, at de flows, der er vigtige for UX og kundeoplevelse, bliver testet.
Sidst men ikke mindst punkt
Overgangen til CI/CD sættes normalt i gang nedefra, men i sidste ende er det en transformation, der kræver ledelsesinvolvering, tid og ressourcer fra virksomhedens side. Når alt kommer til alt, er CI / CD et sæt af færdigheder, processer, værktøjer og kulturel omstrukturering, sådanne ændringer kan kun implementeres systematisk.
Hvad skal man ellers læse om emnet:
- .
- .
- .
Kilde: www.habr.com