Devops kan være et af de mest uhyggelige udtryk i softwareudvikling, men de fleste af os er enige om, at fem aktiviteter gør devops til, hvad det er: kontinuerlig integration, kontinuerlig levering, skyinfrastruktur, testautomatisering og konfigurationsstyring. Hvis du gør disse fem ting, gør du devops. Det er klart, at alle fem er vigtige for at få det rigtige, men alt for let til at gå galt. Især kontinuerlig integration og kontinuerlig levering (CI / CD) kan være de sværeste devops bevæger sig for at mestre.
Kontinuerlig integration (CI) er en proces, hvor udviklere og testere i fællesskab validerer ny kode. Traditionelt skrev udviklere kode og integrerede den en gang om måneden til test. Det var ineffektivt - en fejl i kode fra fire uger siden kunne tvinge udviklerne til at revidere kode skrevet for en uge siden. For at løse dette problem afhænger CI af automatisering for at integrere og teste kode kontinuerligt. Scrum-teams, der bruger CI, begiver kode i det mindste dagligt, mens et flertal af dem begår kode for hver ændring, der indføres.
Kontinuerlig levering (CD) er processen med kontinuerligt at skabe frigivelige artefakter. Nogle virksomheder frigiver til brugerne en gang eller endda flere gange om dagen, mens andre frigiver softwaren i et langsommere tempo af markedsmæssige årsager. Uanset hvad testes evnen til at frigive kontinuerligt. Sammenhængende implementering er mulig takket være skymiljøer. Servere er konfigureret således, at du kan implementere til produktion uden at lukke ned og manuelt opdatere servere.
CI / CD er således en proces til kontinuerlig udvikling, test og levering af ny kode. Nogle virksomheder som Facebook og Netflix bruger CI / CD til at gennemføre 10 eller flere udgivelser om ugen. Andre virksomheder kæmper for at nå det tempo, fordi de giver efter for en eller flere af fem faldgruber, som jeg vil diskutere næste gang.
CI / CD faldgrube nr. 1: Automatisering af de forkerte processer først
Denne fælde har tendens til at ramme organisationer, der skifter fra udvikling af vandfald til devops. Nye organisationer har fordelen ved at implementere CI / CD fra bunden. Eksisterende virksomheder skal rejse gradvist fra manuel til stærkt automatiseret udvikling. Den fulde overgang kan tage flere måneder, hvilket betyder, at du skal være iterativ i, hvordan du anvender CI / CD.
Når du spørger, "Skal dette automatiseres nu?" løb gennem følgende tjekliste:
- Hvor ofte gentages processen eller scenariet?
- Hvor lang er processen?
- Hvilke personer og ressourceafhængigheder er involveret i processen? Forårsager de forsinkelser i CI / CD?
- Er processen udsat for fejl, hvis den ikke er automatiseret?
- Hvad haster det med at få processen automatiseret?
Ved hjælp af denne tjekliste kan du prioritere trinene i en CI / CD-implementering. Først og fremmest automatiserer processen til kompilering af kode. Ideelt set integrerer du kode flere gange om dagen (1). Manuelt tager processen et par minutter til et par timer (2). Det stopper output, indtil compileren er færdig med opgaven (3). Det er også modtageligt for menneskelige fejl (4), og fordi CI / CD er en rørdrøm uden automatiseret integration, er det presserende (5).
Vi kan køre den samme tjekliste ved test. Når du skifter til CI / CD, undrer du dig måske over: Skal vi automatisere funktionstest eller UI-test først? Begge gentages mindst en gang om dagen (1). Begge kan tage to til tre timer for en mellemstor applikation (2). Men de involverer flere afhængigheder (3). Hvis du automatiserer funktionstest, behøver du muligvis ikke at opdatere automatiseringsscriptet så ofte. Brugergrænsefladen ændres derimod ofte og kræver derfor hyppige scriptændringer. Selv om begge er fejlbehæftede (4), bør du prioritere funktionstestning før UI-test for at udnytte dine ressourcer bedst muligt (5).
Lad os gøre dette endnu en gang med processen med at oprette miljøer. Dette scenarie gentages kun hyppigt, hvis du er på ansættelsesforløb eller oplever tung churn (1). Det er en ret tidskrævende proces, der kan tage flere timer, hvis ikke dage (2). Nye teammedlemmer kan ikke gøre noget nyttigt uden miljøer, så der er klart en afhængighed og forsinkelse (3). Jeg vil ikke sige, at processen er udsat for fejl (4), så er det stadig presserende (5)? Jeg læner mig mod ja, men jeg vil stadig prioritere integration og funktionstest først.
Der er ikke sådan noget som overautomatisering. Hvis du havde ubegrænsede ressourcer, ville du automatisere alt muligt. Når det er sagt, dig kan ikke opnå total testautomatisering. Nogle gange kan du opdele opgaver i mindre segmenter og automatisere patches. Nogle gange skal du blot dokumentere processen i detaljer og udføre den manuelt.
CI / CD faldgrube nr. 2: Forvirrende kontinuerlig implementering til kontinuerlig levering
Kontinuerlig implementering er konceptet, at enhver ændring foretaget i kodebasen vil blive implementeret næsten øjeblikkeligt til produktion, hvis resultaterne af rørledningen er vellykkede. Dette er skræmmende for de fleste organisationer, fordi hurtige produktændringer kan skræmme brugere væk.
Virksomheder mener, at hvis de ikke praktiserer kontinuerlig implementering, laver de ikke cd. De skelner ikke mellem kontinuerlig implementering og kontinuerlig levering.
Kontinuerlig levering er konceptet, at enhver ændring af kodebasen går gennem rørledningen op til det sted, hvor den implementeres til ikke-produktionsmiljøer. Holdet finder og løser problemer med det samme, ikke senere når de planlægger at frigive kodebasen.
Kodebasen er altid på et kvalitetsniveau, der er sikkert for frigivelse. Hvornår at frigive kodebasen til produktion er en forretningsbeslutning.
Mens kontinuerlig implementering forstyrrer de fleste organisationer, resonerer kontinuerlig levering med dem. Kontinuerlig levering giver dem kontrol over produktudrulning, funktionalitet og risikofaktorer. Der er tid til alfatest, for betakunder, for tidlige adoptere osv.
CI / CD faldgrube nr. 3: Mangel på meningsfulde dashboards og metrics
I CI / CD-implementeringer kan scrumteamet oprette et dashboard, før medlemmerne ved, hvad de har brug for at spore. Som et resultat falder holdet på en logisk fejlslutning: "Dette er de målinger, vi har, så de skal være vigtige." Udfør i stedet en progressiv vurdering Før designe et dashboard.
Forskellige medlemmer af en it-organisation og endda forskellige medlemmer af et scrumteam har forskellige prioriteter. For eksempel elsker folk i et netværksdriftscenter (NOC) røde, gule og grønne indikatorer. Sådanne trafiklysdashboards giver NOC-medarbejdere mulighed for at skelne mellem problemer uden at læse tæt tekst eller beskatte deres analytiske evner. Trafiklys hjælper med at gøre hundredvis af servere håndterbare.
Du kan blive fristet til også at bruge et trafiklysdashboard til CI / CD. Grøn, vi er på rette spor. Gul, vi er ude af sporet, men vi har en plan om at tackle det. Rød, vi er på sporet og er sandsynligvis nødt til at ændre vores mål.
Dette instrumentbræt er sandsynligvis nyttigt for en scrummaster, men hvad med udviklingschefen eller CTO? Hvis et scrum-team har 350 timers arbejde fremad i en to-ugers sprint, og dets 10 medlemmer er ansvarlige for 35 timer hver, ville de modtage et tilsvarende antal historiepoints. Øverste ledelse er måske mindre interesseret i status for historiepunkter og mere nysgerrig efter "nedbrud" -hastigheden: hastigheden på opgavens afslutning. Bærer holdmedlemmer deres byrder? Hvor hurtigt? Forbedres de over tid?
Desværre kan nedbrændingsrater være vildledende, hvis de forskellige interessenter ikke forstår scrumteamets aftalte vaner. Nogle hold brænder point tidligt, når de går. Andre venter til nær slutningen af sprinten med at brænde åbne punkter ned. Dashboardet skal tage det i betragtning.
Hvis du kan vurdere, hvilke data alle ønsker og etablere en standardfortælling for, hvad disse data betyder, kan du designe et nyttigt dashboard. Men vær ikke besat af stof på bekostning af udseende. Spørg, hvordan interessenter vil have det til at se ud. Ville grafer, tekst eller tal være bedst?
Dette er de overvejelser, der skal undersøges i en progressiv vurdering. De illustrerer, hvor vanskeligt det er at lave et nyttigt CI / CD-dashboard - og at gøre alle glade. Alt for ofte kaprer det mest høje holdmedlem processen, og andre føler sig frustrerede over, at instrumentbrættet kun opfylder en persons præferencer. Lyt til alle.
CI / CD faldgrube nr. 4: Manglende koordinering mellem kontinuerlig integration og kontinuerlig levering
Denne faldgrube fører os tilbage til vores konsensusdefinition af devops, hvilket hævder, at kontinuerlig integration og kontinuerlig levering er to forskellige ting. CI feeds CD. Implementering af en anstændig kontinuerlig integrationspipeline og et komplet kontinuerligt leveringssystem tager måneder og kræver samarbejde. Kvalitetssikring, devops-teamet, ops-ingeniører, scrum-mestre - alt skal bidrage. Måske er det hårdeste aspekt af CI / CD denne menneskelige faktor snarere end nogen teknisk udfordring, vi har diskuteret. Ligesom du ikke kan programmere et sundt forhold mellem to personer, kan du ikke automatisere samarbejde og kommunikation.
For at måle dette niveau af koordination skal du benchmark din CI / CD-proces mod de bedste i branchen. Virksomheder som Netflix kan gennemføre integration, test og levering i løbet af to til tre timer. De etablerede et system, der sender kode fra hånd til hånd uden ubeslutsomhed og diskussion. Nej, det er ikke 100 procent automatiseret, fordi det er umuligt med den nuværende teknologi.
CI / CD faldgrube nr. 5: Balancerer hyppigheden af løbende integrationsjob og ressourceudnyttelse
Kontinuerlige integrationsjob antages at blive udløst for hver ændring, der introduceres i koden. Succesrige job tillader ændringer at gå igennem, mens fejl afviser ændringerne. Dette tilskynder udviklere til at kontrollere mindre klumper af kode, hvilket udløser flere builds på en dag. Imidlertid forbruger unødvendige kontinuerlige integrationsjob ressourcer, som spilder tid og penge.
Da denne proces involverer en masse ressourceudnyttelse (CPU, strøm, tid), bør softwaren opdeles i mindre komponenter for at skabe hurtigere kørende rørledninger. Eller de kontinuerlige integrationsjobs skal designes til batchcheck, der først testes lokalt. Målet er at finde en balance mellem hyppigheden af løbende integrationsjob og ressourceudnyttelsen.
Hold målet i sikte
Når vi graver ned i faldgruberne ved CI / CD - komplet med al dens esoteriske terminologi - er det let at miste synet af hvorfor dette betyder noget. I sidste ende er CI / CD afgørende, fordi den opfylder forretningsmål.
Teknologiledere ved, at kontinuerlig udvikling, hurtige rettelser og kvalitetsresultater skaber og fastholder kunder. De ved, at en mislykket frigivelse inviterer et bludgeon til App Store-anmeldelser, og det er sværere at genvinde høje anmeldelser end at beholde dem. Devops kan skabe en bedre arbejdsoplevelse for dit team, men det er ikke derfor, virksomheder implementerer devops.
Kort sagt, faldgruberne ved CI / CD er værd at gennemgå, fordi milliarder dollars står på spil. Selv om jeg ikke foreslår, at du tilføjer en stock ticker eller App Store review tracker til dit CI / CD dashboard, opfordrer jeg dig til at holde dig opmærksom på dette. Meget afhænger af detaljerne i CI / CD.
Zubin Irani er medstifter og administrerende direktør for cPrime, en fullservicekonsulent, der implementerer agile transformationer og leverer smidige løsninger til mere end 50 Fortune 100-firmaer og mange af Silicon Valley's største arbejdsgivere.
New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle forespørgsler til [email protected].
