Programmering

5 vanlige fallgruver for CI / CD - og hvordan du kan unngå dem

Devops kan være et av de mest uhyggelige begrepene innen programvareutvikling, men de fleste av oss er enige om at fem aktiviteter gjør devops til hva det er: kontinuerlig integrering, kontinuerlig levering, skyinfrastruktur, testautomatisering og konfigurasjonsadministrasjon. Hvis du gjør disse fem tingene, gjør du devops. Det er klart at alle fem er viktige for å få rett, men altfor lett å ta feil. Spesielt kan kontinuerlig integrering og kontinuerlig levering (CI / CD) være de vanskeligste devops trekk for å mestre.

Kontinuerlig integrasjon (CI) er en prosess der utviklere og tester samarbeider validerer ny kode. Tradisjonelt skrev utviklere kode og integrerte den en gang i måneden for testing. Det var ineffektivt - en feil i koden fra fire uker siden kunne tvinge utviklerne til å revidere koden som ble skrevet for en uke siden. For å løse dette problemet, er CI avhengig av automatisering for å integrere og teste koden kontinuerlig. Scrum-team som bruker CI forplikter kode i det minste i det daglige, mens et flertall av dem begår kode for alle innførte endringer.

Kontinuerlig levering (CD) er prosessen med kontinuerlig å lage frigjørbare gjenstander. Noen selskaper gir ut til brukerne en eller flere ganger om dagen, mens andre gir ut programvaren i et lavere tempo av markedsmessige årsaker. Uansett testes evnen til å frigjøre kontinuerlig. Kontinuerlige utplassering er mulig takket være skymiljøer. Servere er konfigurert slik at du kan distribuere til produksjon uten å avslutte og manuelt oppdatere servere.

Dermed er CI / CD en prosess for kontinuerlig utvikling, testing og levering av ny kode. Noen selskaper som Facebook og Netflix bruker CI / CD for å fullføre 10 eller flere utgivelser per uke. Andre selskaper sliter med å oppnå det tempoet fordi de gir etter for en eller flere av fem fallgruver jeg skal diskutere videre.

CI / CD fallgruve nr. 1: Automatiser feil prosesser først

Denne fellen har en tendens til å streike organisasjoner som skifter fra utvikling av foss til devops. Nye organisasjoner har fordelen av å implementere CI / CD fra bunnen av. Eksisterende selskaper må reise gradvis fra manuell til svært automatisert utvikling. Full overgang kan ta flere måneder, noe som betyr at du må være iterativ i hvordan du bruker CI / CD.

Når du spør "Må dette automatiseres nå?" kjør gjennom følgende sjekkliste:

  1. Hvor ofte gjentas prosessen eller scenariet?
  2. Hvor lang er prosessen?
  3. Hvilke mennesker og ressursavhengigheter er involvert i prosessen? Forårsaker de forsinkelser i CI / CD?
  4. Er prosessen feilutsatt hvis den ikke er automatisert?
  5. Hva haster det med å få prosessen automatisert?

Ved hjelp av denne sjekklisten kan du prioritere trinnene i en CI / CD-implementering. Først og fremst automatiser prosessen for å kompilere kode. Ideelt sett vil du integrere kode flere ganger per dag (1). Manuelt tar prosessen noen minutter til et par timer (2). Det stopper utdata til kompilatoren fullfører oppgaven (3). Det er også utsatt for menneskelige feil (4), og fordi CI / CD er en rørdrøm uten automatisert integrasjon, er dette presserende (5).

Vi kan kjøre den samme sjekklisten ved testing. Når du går over til CI / CD, kan du lure på: Bør vi automatisere funksjonstesting eller UI-testing først? Begge vil bli gjentatt minst en gang per dag (1). Begge kan ta to til tre timer for en mellomstor applikasjon (2). Men de involverer flere avhengigheter (3). Hvis du automatiserer funksjonstesting, trenger du ikke å oppdatere automatiseringsskriptet ofte. Brukergrensesnittet, derimot, endres ofte og krever derfor hyppige skiftendringer. Selv om begge er feilutsatte (4), bør du prioritere funksjonstesting før UI-testing for å utnytte ressursene dine best (5).

La oss gjøre dette en gang til med å sette opp miljøer. Dette scenariet gjentas bare ofte hvis du er på leietid eller opplever tung churn (1). Det er en ganske tidkrevende prosess som kan ta flere timer om ikke dager (2). Nye teammedlemmer kan ikke gjøre noe nyttig uten miljøer, så det er helt klart en avhengighet og forsinkelse (3). Jeg vil ikke si at prosessen er utsatt for feil (4), så er det fortsatt presserende (5)? Jeg lener meg mot ja, men jeg vil fortsatt prioritere integrering og funksjonstesting først.

Det er ikke noe som heter overautomatisering. Hvis du hadde ubegrensede ressurser, ville du automatisere alt mulig. Når det er sagt, du kan ikke oppnå total testautomatisering. Noen ganger kan du dele oppgaver i mindre segmenter og automatisere oppdateringer. Noen ganger bør du bare dokumentere prosessen i detalj og utføre den manuelt.

CI / CD fallgruve nr. 2: Forvirrende kontinuerlig distribusjon for kontinuerlig levering

Kontinuerlig distribusjon er konseptet at enhver endring i kodebasen vil bli distribuert nesten umiddelbart til produksjon hvis resultatene av rørledningen er vellykkede. Dette er skremmende for de fleste organisasjoner fordi raske produktendringer kan skremme brukere.

Bedrifter mener at hvis de ikke praktiserer kontinuerlig distribusjon, gjør de ikke CD. De klarer ikke å skille mellom kontinuerlig distribusjon og kontinuerlig levering.

Kontinuerlig levering er konseptet at hver endring i kodebasen går gjennom rørledningen til det punktet den distribueres til miljøer uten produksjon. Teamet finner og adresserer problemer umiddelbart, ikke senere når de planlegger å frigjøre kodebasen.

Kodebasen er alltid på et kvalitetsnivå som er trygt for utgivelse. Når å frigjøre kodebasen til produksjon er en forretningsbeslutning.

Mens kontinuerlig distribusjon forstyrrer de fleste organisasjoner, gjenspeiles kontinuerlig levering av dem. Kontinuerlig levering gir dem kontroll over produktutrulling, funksjonalitet og risikofaktorer. Det er tid for alfatesting, for betakunder, for tidlig adoptere og så videre.

CI / CD fallgruve nr. 3: Mangel på meningsfulle dashbord og beregninger

I CI / CD-implementeringer kan scrumteamet lage et dashbord før medlemmene vet hva de trenger å spore. Som et resultat blir teamet offer for en logisk feilslutning: "Dette er beregningene vi har, så de må være viktige." I stedet må du utføre en progressiv vurdering før designe et dashbord.

Ulike medlemmer av en IT-organisasjon, og til og med forskjellige medlemmer av et scrumteam, har forskjellige prioriteringer. For eksempel elsker folk i et nettverksoperasjonssenter (NOC) røde, gule og grønne indikatorer. Slike trafikklysdashboards gjør det mulig for NOC-ansatte å skille mellom problemer uten å lese tett tekst eller å skattlegge deres analytiske evner. Trafikklys bidrar til å gjøre hundrevis av servere håndterbare.

Du kan også bli fristet til å bruke et trafikklysdashboard for CI / CD. Grønt, vi er på rett spor. Gul, vi er på sporet, men vi har en plan for å løse det. Rødt, vi er på sporet og trenger sannsynligvis å endre målene våre.

Det dashbordet er sannsynligvis nyttig for en scrummester, men hva med utviklingsdirektør eller CTO? Hvis et scrumteam har 350 timers arbeid foran en to-ukers sprint, og dets 10 medlemmer er ansvarlige for 35 timer hver, vil de motta et tilsvarende antall historiepoeng. Øverste ledelse kan være mindre interessert i statusen til historiepoeng og mer nysgjerrig på "nedbruddshastigheten": hastigheten på oppgavens fullføring. Bærer teammedlemmer lastene sine? Hvor raskt? Bedres de over tid?

Dessverre kan nedbruddssatser være misvisende hvis de forskjellige interessentene ikke forstår scrumteamets avtalt vaner. Noen lag brenner ned poeng tidlig når de går. Andre venter til nær slutten av sprinten med å brenne ned åpne punkter. Dashbordet bør ta hensyn til det.

Hvis du kan vurdere hvilke data alle vil ha og etablere en standardfortelling for hva dataene betyr, kan du designe et nyttig instrumentbord. Men ikke besett stoffet på bekostning av utseendet. Spør hvordan interessenter vil at det skal se ut. Ville grafer, tekst eller tall være best?

Dette er hensynene som skal undersøkes i en progressiv vurdering. De illustrerer hvor vanskelig det er å lage et nyttig CI / CD-dashbord - og å gjøre alle lykkelige. Altfor ofte kaprer det høylydte teammedlemmet prosessen, og andre føler seg frustrert over at dashbordet bare oppfyller en persons preferanser. Lytt til alle.

CI / CD-fallgruve nr. 4: Manglende koordinering mellom kontinuerlig integrasjon og kontinuerlig levering

Denne fallgruven tar oss tilbake til vår konsensusdefinisjon av devops, som hevder at kontinuerlig integrasjon og kontinuerlig levering er to forskjellige elementer. CI strømmer CD. Å implementere en anstendig kontinuerlig integrasjonsrørledning og et komplett kontinuerlig leveringssystem tar måneder og krever samarbeid. Kvalitetssikring, devops-teamet, ops-ingeniører, scrum-mestere - alt må bidra. Kanskje det tøffeste aspektet ved CI / CD er denne menneskelige faktoren i stedet for noen teknisk utfordring vi har diskutert. Akkurat som du ikke kan programmere et sunt forhold mellom to personer, kan du ikke automatisere samarbeid og kommunikasjon.

For å måle dette koordineringsnivået må du sammenligne CI / CD-prosessen mot de beste i bransjen. Bedrifter som Netflix kan fullføre integrering, testing og levering i løpet av to til tre timer. De etablerte et system som overfører kode fra hånd til hånd uten ubesluttsomhet og diskusjon. Nei, det er ikke 100 prosent automatisert fordi det er umulig med dagens teknologi.

CI / CD fallgruve nr. 5: Balanserer hyppigheten av å kjøre kontinuerlige integrasjonsjobber og ressursutnyttelse

Kontinuerlige integrasjonsjobber skal utløses for hver endring som blir introdusert i koden. Vellykkede jobber tillater endringene å gå gjennom mens feil avviser endringene. Dette oppfordrer utviklere til å sjekke inn mindre biter av kode, og utløse flere bygg på en dag. Imidlertid bruker unødvendige kontinuerlige integrasjonsjobber ressurser, som kaster bort tid og penger.

Fordi denne prosessen innebærer mye ressursutnyttelse (CPU, strøm, tid), bør programvaren deles inn i mindre komponenter for å skape raskere rørledninger. Eller de kontinuerlige integrasjonsjobbene bør utformes for batch-innsjekking som først blir testet lokalt. Målet er å finne en balanse mellom hyppigheten av kontinuerlige integrasjonsjobber og ressursutnyttelsen.

Hold målet i sikte

Når vi graver ned i fallgruvene til CI / CD - komplett med sin esoteriske terminologi - er det lett å miste synet av Hvorfor dette betyr noe. Til slutt er CI / CD viktig fordi den oppfyller forretningsmål.

Teknologiledere vet at kontinuerlig utvikling, hurtigreparasjoner og kvalitetsresultater skaper og beholder kunder. De vet at en mislykket utgivelse innbyr til et bludgeon til App Store-anmeldelser, og det er vanskeligere å gjenvinne høye anmeldelser enn å beholde dem. Devops kan skape en bedre arbeidsopplevelse for teamet ditt, men det er ikke derfor selskaper implementerer devops.

Enkelt sagt, fallgruvene til CI / CD er verdt å se på fordi milliarder dollar står på spill. Selv om jeg ikke foreslår at du legger til en aksjemarkør eller App Store-gjennomgangssporing i CI / CD-dashbordet, ber jeg deg om å holde deg klar over dette. Mye avhenger av detaljene til CI / CD.

Zubin Irani er medstifter og administrerende direktør i cPrime, et fullservicekonsulent som implementerer smidige transformasjoner og leverer smidige løsninger for mer enn 50 Fortune 100-firmaer og mange av Silicon Valley største arbeidsgivere.

New Tech Forum er et sted for å utforske og diskutere ny teknologi i enestående dybde og bredde. Valget er subjektivt, basert på vårt valg av teknologiene vi mener er viktige og av størst interesse for leserne. godtar ikke markedsføringssikkerhet for publisering og forbeholder seg retten til å redigere alt bidratt innhold. Send alle henvendelser til [email protected].

$config[zx-auto] not found$config[zx-overlay] not found