CI/CD Pipeline: Lær med eksempel
Hva er en CI/CD-pipeline?
En CI/CD-pipeline automatiserer prosessen med programvarelevering. Den bygger kode, kjører tester og hjelper deg med å trygt distribuere en ny versjon av programvaren. CI/CD-pipeline reduserer manuelle feil, gir tilbakemelding til utviklere og tillater raske produktgjentakelser.
CI/CD-pipeline introduserer automatisering og kontinuerlig overvåking gjennom hele livssyklusen til et programvareprodukt. Det involverer fra integrerings- og testfasen til levering og distribusjon. Disse tilknyttede praksisene refereres til som CI/CD-rørledning.
Hva er kontinuerlig integrasjon, kontinuerlig levering og kontinuerlig distribusjon?
- Kontinuerlig integrasjon er en programvareutviklingsmetode der medlemmer av teamet kan integrere arbeidet sitt minst en gang om dagen. I denne metoden kontrolleres hver integrasjon av en automatisert build for å søke etter feilen.
- Kontinuerlig levering er en programvareutviklingsmetode der et team utvikler programvareprodukter i en kort syklus. Det sikrer at programvare enkelt kan utgis når som helst.
- Kontinuerlig utplassering er en programvareutviklingsprosess der produktfunksjonaliteter leveres ved hjelp av automatisk distribusjon. Det hjelper testere å validere om kodebaseendringene er riktige, og den er stabil eller ikke.
Stadier av en CI/CD-rørledning
En CI/CD-pipeline er en kjørbar spesifikasjon av trinnene som enhver utvikler bør utføre for å levere en ny versjon av programvare. Feil i hvert trinn utløser et varsel via e-post, Slack, eller andre kommunikasjonsplattformer. Det gjør det mulig for ansvarlige utviklere å vite om de viktige problemene.
Her er de viktige stadiene i CI/CD-pipeline:
Kildestadiet
I kildestadiet utløses CI/CD-pipeline av et kodelager. Enhver endring i programmet utløser en melding til CI/CD-verktøyet som kjører en tilsvarende pipeline. Andre vanlige utløsere inkluderer brukerinitierte arbeidsflyter, automatiserte tidsplaner og resultatene av andre rørledninger.
Byggescenen
Dette er den andre fasen av CI/CD Pipeline der du slår sammen kildekoden og dens avhengigheter. Det gjøres hovedsakelig for å bygge en kjørbar forekomst av programvare som du potensielt kan sende til sluttbrukeren.
Programmer som er skrevet på språk som C++, JavaSpråket , C eller Go bør kompileres. På den annen side, JavaScript, Python, og Ruby-programmer kan fungere uten byggestadiet.
Unnlatelse av å bestå byggestadiet betyr at det er en grunnleggende prosjektfeilkonfigurasjon, så det er bedre at du tar opp et slikt problem umiddelbart.
Teststadiet
Teststadiet inkluderer utførelse av automatiserte tester for å validere riktigheten av koden og oppførselen til programvaren. Dette stadiet forhindrer lett reproduserbare feil i å nå klientene. Det er utviklernes ansvar å skrive automatiserte tester.
Distribuer scenen
Dette er den siste fasen der produktet ditt publiseres. Når bygningen har gått gjennom alle nødvendige testscenarioer, er den klar til å distribueres til live server.
Eksempel på CI/CD Pipeline
Her er et eksempel på CI/CD-pipeline:
- Kildekodekontroll: Vertskode på GitHub som et privat depot. Dette vil hjelpe deg med å integrere applikasjonen din med viktige tjenester og programvare.
- Kontinuerlig integrering: Bruk kontinuerlig integrasjon og leveringsplattform CircleCI og begå hver kode. Når endringene varsler, vil dette verktøyet trekke koden som er tilgjengelig i GitHub og behandle for å bygge og kjøre testen.
- Distribuer kode til UAT: Konfigurer CircleCI for å distribuere koden din til AWS UAT-server.
- Distribuer til produksjon: Du må gjenbruke kontinuerlige integrasjonstrinn for å distribuere kode til UAT.
Beste praksis for CI/CD-pipeline
Her er en CI/CD-pipeline beste praksis:
- Skriv opp den nåværende utviklingsprosessen, derfor kan du kjenne prosedyrene som må endres og en som enkelt kan automatiseres.
- Start med et lite bevis på prosjektet før du går videre og fullfør hele utviklingsprosessen på en gang.
- Sett opp en pipeline med mer enn ett trinn der raske grunnleggende tester kjøres først.
- Start hver arbeidsflyt fra det samme, rene og isolerte miljøet.
- Kjør åpen kildekode-verktøy som dekker alt fra kodestil til sikkerhetsskanning.
- Sett opp en bedre kodehub for kontinuerlig å sjekke kvaliteten på koden din ved å kjøre standardsettet med tester mot hver gren.
- Peer-kode gjennomgår hver pull-forespørsel for å løse et problem på en samarbeidsmåte.
- Du må definere suksessberegninger før du starter overgangen til CD-automatisering. Dette vil hjelpe deg til konsekvent å analysere programvaren din, og utvikling av fremgang hjelper deg med å avgrense der det er nødvendig.
Fordeler med CI/CD-rørledninger
Her er fordelene/fordelene med CI/CD Pipeline:
- Bygg og testing kan enkelt utføres manuelt.
- Det kan forbedre konsistensen og kvaliteten på koden.
- Forbedrer fleksibiliteten og har muligheten til å sende nye funksjoner.
- CI/CD pipeline kan strømlinjeforme kommunikasjonen.
- Det kan automatisere prosessen med programvarelevering.
- Hjelper deg å oppnå raskere tilbakemeldinger fra kunder.
- CI/CD-pipeline hjelper deg med å øke produktets synlighet.
- Den lar deg fjerne manuelle feil.
- Reduserer kostnader og arbeidskraft.
- CI/CD-pipelines kan gjøre livssyklusen for programvareutvikling raskere.
- Den har automatisert pipeline-distribusjon.
- En CD-pipeline gir en rask tilbakemeldingssløyfe fra utvikler til klient.
- Forbedrer kommunikasjonen mellom ansatte i organisasjonen.
- Det gjør det mulig for utviklere å vite hvilke endringer i bygget som kan henvende seg til meglerhuset og unngå dem i fremtiden.
- De automatiserte testene, sammen med få manuelle testkjøringer, hjelper til med å fikse eventuelle problemer som kan oppstå.
Viktige CI/CD-verktøy
Her er de viktige CI/CD-verktøyene:
1) Jenkins
Jenkins er en åpen kildekode Continuous Integration-server som hjelper til med å oppnå den kontinuerlige integreringsprosessen (og ikke bare) på en automatisert måte. Jenkins er gratis og er helt skrevet inn Java. Jenkins er et mye brukt program over hele verden som har rundt 300 XNUMX installasjoner og vokser dag for dag.
Egenskaper:
- Jenkin vil bygge og teste kode mange ganger i løpet av dagen.
- Automatisert bygge- og testprosess, sparer timing og reduserer defekter.
- Koden distribueres etter hver vellykket bygg og test.
- Utviklingssyklusen er rask.
Link: https://www.jenkins.io/download/
2) Bamboo
Bamboo er en kontinuerlig integrasjonsbyggeserver som utfører – automatisk bygg, test og utgivelser på ett enkelt sted. Det fungerer sømløst med JIRA-programvare og Bitbucket.
Egenskaper:
- Kjør parallelle batch-tester
- Setter opp Bamboo er ganske enkelt
- Per-miljø tillatelser funksjonen lar utviklere og QA distribuere til sine miljøer
- Innebygd Git-grening og arbeidsflyter. Den slår automatisk sammen grenene.
Link: https://www.atlassian.com/software/bamboo
3) CircleCi
CircleCi er et fleksibelt CI-verktøy som kjører i alle miljøer som en mobilapp på tvers av plattformer, Python API-server, eller Docker-klynge. Dette verktøyet reduserer feil og forbedrer kvaliteten på applikasjonen.
Egenskaper:
- Lar deg velge Byggmiljø
- Støtter mange språk inkludert C++, JavaSkript, NET, PHP, Python, og Ruby
- Støtte for Docker lar deg konfigurere et tilpasset miljø.
- Avbryt automatisk alle bygg i kø eller kjører når et nyere bygg utløses.
Link: https://circleci.com/
Hvorfor er CI/CD-rørledningen viktig for IT-ledere?
- CI/CD-pipeline kan forbedre påliteligheten.
- Det gjør IT-teamet mer attraktivt for utviklere.
- CI/CD-pipeline hjelper IT-ledere med å hente kode fra versjonskontroll og utføre programvarebygging.
- Hjelper med å flytte kode til måldatabehandlingsmiljøet.
- Gjør det mulig for prosjektledere å enkelt administrere miljøvariabler og konfigurere for målmiljøet.
- Prosjektledere kan publisere push-applikasjonskomponenter til tjenester som webtjenester, databasetjenester, API-tjenester osv.
- Oppgi loggdata og varsler om leveringstilstand.
- Det gjør det mulig for programmerere å verifisere kodeendringer før de går videre, noe som reduserer sjansene for at defekter havner i produksjonen.
Ci/CD Pipeline KPI
- Syklus eller distribusjonstid: Syklustid er tiden det tar å gå fra byggestadiet til produksjon. Du kan få gjennomsnittlig livssyklustid ved å måle fasene i utviklingsprosessen. Denne beregningen vil gi innsikt i flaskehalser i prosessen din og den generelle hastigheten på utviklingstiden.
- Utviklingsfrekvens: Utviklingsfrekvens lar deg analysere flaskehalser du finner under automatisering. De hyppigere mindre utgivelsene reduserer risikoen for defekter og fikser dem når de oppdages. En slik beregning er et samlet mål på teamets effektivitet.
- Endre ledetid: Den måler starttiden for utviklingsfasen til utrulling. Denne beregningen er en indikator på hele utviklingsprosessen og hvor godt teamet jobber sammen.
- Endre feilfrekvens: Den fokuserer på antall ganger utviklingen lykkes kontra antall ganger den mislykkes.
- MTTR vs. MTTF: MTTR (Mean Time to Recovery) er tiden som kreves av teamet ditt for å komme seg etter feil. MTTF (Mean Time to Failure) måler tiden mellom reparasjoner og utfall. Disse beregningene er en refleksjon av teamets evne til å svare og fikse problemer.
Sammendrag
- En CI/CD-pipeline automatiserer prosessen med programvarelevering.
- CI/CD-pipeline introduserer automatisering og kontinuerlig overvåking gjennom hele livssyklusen til et programvareprodukt.
- Kontinuerlig integrasjon er en programvareutviklingsmetode der medlemmer av teamet kan integrere arbeidet sitt minst en gang om dagen.
- Kontinuerlig levering er en programvareutviklingsmetode der et team utvikler programvareprodukter i en kort syklus.
- Kontinuerlig distribusjon er en programvareutviklingsprosess der produktfunksjonalitet leveres ved hjelp av automatisk distribusjon.
- Det er fire trinn i en CI/CD-pipeline 1) Kildestadium, 2) Byggstadium, 3) Teststadium, 4) Utplasseringsstadium.
- Viktig CI/CD-verktøy er Jenkins, Bambo og Circle CI.
- CI/CD-pipeline kan forbedre påliteligheten.
- CI/CD-pipeline gjør IT-teamet mer attraktivt for utviklere.
- Syklustid er tiden det tar å gå fra byggestadiet til produksjon.
- Utviklingsfrekvens lar deg analysere flaskehalser du finner under automatisering.
- Change Lead Time måler starttiden for utviklingsfasen til utrulling.
- Change Failure Rate fokuserer på antall ganger utviklingen lykkes kontra antall ganger den mislykkes.
- MTTR (Mean Time to Recovery) er tiden som kreves av teamet ditt for å komme seg etter feil.
- MTTF (Mean Time to Failure) måler tiden mellom reparasjoner og utfall.