Hvis bedriften din nettopp introduserer DevOps eller CI/CD-verktøy, kan det være nyttig for deg å bli kjent med de vanligste feilene for ikke å gjenta dem og ikke tråkke på andres rake.
Lag oversatte artikkelen .
Uberedskap for å endre kultur og prosesser
Hvis du ser på det sykliske diagrammet , er det klart at testing i DevOps-praksis er en kontinuerlig aktivitet, en grunnleggende del av hver enkelt distribusjon.
DevOps Infinite Cycle Chart
Testing og kvalitetssikring under utvikling og levering er en vesentlig del av alt utviklere gjør. Dette krever et tankesettskifte for å inkludere testing i hver oppgave.
Testing blir en del av det daglige arbeidet til hvert teammedlem. Overgangen til konstant testing er ikke lett, du må være forberedt på det.
Mangel på tilbakemelding
DevOps effektivitet avhenger av konstant tilbakemelding. Kontinuerlig forbedring er umulig hvis det ikke er rom for samarbeid og kommunikasjon.
Bedrifter som ikke arrangerer retrospektive møter finner det vanskelig å implementere en kultur med kontinuerlig tilbakemelding i CI/CD. Retrospektive møter holdes på slutten av hver iterasjon, der teammedlemmene diskuterer hva som gikk bra og hva som gikk dårlig. Retrospektive møter er grunnlaget for Scrum/Agile, men de er også nødvendige for DevOps.
Dette er fordi retrospektive møter gir en vane med å utveksle tilbakemeldinger og meninger. Et av de viktigste punktene i starten er å organisere tilbakevendende retromøter slik at de blir forståelige og kjente for hele teamet.
Når det gjelder programvarekvalitet, er alle teammedlemmer ansvarlige for å vedlikeholde den. For eksempel kan utviklere skrive enhetstester og også skrive kode med testbarhet i tankene, noe som bidrar til å redusere risikoen fra starten.
En enkel måte å gjenspeile endringen i tenkningen rundt testing er å kalle testere ikke QA, men programvaretester eller kvalitetsingeniør. Denne endringen kan virke for enkel eller til og med dum. Men å kalle noen en "kvalitetssikringsperson for programvare" gir feil oppfatning av hvem som er ansvarlig for kvaliteten på produktet. I Agile-, CI/CD- og DevOps-praksis er alle ansvarlige for programvarekvalitet.
Et annet viktig poeng er å forstå hva kvalitet betyr for hele teamet og hvert av dets medlemmer, organisasjonen og interessenter.
Misforståelse av ferdigstillelse av etappe
Hvis kvalitet er en kontinuerlig og generell prosess, er det nødvendig med en felles forståelse av fasegjennomføring. Hvordan vet du når en scene er over? Hva skjer når et trinn er merket som fullført på et Trello- eller annet Kanban-brett?
Definition of Done (DoD) er et kraftig verktøy i sammenheng med CD DevOps/CI. Det hjelper å bedre forstå kvalitetsstandardene for hva og hvordan teamet bygger.
Utviklingsteamet må bestemme hva «Ferdig» betyr. De må sette seg ned og lage en liste over egenskaper som må oppfylles i hvert trinn for at det skal anses som komplett.
DoD gjør prosessen mer gjennomsiktig og gjør det lettere å implementere CI/CD hvis det er forstått av alle teammedlemmer og gjensidig avtalt.
Mangel på realistiske, klart definerte mål
Dette er et av de mest siterte rådene, men det tåler å gjentas. For å lykkes med noen større bestrebelser, inkludert CI/CD eller DevOps, må du sette deg realistiske mål og måle ytelsen mot dem. Hva prøver du å oppnå med CI/CD? Tillater dette raskere utgivelser med bedre kvalitet?
Eventuelle mål som settes må ikke bare være transparente og realistiske, men også være i samsvar med selskapets nåværende aktiviteter. Hvor ofte trenger kundene dine for eksempel nye oppdateringer eller versjoner? Det er ikke nødvendig å overbelaste prosesser og frigjøre raskere hvis det ikke er noen ekstra fordel for brukerne.
I tillegg trenger du ikke alltid å implementere både CD og CI. For eksempel kan sterkt regulerte selskaper som banker og medisinske klinikker bare jobbe med CI.
CI fungerer som et godt utgangspunkt for ethvert selskap som implementerer DevOps. Når det implementeres, endres bedrifters tilnærminger til programvarelevering betydelig. Når CI er mestret, kan du tenke på å forbedre hele prosessen, øke utrullingshastigheten og andre endringer.
For mange organisasjoner er CI alene tilstrekkelig, og CD bør bare implementeres hvis det tilfører verdi.
Mangel på passende instrumentbord og beregninger
Når du har satt deg mål, kan utviklingsteamet lage et dashbord for å måle KPIer. Før utviklingen er det verdt å vurdere parametrene som vil bli overvåket.
Ulike rapporter og applikasjoner er nyttige for forskjellige teammedlemmer. Scrum Master er mer interessert i status og rekkevidde. Mens toppledelsen kan være interessert i utbrenthetsraten til spesialister.
Noen lag bruker også dashbord med røde, gule og grønne indikatorer for å vurdere statusen til CI/CD for å forstå om de gjør alt riktig eller om det er en feil. Rød betyr at du må være oppmerksom på hva som skjer.
Men hvis dashbord ikke er standardiserte, kan de være misvisende. Analyser hvilke data alle trenger, og lag deretter en standardisert beskrivelse av hva det betyr. Finn ut hva som gir mer mening for interessenter: grafikk, tekst eller tall.
Ingen manuelle tester
Testautomatisering legger grunnlaget for en god CI/CD-pipeline. Men automatisert testing på alle stadier betyr ikke at du ikke skal gjennomføre manuell testing.
For å bygge en effektiv CI/CD-pipeline trenger du også manuelle tester. Det vil alltid være noen aspekter ved testing som krever menneskelig analyse.
Det er verdt å vurdere å integrere manuell testing i rørledningen. Når den manuelle testingen av noen testtilfeller er fullført, kan du gå videre til distribusjonsfasen.
Ikke prøv å forbedre tester
En effektiv CI/CD-pipeline krever tilgang til de riktige verktøyene, enten det er testadministrasjon eller integrasjon og løpende overvåking.
Å skape en sterk, kvalitetsorientert kultur tar sikte på , overvåking av kundeinteraksjoner etter distribusjon og sporing av forbedringer.
Her er noen praktiske tips som du enkelt kan implementere:
- Sørg for at testene dine er enkle å skrive og fleksible nok til at de ikke går i stykker når du refaktoriserer koden.
- Utviklingsteam bør inkluderes i testprosessen - se en liste over brukerproblemer og forespørsler som er viktige å teste under CI-pipelines.
- Du har kanskje ikke full testdekning, men sørg alltid for at flyter som er viktige for UX og kundeopplevelse blir testet.
Sist men ikke minst viktig poeng
Overgangen til CI/CD er vanligvis drevet fra bunnen og opp, men til syvende og sist er det en transformasjon som krever lederskap, tid og ressurser fra selskapet. Tross alt er CI/CD et sett med ferdigheter, prosesser, verktøy og kulturell omstrukturering; slike endringer kan bare implementeres systematisk.
Hva annet å lese om emnet:
- .
- .
- .
Kilde: www.habr.com