Kontinuerlig integration (CI) og kontinuerlig levering (CD) er en kultur, et sæt driftsprincipper og en samling af fremgangsmåder, der gør det muligt for applikationsudviklingsteams at levere kodeændringer oftere og pålideligt. Implementeringen er også kendt som CI / CD rørledning.
CI / CD er en af de bedste fremgangsmåder, som devops-teams kan implementere. Det er også en smidig metodisk bedste praksis, da det gør det muligt for softwareudviklingsteam at fokusere på at opfylde forretningskrav, kodekvalitet og sikkerhed, fordi implementeringstrinene er automatiserede.
CI / CD defineret
Kontinuerlig integration er en kodningsfilosofi og et sæt praksis, der får udviklingshold til at implementere små ændringer og kontrollere kode til versionskontrol repositories ofte. Da de fleste moderne applikationer kræver udvikling af kode i forskellige platforme og værktøjer, har teamet brug for en mekanisme til at integrere og validere sine ændringer.
Det tekniske mål med CI er at etablere en ensartet og automatiseret måde at opbygge, pakke og teste applikationer på. Med konsekvens i integrationsprocessen på plads er teams mere tilbøjelige til at foretage kodeændringer oftere, hvilket fører til bedre samarbejde og softwarekvalitet.
Kontinuerlig leveringopfanger, hvor kontinuerlig integration slutter. CD automatiserer levering af applikationer til udvalgte infrastrukturmiljøer. De fleste teams arbejder med flere andre miljøer end produktionen, såsom udviklings- og testmiljøer, og CD sikrer, at der er en automatiseret måde at skubbe kodeændringer til dem på.
CI / CD-værktøjer hjælper med at gemme de miljøspecifikke parametre, der skal pakkes med hver levering. CI / CD-automatisering udfører derefter alle nødvendige serviceopkald til webservere, databaser og andre tjenester, der muligvis skal genstartes eller følge andre procedurer, når applikationer implementeres.
Kontinuerlig integration og kontinuerlig levering kræverkontinuerlig testfordi målet er at levere kvalitetsapplikationer og kode til brugerne. Kontinuerlig test implementeres ofte som et sæt automatiseret regression, ydeevne og andre tests, der udføres i CI / CD-pipelinen.
En moden CI / CD devops-praksis har mulighed for at implementere kontinuerlig implementering, hvor applikationsændringer løber gennem CI / CD-pipelinen, og videregående builds distribueres direkte til produktionsmiljøer. Hold, der praktiserer kontinuerlig levering, vælger at implementere til produktion på en daglig eller endda timeplan, selvom kontinuerlig levering ikke altid er optimal til enhver forretningsapplikation.
Relateret video: Sådan leveres kode hurtigere med CI / CD
Hvordan kontinuerlig integration forbedrer samarbejde og kvalitet
Kontinuerlig integration er en udviklingsfilosofi bakket op af procesmekanik og en vis automatisering. Når man praktiserer CI, forpligter udviklere deres kode ofte til versionskontroldatabasen, og de fleste hold har en minimal standard for at begå kode mindst dagligt. Begrundelsen bag dette er, at det er lettere at identificere mangler og andre softwarekvalitetsproblemer på mindre kodedifferentialer snarere end større, der er udviklet over en lang periode. Derudover, når udviklere arbejder på kortere forpligtelsescyklusser, er det mindre sandsynligt, at flere udviklere redigerer den samme kode og kræver en fletning, når de begår.
Hold, der implementerer kontinuerlig integration, starter ofte med versionskontrolkonfiguration og praksisdefinitioner. Selvom indtjekning sker ofte, implementeres funktioner og rettelser på både korte og længere tidsrammer. Udviklingsteam, der praktiserer kontinuerlig integration, bruger forskellige teknikker til at kontrollere, hvilke funktioner og kode der er klar til produktion.
Mange hold bruger har flag, en konfigurationsmekanisme til at slå funktioner og kode til eller fra på kørselstid. Funktioner, der stadig er under udvikling, er pakket med funktionsflag i koden, implementeret sammen med mastergrenen til produktion og slukket, indtil de er klar til brug. Ifølge en nylig undersøgelse rapporterer 63 procent af hold, der bruger funktionsflag, bedre test og software af højere kvalitet. Funktioner til markering af funktioner som CloudBees-udrulning, Optimalt udrulning og LaunchDarkly integreres med CI / CD-værktøjer og aktiverer konfigurationer på funktionsniveau.
En anden teknik til styring af funktioner erversionskontrol forgrening. En forgreningsstrategi som Gitflow er valgt for at definere protokoller over, hvordan ny kode flettes til standardgrene til udvikling, test og produktion. Yderligere funktionsgrene oprettes til dem, der tager længere udviklingscyklusser. Når funktionen er færdig, kan udviklerne derefter flette ændringer fra funktionsgrene til den primære udviklingsgren. Denne tilgang fungerer godt, men det kan blive svært at administrere, hvis der er mange funktioner, der udvikles samtidigt.
Selve byggeprocessen automatiseres derefter ved at pakke al software, database og andre komponenter. For eksempel, hvis du udviklede en Java-applikation, ville CI pakke alle de statiske webserverfiler såsom HTML, CSS og JavaScript sammen med Java-applikationen og eventuelle databasescripts.
CI pakker ikke kun al software og databaskomponenter, men automatiseringen udfører også enhedstest og anden test. Denne test giver feedback til udviklere, at deres kodeændringer ikke bryder nogen eksisterende enhedstest.
De fleste CI / CD-værktøjer lader udviklere starte builds on demand, udløst af kodeforpligtelser i versionskontroldatabasen eller på en defineret tidsplan. Hold skal diskutere den byggeplan, der fungerer bedst for teamets størrelse, antallet af forventede daglige forpligtelser og andre applikationsovervejelser. En bedste praksis for at sikre, at forpligtelser og builds er hurtige, ellers kan det hindre fremskridt for hold, der forsøger at kode hurtigt og begå ofte.
Kontinuerlig test går ud over testautomatisering
Automatiske testrammer hjælper kvalitetssikringsingeniører med at definere, udføre og automatisere forskellige typer test, der kan hjælpe udviklingshold ved, om en softwarebyggelse består eller mislykkes. De inkluderer funktionstest, der er udviklet i slutningen af hver sprint og samlet til en regressionstest for hele applikationen. Disse regressionstest informerer derefter holdet om, hvorvidt en kodeændring mislykkedes i en eller flere af de tests, der er udviklet på tværs af alle funktionelle områder af applikationen, hvor der er testdækning.
En bedste praksis er at aktivere og kræve, at udviklere kører alle eller en delmængde af regressionstest i deres lokale miljøer. Dette trin sikrer, at udviklere kun forpligter kode til versionskontrol, efter at regressionstest videregiver kodeændringerne.
Regressionstest er kun starten. Performance-test, API-test, statisk kodeanalyse, sikkerhedstest og andre testformularer kan også automatiseres. Nøglen er at kunne udløse disse tests enten via kommandolinje, webhook eller webservice, og at de reagerer med succes eller mislykkes statuskoder.
Når test er automatiseret, indebærer kontinuerlig test, at automatiseringen er integreret i CI / CD-pipelinen. Nogle enheds- og funktionstest kan integreres i CI, der markerer problemer før eller under integrationsprocessen. Test, der kræver et fuldt leveringsmiljø såsom ydeevne og sikkerhedstest, integreres ofte i CD og udføres, efter build er leveret til målmiljøer.
CD-pipelinen automatiserer ændringer i flere miljøer
Kontinuerlig levering er den automatisering, der skubber applikationer til leveringsmiljøer. De fleste udviklingsteam har typisk et eller flere udviklings- og testmiljøer, hvor applikationsændringer er iscenesat til test og gennemgang. Et CI / CD-værktøj som Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo eller Travis CI bruges til at automatisere trinene og levere rapportering.
En typisk cd-pipeline har bygge-, test- og implementeringsfaser. Mere sofistikerede rørledninger inkluderer mange af disse trin:
- Henter kode fra versionskontrol og udfører en build.
- Udførelse af alle nødvendige infrastrukturtrin, der automatiseres som kode til at stå op eller nedbryde skyinfrastruktur.
- Flytning af kode til målcomputermiljøet.
- Håndtering af miljøvariabler og konfiguration af dem til målmiljøet.
- At skubbe applikationskomponenter til deres relevante tjenester, såsom webservere, API-tjenester og databasetjenester.
- Udførelse af de nødvendige trin til genstart af tjenester eller opkaldstjenestepunkter, der er nødvendige for nye kodeskub.
- Udførelse af kontinuerlige tests og tilbagevendende miljøer, hvis test mislykkes.
- Tilvejebringelse af logdata og advarsler om leveringsstatus.
Som et eksempel definerer Jenkins-brugere deres rørledninger i en Jenkinsfil, der beskriver forskellige faser, f.eks. Bygge, teste og implementere. Miljøvariabler, valgmuligheder, hemmelige nøgler, certificeringer og andre parametre erklæres i filen og henvises derefter i trin. Indlægssektionen håndterer fejlbetingelser og meddelelser.
Mere sofistikeret CD kan have andre trin, f.eks. Udførelse af datasynkronisering, arkivering af informationsressourcer eller udførelse af program- og biblioteksopdatering. CI / CD-værktøjer understøtter typisk en markedsplads for plug-ins. For eksempel viser Jenkins mere end 1.500 plug-ins, der understøtter integration med tredjepartsplatforme, brugergrænseflade, administration, kildekodeadministration og build management.
Når et CI / CD-værktøj er valgt, skal udviklingsteam sørge for, at alle miljøvariabler er konfigureret uden for applikationen. CI / CD-værktøjer tillader indstilling af disse variabler, maskering af variabler såsom adgangskoder og kontonøgler og konfiguration af dem på tidspunktet for implementeringen til målmiljøet.
CD-værktøjer giver også dashboard og rapporteringsfunktioner. Hvis konstruktioner eller leveringer mislykkes, advarer de udviklere med oplysninger om fejlene. De integreres med versionskontrol og smidige værktøjer, så de kan bruges til at slå op, hvilke kodeændringer og brugerhistorier der udgør en build.
Implementering af CI / CD-rørledninger med Kubernetes og serverløse arkitekturer
Mange hold, der driver CI / CD-rørledninger i skymiljøer, bruger også containere som Docker og orkestrationssystemer som Kubernetes. Beholdere tillader emballage og forsendelsesapplikationer på standard, bærbare måder. Beholdere gør det let at opskalere eller nedbryde miljøer med variabel arbejdsbyrde.
Der er mange tilgange til at bruge containere, infrastruktur som kode og CI / CD-rørledninger sammen. Du kan udforske mulighederne ved at arbejde igennem selvstudier som Kubernetes med Jenkins eller Kubernetes med Azure DevOps.
Serverløse databehandlingsarkitekturer præsenterer en anden vej til implementering og skalering af applikationer. I et serverløst miljø styres infrastrukturen fuldt ud af cloudtjenesteudbyderen, og applikationen bruger ressourcer efter behov baseret på dens konfiguration. På AWS kan serverløse applikationer f.eks. Køre som Lambda-funktioner og implementeringer integreres i en Jenkins CI / CD-pipeline med et plug-in.
CI / CD muliggør hyppigere implementering af kode
For at resumere bygger CI-pakker og tester software og advarer udviklere, hvis deres ændringer mislykkedes nogen enhedstest. CD er den automatisering, der leverer ændringer i infrastrukturen og udfører yderligere test.
CI / CD-rørledninger er designet til virksomheder, der ofte vil forbedre applikationer og kræver en pålidelig leveringsproces. Den ekstra indsats for at standardisere builds, udvikle tests og automatisere implementeringer er fremstillingsprocessen til implementering af kodeændringer. Når det er på plads, giver det holdene mulighed for at fokusere på processen med at forbedre applikationer og mindre på systemdetaljerne for at levere det til computermiljøer.
CI / CD er en devops bedste praksis, fordi den løser fejljusteringen mellem udviklere, der ofte vil skifte ændringer med operationer, der ønsker stabile applikationer. Med automatisering på plads kan udviklere skubbe ændringer oftere. Operationshold ser større stabilitet, fordi miljøer har standardkonfigurationer, der er kontinuerlig test i leveringsprocessen, miljøvariabler er adskilt fra applikationen, og tilbageføringsprocedurer automatiseres.
Virkningen af implementering af CI / CD-rørledninger kan måles som en devops key performance indicator (KPI). KPI'er såsom distributionsfrekvens, ændring af ledetid og gennemsnitlig tid til gendannelse (MTTR) fra en hændelse forbedres ofte, når CI / CD med kontinuerlig test implementeres. CI / CD er dog kun en proces, der kan drive disse forbedringer, og der er andre forudsætninger for at forbedre implementeringsfrekvenser.
At komme i gang med CI / CD kræver, at udviklingshold og operationelle teams samarbejder om teknologier, praksis og prioriteter. Hold har brug for at udvikle konsensus om de rigtige tilgange til deres forretning og teknologier, så når CI / CD er på plads, er holdet ombord med konsekvent at følge praksis.
