CI/CD-rørledningsopplæring med eksempel

Hva er en CI/CD-pipeline?

A CI/CD pipeline automatiserer banen en kodeendring tar fra en utviklers commit til en distribuert utgivelse. Den bygger koden, kjører testpakken og promoterer binærfilen på en sikker måte til ett eller flere miljøer. En godt designet pipeline reduserer manuelle feil, gir rask tilbakemelding til utviklere og muliggjør små, hyppige produktiterasjoner.

Rørledningen knytter sammen automatisering og kontinuerlig overvåking gjennom hele programvarens livssyklus – fra integrasjon og testing til levering og distribusjon. De tilkoblede praksisene omtales samlet som en CI/CD-rørledning.

Hva er kontinuerlig integrasjon, kontinuerlig levering og kontinuerlig distribusjon?

• Kontinuerlig integrasjon (CI): en utviklingspraksis der teammedlemmer integrerer arbeidet sitt minst én gang om dagen. Hver integrasjon verifiseres av en automatisert bygging og testkjøring som raskt avdekker feil.
• Kontinuerlig levering (CD): en ingeniørpraksis der teamet holder produktet i en utgivelsesklar tilstand på slutten av hver iterasjon. Distribusjonen til produksjon er vanligvis en manuell godkjenning.
• Kontinuerlig distribusjon (CD): tar kontinuerlig levering et skritt videre – hver endring som består automatiserte kontroller distribueres automatisk til produksjon, uten en menneskelig gateway.

Stadier i en CI/CD-rørledning

En CI/CD-pipeline er en kjørbar spesifikasjon av trinnene som kreves for å sende en ny versjon av programvaren. En feil på et hvilket som helst tidspunkt utløser et varsel – via e-post, Slack, eller en annen kanal – slik at den ansvarlige teknikeren varsles umiddelbart.

Stadier i en CI/CD-pipeline.

Kildestadiet

Pipelinen utløses av en endring i kodelageret. Enhver commit varsler CI/CD-verktøyet om å kjøre den samsvarende pipelinen. Andre vanlige utløsere inkluderer brukerinitierte arbeidsflyter, planlagte kjøringer og resultatene av oppstrøms pipelines.

Byggescenen

Byggefasen kompilerer kildekoden og løser avhengighetene til en kjørbar artefakt. Kompilerte språk som C++, Java, C og Go må produsere binærfiler her. Tolkede språk som JavaScript, Python, og Ruby drar fortsatt nytte av dette stadiet for å pakke avhengigheter, linte og produsere containerbilder.

En feil i byggefasen indikerer vanligvis en grunnleggende feilkonfigurasjon i prosjektet, så problemet må løses umiddelbart.

Teststadiet

Testfasen kjører den automatiserte testpakken for å validere kodens korrekthet og programvarens oppførsel. Den fanger opp lett reproduserbare feil før de når kundene. Det er utviklerens ansvar å skrive og vedlikeholde testene – pipelinen håndhever bare at de kjører.

Distribuer scenen

Distribusjonsfasen flytter den verifiserte artefakten til et målmiljø, for eksempel staging, UAT eller produksjon. Når bygget har bestått alle nødvendige tester, kan distribusjonen utløses automatisk (kontinuerlig distribusjon) eller etter en manuell port (kontinuerlig levering).

Eksempel på en CI/CD-rørledning

Gjennomgangen nedenfor viser en betongrørledning som bruker GitHub, CircleCI, og AWS.

• Kilde Code Kontroll: vert applikasjonskoden i et privat GitHub-repositorium slik at den integreres med bygge-, skanne- og distribusjonstjenester.
• Kontinuerlig integrering: koble CircleCI til depotet slik at hver push henter den nye koden, bygger den og kjører testsuiten.
• Distribuer til UAT: konfigurere CircleCI å distribuere vellykkede bygg til et AWS UAT-miljø for interessenttesting.
• Distribuer til produksjon: Bruk de samme CI/CD-trinnene om igjen for å flytte artefaktet til produksjon, styrt av manuell godkjenning hvis du praktiserer kontinuerlig levering.

Beste praksis for CI/CD-rørledninger

Fremgangsmåtene nedenfor sørger for at pipelines er raske, pålitelige og at teamet stoler på dem:

• Dokumenter den nåværende leveringsprosessen før du automatiserer, slik at du vet hva du skal beholde, endre eller fjerne.
• Start med et lite konseptbevis i stedet for å automatisere hele prosessen på én gang.
• Strukturer pipelinen i flere trinn, så raskt at grunnleggende kontroller kjøres først.
• Start hver arbeidsflyt fra et rent, isolert miljø for å holde bygg reproduserbare.
• Legg til åpen kildekode-verktøy som dekker alt fra kodestil til sikkerhetsskanning.
• Bruk et kodekvalitetshub som kjører de samme testene mot hver gren.
• Fagfellevurdering av alle pull-forespørsler og behandling av pipeline-utdataene som en del av vurderingen.
• Definer suksessmålinger før du starter overgangen – de driver kontinuerlig forbedring.

Fordeler med CI/CD-rørledninger

En moden CI/CD-pipeline gir flere målbare fordeler:

• Erstatter feilutsatte manuelle bygg og utgivelser med pålitelig automatisering.
• Forbedrer konsistensen og kvaliteten på alle sendte gjenstander.
• Øker fleksibiliteten – ny funksjonalitet kan leveres på forespørsel.
• Strømlinjeformer kommunikasjonen mellom utviklere, QA og drift.
• Akselererer tilbakemeldingsprosessen fra kunder med hyppige utgivelser.
• Øker produktsynligheten gjennom dashbord, logger og varsler.
• Fjerner manuelle feil og reduserer utgivelseskostnader.
• Forkorter programvareutviklingens livssyklus.
• Gir en rask tilbakemeldingssløyfe fra utvikler til sluttbruker.
• Fremhever endringer som ødelegger byggingen, slik at de raskt kan tilbakestilles.
• Kombinerer automatiserte tester med lett manuell utforskende testing for å holde kvaliteten høy.

Viktige CI/CD-verktøy

Moderne team velger fra et sunt økosystem av CI/CD-verktøy. De mest brukte er beskrevet nedenfor.

1) Jenkins

Jenkins er en åpen kildekode-server for kontinuerlig integrasjon som automatiserer arbeidsflyter for bygging, testing og utgivelse. Skrevet i Java og støttet av et stort plugin-økosystem, Jenkins driver hundretusenvis av installasjoner over hele verden.

Egenskaper:

• Bygger og tester kode mange ganger om dagen.
• Automatiserer hele bygge-/testprosessen, noe som sparer tid og reduserer feil.
• Distribuerer kode etter hver vellykkede bygging og test.
• Fremskynder utviklingssyklusen gjennom rask tilbakemelding.

Link: https://www.jenkins.io/download/

---

2) Bamboo

Bamboo er en kontinuerlig integrert byggeserver som samler automatisk bygging, testing og utgivelse i ett enkelt verktøy. Den integreres sømløst med Jira Software og Bitbucket.

Egenskaper:

• Kjører parallelle batch-tester.
• Rask å installere og konfigurere.
• Tillatelser per miljø lar utviklere og QA distribuere til sine egne miljøer.
• Innebygde Git-forgreningsarbeidsflyter som automatisk slår sammen grener.

Link: https://www.atlassian.com/software/bamboo

---

3) CircleCI

CircleCI er et fleksibelt CI-verktøy som kjører bygg for mobilapper på tvers av plattformer, Python API-er, Docker-klynger og mer. Det reduserer feil og forbedrer applikasjonskvaliteten gjennom rask tilbakemelding.

Egenskaper:

• Valg av byggemiljøer.
• Støtter mange språk inkludert C++, JavaSkript, .NET, PHP Python, og Ruby.
• Docker-støtte for tilpassede byggebilder.
• Avbryter automatisk bygg i kø eller som kjører når et nyere bygg utløses.

Link: https://circleci.com/

---

4) GitHub-handlinger, GitLab CI og Argo CD

GitHub Actions og GitLab CI integrerer CI/CD direkte i kildekontrollplattformen, og fjerner behovet for en ekstern byggeserver. Argo CD legger til kontinuerlig distribusjon i GitOps-stil for Kubernetes-klynger, og avstemmer klyngen til ønsket tilstand deklarert i Git.

Hvorfor er CI/CD-rørledningen viktig for IT-ledere?

• Forbedrer påliteligheten og forutsigbarheten ved utgivelse.
• Gjør ingeniørorganisasjonen mer påtractiv for utviklere.
• Henter kode fra versjonskontroll og kjører byggingen med ett klikk.
• Flytter binærfiler trygt til målmiljøer.
• Lar prosjektledere administrere miljøvariabler og konfigurasjon per miljø.
• Publiserer applikasjonskomponenter til web, database, API og andre tjenester.
• Surfaces-loggdata og varsler om statusen til hver utgivelse.
• Verifiserer kodeendringer før de går videre, noe som reduserer produksjonsfeil.

KPI-er for CI/CD-pipeline

• Syklus eller distribusjonstid: tiden det tar å gå fra bygging til produksjon. Trender avslører flaskehalser i leveringsprosessen din.
• Distribusjonsfrekvens: hvor ofte du sender. Hyppigere, mindre utgivelser reduserer risikoen og gjør det enklere å fikse feil.
• Endre ledetid: tiden fra utviklingsstart til en vellykket utrulling. Gjenspeiler hvor godt planlegging, koding og levering fungerer sammen.
• Endre feilfrekvens: prosentandelen av utrullinger som forårsaker hendelser eller krever tilbakestilling. Tracks sikkerheten til rørledningen.
• MTTR (gjennomsnittlig tid til restitusjon): Gjennomsnittlig tid det tar å gjenopprette tjenesten etter en feil. Måler robusthet.
• MTTF (gjennomsnittlig tid til feil): gjennomsnittlig tid mellom feil. Tracks langsiktig pålitelighet.

Spørsmål og svar