Kontinuerlig integrasjon (CI) og kontinuerlig levering (CD) innebærer en kultur, sett med driftsprinsipper og samling av praksis som gjør det mulig for applikasjonsutviklingsteam å levere kodeendringer oftere og mer pålitelig. Implementeringen er også kjent som CI / CD rørledning.
CI / CD er en av de beste metodene for implementering av devops-team. Det er også en smidig metodikk, da det gjør det mulig for programvareutviklingsteam å fokusere på å oppfylle forretningskrav, kodekvalitet og sikkerhet fordi distribusjonstrinnene er automatiserte.
CI / CD definert
Kontinuerlig integrering er en kodingsfilosofi og praksis som driver utviklingsteam til å implementere små endringer og sjekke inn kode til versjonskontrollregister ofte. Fordi de fleste moderne applikasjoner krever utvikling av kode på forskjellige plattformer og verktøy, trenger teamet en mekanisme for å integrere og validere endringene.
Det tekniske målet med CI er å etablere en konsistent og automatisert måte å bygge, pakke og teste applikasjoner på. Med konsistens i integrasjonsprosessen på plass, er det mer sannsynlig at team begår kodeendringer oftere, noe som fører til bedre samarbeid og programvarekvalitet.
Kontinuerlig leveringplukker opp der kontinuerlig integrasjon slutter. CD automatiserer levering av applikasjoner til utvalgte infrastrukturmiljøer. De fleste team jobber med flere miljøer enn produksjonen, for eksempel utviklings- og testmiljøer, og CD sørger for at det er en automatisert måte å overføre kodeendringer til dem.
CI / CD-verktøy hjelper til med å lagre miljøspesifikke parametere som må pakkes med hver levering. CI / CD-automatisering utfører deretter nødvendige tjenesteanrop til webservere, databaser og andre tjenester som kan trenge å starte på nytt eller følge andre prosedyrer når applikasjoner distribueres.
Kontinuerlig integrering og kontinuerlig levering kreverkontinuerlig testingfordi målet er å levere kvalitetsapplikasjoner og kode til brukerne. Kontinuerlig testing implementeres ofte som et sett med automatisert regresjon, ytelse og andre tester som utføres i CI / CD-rørledningen.
En moden CI / CD devops-praksis har muligheten til å implementere kontinuerlig distribusjon der applikasjonsendringer kjøres gjennom CI / CD-rørledningen og passerer builds distribueres direkte til produksjonsmiljøer. Team som praktiserer kontinuerlig levering, velger å distribuere til produksjon på en daglig eller til og med timeplan, selv om kontinuerlig levering ikke alltid er optimal for alle forretningsapplikasjoner.
Relatert video: Hvordan levere kode raskere med CI / CD
Hvordan kontinuerlig integrasjon forbedrer samarbeid og kvalitet
Kontinuerlig integrasjon er en utviklingsfilosofi støttet av prosessmekanikk og litt automatisering. Når du praktiserer CI, forplikter utviklere koden sin til versjonskontrolldatabasen ofte, og de fleste lag har en minimal standard for å begå kode minst daglig. Begrunnelsen bak dette er at det er lettere å identifisere feil og andre problemer med programvarekvalitet på mindre kodedifferensialer i stedet for større utviklet over en lang periode. I tillegg, når utviklere jobber med kortere sykluser, er det mindre sannsynlig at flere utviklere redigerer den samme koden og krever en sammenslåing når de forplikter seg.
Team som implementerer kontinuerlig integrasjon starter ofte med konfigurasjon av versjonskontroll og definisjoner av praksis. Selv om innsjekking av kode gjøres ofte, implementeres funksjoner og reparasjoner på både korte og lengre tidsrammer. Utviklingsteam som praktiserer kontinuerlig integrasjon, bruker forskjellige teknikker for å kontrollere hvilke funksjoner og kode som er klare for produksjon.
Mange lag bruker har flagg, en konfigurasjonsmekanisme for å slå funksjoner og kode på eller av på kjøretid. Funksjoner som fremdeles er under utvikling er pakket med funksjonsflagg i koden, distribuert med hovedgrenen til produksjon, og slått av til de er klare til bruk. I følge en fersk undersøkelse rapporterer 63 prosent av teamene som bruker funksjonsflagg, bedre testing og programvare av høyere kvalitet. Funksjonsflaggingsverktøy som CloudBees-utrulling, Optimalt utrulling og LaunchDarkly integreres med CI / CD-verktøy og aktiverer konfigurasjon på funksjonsnivå.
En annen teknikk for å administrere funksjoner erversjonskontroll forgrening. En forgreningsstrategi som Gitflow er valgt for å definere protokoller over hvordan ny kode slås sammen til standardgrener for utvikling, testing og produksjon. Ytterligere funksjonsgrener blir opprettet for de som vil ta lengre utviklingssykluser. Når funksjonen er fullført, kan utviklerne deretter slå sammen endringene fra funksjonsgrenene til den primære utviklingsgrenen. Denne tilnærmingen fungerer bra, men det kan bli vanskelig å administrere hvis det er mange funksjoner som utvikles samtidig.
Selve byggeprosessen blir deretter automatisert ved å pakke all programvare, database og andre komponenter. For eksempel, hvis du utviklet et Java-program, ville CI pakke alle de statiske webserverfilene som HTML, CSS og JavaScript sammen med Java-applikasjonen og eventuelle databaseskript.
CI pakker ikke bare all programvare og databaskomponenter, men automatiseringen vil også utføre enhetstester og andre tester. Denne testen gir tilbakemeldinger til utviklere om at kodeendringene deres ikke brøt noen eksisterende enhetstester.
De fleste CI / CD-verktøy lar utviklere starte builds on demand, utløst av kodeforpliktelser i versjonskontrolldatabasen, eller på en definert tidsplan. Teamene må diskutere byggeplanen som fungerer best for størrelsen på teamet, antall forventede daglige forpliktelser og andre hensyn til applikasjonen. En god praksis for å sikre at forpliktelser og bygg er raske, ellers kan det hindre fremgangen til team som prøver å kode raskt og forplikte seg ofte.
Kontinuerlig testing går utover testautomatisering
Automatiserte testrammer hjelper kvalitetssikringsingeniører med å definere, utføre og automatisere forskjellige typer tester som kan hjelpe utviklingsteam til å vite om en programvarebygging består eller mislykkes. De inkluderer funksjonalitetstester som er utviklet på slutten av hver sprint og samlet til en Regresjonstest for hele søknaden. Disse regresjonstestene informerer deretter teamet om en kodeendring mislyktes i en eller flere av testene som ble utviklet på tvers av alle funksjonelle områder av applikasjonen der det er testdekning.
En god praksis er å aktivere og kreve at utviklere kjører alle eller en delmengde regresjonstester i sine lokale miljøer. Dette trinnet sikrer at utviklere bare forplikter kode til versjonskontroll etter at regresjonstester har gitt kodendringene videre.
Regresjonstester er bare starten. Ytelsestesting, API-testing, analyse av statisk kode, sikkerhetstesting og andre testskjemaer kan også automatiseres. Nøkkelen er å kunne utløse disse testene enten via kommandolinje, webhook eller webtjeneste, og at de svarer med suksess eller mislykkes statuskoder.
Når testingen er automatisert, innebærer kontinuerlig testing at automatiseringen er integrert i CI / CD-rørledningen. Noen enhets- og funksjonstester kan integreres i CI som flagger problemer før eller under integrasjonsprosessen. Tester som krever et fullstendig leveringsmiljø, som ytelse og sikkerhetstesting, blir ofte integrert i CD og utført etter at build er levert til målmiljøer.
CD-rørledningen automatiserer endringer i flere miljøer
Kontinuerlig levering er automatiseringen som skyver applikasjoner til leveringsmiljøer. De fleste utviklingsteam har vanligvis ett eller flere utviklings- og testmiljøer der applikasjonsendringer er iscenesatt for testing og gjennomgang. Et CI / CD-verktøy som Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo eller Travis CI brukes til å automatisere trinnene og levere rapportering.
En typisk CD-rørledning har bygg, test og distribusjonsstadier. Mer sofistikerte rørledninger inkluderer mange av disse trinnene:
- Henter kode fra versjonskontroll og utfører en build.
- Utføre nødvendige infrastrukturtrinn som automatiseres som kode for å stå opp eller rive ned skyinfrastruktur.
- Å flytte kode til måldatamiljøet.
- Administrere miljøvariablene og konfigurere dem for målmiljøet.
- Å skyve applikasjonskomponenter til passende tjenester, for eksempel webservere, API-tjenester og databasetjenester.
- Utføre trinnene som kreves for å starte tjenester på nytt eller ringe endepunkter for tjenesten som er nødvendige for nye kodetrykk.
- Utføre kontinuerlige tester og tilbakeslagsmiljøer hvis tester mislykkes.
- Tilby loggdata og varsler om leveransens tilstand.
Som et eksempel definerer Jenkins-brukere sine rørledninger i en Jenkinsfil som beskriver forskjellige stadier, for eksempel bygge, teste og distribuere. Miljøvariabler, alternativer, hemmelige nøkler, sertifiseringer og andre parametere blir deklarert i filen og deretter referert til i trinn. Innleggsseksjonen håndterer feilforhold og varsler.
Mer sofistikert CD kan ha andre trinn som å utføre datasynkronisering, arkivere informasjonsressurser eller utføre program- og biblioteksoppdatering. CI / CD-verktøy støtter vanligvis en markedsplass for plugin-moduler. For eksempel viser Jenkins mer enn 1500 plugin-moduler som støtter integrasjon med tredjepartsplattformer, brukergrensesnitt, administrasjon, kildekodeadministrasjon og bygningsadministrasjon.
Når et CI / CD-verktøy er valgt, må utviklingsteam sørge for at alle miljøvariablene er konfigurert utenfor applikasjonen. CI / CD-verktøy tillater innstilling av disse variablene, maskering av variabler som passord og kontonøkler, og konfigurering av dem på tidspunktet for distribusjon for målmiljøet.
CD-verktøy gir også dashbord og rapporteringsfunksjoner. Hvis bygg eller leveranser mislykkes, varsler de utviklere med informasjon om feilene. De integreres med versjonskontroll og smidige verktøy, slik at de kan brukes til å slå opp hva kodeendringer og brukerhistorier utgjorde en build.
Implementering av CI / CD-rørledninger med Kubernetes og serverløse arkitekturer
Mange team som driver CI / CD-rørledninger i skymiljøer, bruker også containere som Docker og orkestrasjonssystemer som Kubernetes. Beholdere tillater emballasje og forsendelsesapplikasjoner på standard, bærbare måter. Beholdere gjør det enkelt å skalere opp eller rive miljøer som har variabel arbeidsbelastning.
Det er mange tilnærminger til bruk av containere, infrastruktur som kode og CI / CD-rørledninger sammen. Du kan utforske alternativene ved å arbeide gjennom opplæringsprogrammer som Kubernetes med Jenkins eller Kubernetes med Azure DevOps.
Serverløse databehandlingsarkitekturer presenterer en annen vei for distribusjon og skalering av applikasjoner. I et serverfritt miljø administreres infrastrukturen fullstendig av skytjenesteleverandøren, og applikasjonen bruker ressurser etter behov basert på konfigurasjonen. På AWS kan for eksempel serverløse applikasjoner kjøres som Lambda-funksjoner og distribusjoner integreres i en Jenkins CI / CD-rørledning med en plug-in.
CI / CD muliggjør hyppigere distribusjon av koder
For å oppsummere, bygger CI-pakker og tester programvare og varsler utviklere hvis endringene deres mislyktes i enhetstester. CD er automatiseringen som leverer endringer i infrastrukturen og utfører ytterligere tester.
CI / CD-rørledninger er designet for bedrifter som ofte vil forbedre applikasjoner og krever en pålitelig leveringsprosess. Den ekstra innsatsen for å standardisere bygg, utvikle tester og automatisere distribusjoner er produksjonsprosessen for distribusjon av kodeendringer. Når det er på plass, gjør det teamene i stand til å fokusere på prosessen med å forbedre applikasjoner og mindre på systemdetaljene for å levere det til databehandlingsmiljøer.
CI / CD er en devops beste praksis fordi den adresserer feiljusteringen mellom utviklere som ønsker å presse endringer ofte, med operasjoner som ønsker stabile applikasjoner. Med automatisering på plass kan utviklere presse endringer oftere. Operasjonsteamene ser større stabilitet fordi miljøer har standardkonfigurasjoner, det er kontinuerlig testing i leveringsprosessen, miljøvariabler er skilt fra applikasjonen, og tilbakeføringsprosedyrer blir automatisert.
Effekten av implementering av CI / CD-rørledninger kan måles som en devops key performance indicator (KPI). KPI-er som distribusjonsfrekvens, endringstid og gjennomsnittlig tid til gjenoppretting (MTTR) fra en hendelse forbedres ofte når CI / CD med kontinuerlig testing implementeres. Imidlertid er CI / CD bare en prosess som kan drive disse forbedringene, og det er andre forutsetninger for å forbedre distribusjonsfrekvensen.
Å komme i gang med CI / CD krever at utviklingsteam og operasjonelle team samarbeider om teknologier, praksis og prioriteringer. Teamene må utvikle konsensus om de riktige tilnærmingene for sin virksomhet og teknologi, slik at når CI / CD er på plass, er teamet ombord og følger konsekvent praksis.