Opbygning af en god CI/CD-pipeline med GitHub Actions Det er ikke længere en ekstra ting "til når der er tid": i moderne teams er det praktisk talt et krav for hurtig og pålidelig implementering. Alligevel er det ofte meget mere kompliceret, end det ser ud til, at finde et komplet, generisk og velgennemtænkt eksempel, som du kan tilpasse til din virksomhed.
I de følgende linjer vil vi blande den klassiske teori om CI/CD med eksempler på implementering fra den virkelige verden ved hjælp af GitHub-handlinger, genanvendelige pipelines, opgaver, bash-scripts, PowerShell PnP-modulerImplementeringer til Kubernetes, Google Cloud og Kinsta, sammen med bedste praksis for sikkerhed, overvågning og skalerbarhed. Ideen er, at du kan tage disse dele, tilpasse dem til din kontekst og undgå mange af de typiske faldgruber.
Hvorfor du har brug for en veludviklet CI/CD-pipeline
I den nuværende professionelle udvikling er CI/CD kodens kredsløbssystemDen integrerer ændringer, kører tests, bygger artefakter og implementerer nye versioner med minimal indgriben. Uden denne arbejdsgang bliver hver implementering en langsom, fejlbehæftet og manuel prøvelse.
Kontinuerlig integration (CI) fokuserer på validering af ændringer Så snart de er uploadet til repository'et, køres enhedstests, linters og statiske analyser for at opdage fejl så hurtigt som muligt. Jo hurtigere du får feedback, jo hurtigere kan du rette dem, og jo mindre smertefuld vil enhver regression være.
Kontinuerlig implementering (CD i betydningen kontinuerlig implementering) eller Continuous Delivery (afhængigt af automatiseringsniveauet) tilføjer automatisering af udgivelsesdelen: opbygning af images, publicering af pakker, implementering til test-, staging- eller produktionsmiljøer og endda ændring af trafik ved hjælp af blågrønne eller canary-strategier.
I virksomheder med meget ældre kodeEn god pipeline er et af de bedste redskaber til at modernisere økosystemet: det giver dig mulighed for at introducere tests i ældre tjenester, automatisere opgaver, der tidligere blev udført manuelt, og reducere omkostningerne ved vedligeholdelse af infrastrukturer som Jenkins eller Nexus, der er blevet forældede.
Hvad er GitHub Actions, og hvorfor passer det så godt sammen med CI/CD?
GitHub Actions er den automatiseringsplatform, der er indbygget i GitHub. Det giver dig mulighed for at definere arbejdsgange i YAML-filer i selve repository'et. Med det kan du kompilere, teste, analysere og implementere din software uden at konfigurere eksterne CI-servere.
En arbejdsgang er et sæt af job og trin som udløses af begivenheder som f.eks. push, pull_request, schedule (CRON), workflow_dispatch (manuel) eller endda handlinger på problemer. Hvert job kører i en runner (f.eks. ubuntu-latest) og består af trin, der bruger genanvendelige handlinger eller kommandoer run.
GitHub tilbyder en enorm markedsplads for aktier hvor du har færdige integrationer til næsten alt: Docker, Kubernetes, AWS, Azure, Google Cloud, SonarCloud, Slack, Jira, sikkerhedsanalyse, linters til tusind sprog osv. Dette reducerer i høj grad den tid, der kræves til at opsætte avancerede pipelines.
Sammenlignet med løsninger som Jenkins eller ConcourseGitHub Actions har flere klare fordele: det er en administreret tjeneste (du administrerer ikke servere), den er tæt knyttet til koden, den bruger en pay-as-you-go-model, og den understøttes af et massivt fællesskab. Derudover er mange udviklere allerede bekendt med det fra personlige projekter, hvilket reducerer læringskurven betydeligt.
Grundlæggende komponenter i en GitHub Actions-arbejdsgang
Det hele starter med en YAML-fil i .github/workflows/, for eksempel ci.yml o build-test-deploy.ymlSelvom syntaksen kan vokse betydeligt, er den grundlæggende struktur relativt enkel.
De vigtigste afsnit i YAML er: name (navn på arbejdsgang), on (begivenheder der udløser det), jobs (sæt af logiske opgaver), og inden for hvert job, runs-on (løber), steps (trin), env (globale variabler) og if (betingelser for udførelse af trin eller job).
Job repræsenterer blokke af arbejde som kan køres parallelt eller i en kæde ved hjælp af needsInden for hvert job bruger trinnene handlinger (uses:) eller kommandoer (run:Et typisk eksempel inkluderer: kodeudtjekning, afhængighedsinstallation, linter-udførelse, tests og build.
Hemmeligheder og miljøvariabler De administreres på lager-, organisations- eller miljøniveau. I arbejdsgange refereres der til dem med ${{ secrets.MI_SECRET }} og tillade arbejde med API-nøgler, implementeringstokens eller cloud-legitimationsoplysninger uden at eksponere dem i arkivet.
YAML tillader også at bygge eksekveringsarrays med strategy.matrix, meget nyttigt til at teste din kode på forskellige versioner af Node, Python eller Java, eller endda på forskellige operativsystemer uden at skrive den samme blok flere gange.
Design en moderne CI/CD-pipeline ved hjælp af bedste praksis
En sund pipeline er normalt opdelt i klare faserHurtige tjek (lint, enhedstests), artefaktopbygning, udgivelse (version, mærkning, ændringslog, publicering i artefaktarkiv) og implementering i et eller flere miljøer.
Den kontinuerlige integrationsfase bør være så hurtig som muligt. Dette sikrer, at enhver push- eller pull-anmodning modtager næsten øjeblikkelig feedback. En almindelig praksis er at køre de forskellige kontroller parallelt ved hjælp af separate arrays eller job, hvilket antager en lidt højere pris til gengæld for at reducere den samlede ventetid.
At afkoble pipelinen fra det konkrete sprogDu kan bruge et opgaveværktøj som Task (ligner Make, men med en mere brugervenlig syntaks). På denne måde aktiverer GitHub Actions-arbejdsgangen kun generiske opgaver (task test, task lintosv.) og hvert repository definerer, hvordan de implementeres internt, afhængigt af om det er Node, Java, Python osv.
Versionsstyring og artefakter kommer i spil i udgivelsesfasen.Her opbygger du et Docker-billede, en jar/war-fil, en npm-pakke eller en hvilken som helst anden artefakt, uploader den til den tilsvarende registreringsdatabase (Docker-registret, Maven, npm i Artifact Registry osv.), tagger commits og genererer GitHub-udgivelser eller changelogs med værktøjer som git-cliff eller frigivelseshandlinger.
Endelig implementeringsfasen Flyt den artefakt til runtime-miljøet: Kubernetes (GKE), Google App Engine, Cloud Functions, tjenester på Kinsta, dine egne servere via SSH osv. Her kan du kæde efterfølgende trin sammen, såsom funktionelle tests efter implementering eller Slack-notifikationer med udgivelsesdetaljer.
Eksempel: Komplet pipeline med ESLint, test og implementering på Kinsta
Et meget illustrativt eksempel er brugen af GitHub Actions At validere en React-applikation med ESLint og enhedstests, og derefter implementere den i Kinsta ved hjælp af dens API. Alt er orkestreret i en enkelt CI/CD-workflow.
Den første del af YAML definerer udløseren og pipelinenavnet. For eksempel at den kører på hver push y pull_request til grenen mainog endda planlagt med CRON-job (f.eks. hver dag ved midnat eller hver mandag kl. 8:00 UTC) ved hjælp af begivenheden schedule.
Det første job i pipelinen kan kaldes eslint og den er ansvarlig for at kontrollere kodesyntaksen. Den kører i ubuntu-latest og bruger en række Node-versioner (f.eks. 18.x, 20.x) med trin til at tjekke og konfigurere Node med actions/setup-node, cache npm-afhængigheder, installer med npm ci og kast npm run lint.
Det andet job, testsDet afhænger af eslint gennem needs: eslintså den kører kun, hvis syntakskontrollen er vellykket. Indeni gentages mønsteret: udtjekning, afhængighedsinstallation og udførelse af npm run test på en specifik version af Node.
Det tredje job, deployDen er kædet sammen efter begge job hjælp needs: og bruger et trin med curl at kalde Kinsta API'en. For at gøre dette konfigureres API-nøglen og applikations-ID'et som hemmeligheder i GitHub (KINSTA_API_KEY y APP_ID) og eksponeres i jobbet via env til at opbygge den POST-anmodning, der udløser implementeringen.
Det er vigtigt at forstå, at dette implementeringsjob Kinsta anser blot accepten af API'en for en succes; hvis implementeringen efterfølgende mislykkes internt i Kinsta, kan GitHub-arbejdsgangen dog stadig vise en grøn status. Dette bør huskes for at undgå selvtilfredshed og for at supplere processen med overvågning efter implementering.
Avanceret cron-styring og arbejdsgangsplanlægning
CRON-syntaksen i GitHub Actions Det er baseret på UNIX-formatet med fem felter: minut, time, månedsdag, måned og ugedag. Hvert felt kan bruge stjerner, intervaller, lister og trin (*, 1-5, 1,15,30, */5), som muliggør planlægning af vedligeholdelsesopgaver, sikkerhedskopier, rengøringer eller periodiske kontroller.
Fx 0 0 * * * udfør arbejdsgangen hver midnat (UTC), mens 0 8 * * 1 Det gør den hver mandag kl. 8:00. Dette kombineres problemfrit med de sædvanlige udløsere af push y pull_requestså den samme YAML kan reagere på både kodeændringer og planlagte udførelser.
Denne funktion er ideel til opgaver, der ikke giver mening at frigive i hver commitintensive sikkerhedsscanninger (f.eks. med OWASP Dependency Check i Java), afhængighedsrevisioner, testdækningstjek eller oprydning af gamle artefakter i registreringsdatabasen.
Genbrug af arbejdsgange: skalering af CI/CD til hundredvis af arkiver
Når din organisation har snesevis eller hundredvis af lagreAt kopiere og indsætte den samme YAML overalt er en opskrift på kaos. Enhver ændring kræver, at halvdelen af GitHub Enterprise modificeres, hvilket gør det næsten umuligt at opretholde konsistens og bedste praksis.
Løsningen ligger i at designe genanvendelige arbejdsgange centraliseret i et CI/CD-"skabelon"-arkiv. Disse arbejdsgange eksponerer input og output, og hver tjeneste definerer kun en lille YAML, der kalder dem og videregiver parametre som artefakttype (Docker, Java-bibliotek, npm-pakke), implementeringskørselstid (GKE, GAE, Cloud Function osv.) eller opgaveelementer, der skal udføres.
Et almindeligt mønster er at adskille tre store genanvendelige arbejdsgange: en af build-check-task (kontinuerlig integration), en anden af build-release-dockerfile eller andre artefakter og en tredje implementering (deploy-gke, deploy-gaeosv.), så hvert repository opbygger sin pipeline ved at kombinere dem.
For at indkapsle delt logik kan brugerdefinerede handlinger også defineres. en .github/actionsFor eksempel til at konfigurere Gradle, Java, Node eller Task, til at hente build-metadata, til at udgive Docker-billeder, til at tagge versioner i Git med et bash-script eller til at sende notifikationer til Slack. Den gyldne regel er, at service-repositories kun bør bruge genanvendelige arbejdsgange, ikke disse handlinger direkte, så bagudkompatibilitet er mere håndterbar.
Hurtig kontinuerlig integration med opgaver, matricer og statisk analyse
Under bygge- eller kontrolfasen er det tilrådeligt at udløse mange ting parallelt.Enhedstest, statisk analyse (PMD, Checkstyle, SpotBugs i Java; ESLint i JS/TS), scanning med SonarCloud osv. Dette holder den samlede pipeline-tid rimelig, selv i store kodebaser.
Opgave (Taskfile.yml) fungerer som et abstraktionslag på specifikke kommandoer, hvilket gør det muligt for CI-arbejdsgangen blot at kalde task check, task test o task lintFor et Java-projekt kan disse opgaver delegeres til Gradle med JUnit, PMD, Checkstyle og SpotBugs; for et Node-projekt til Jest, ESLint og sikkerhedsværktøjer som f.eks. npm audit eller lignende.
GitHub Actions tilføjer array-stykket At køre de samme opgaver på forskellige versioner af runtime-systemet: for eksempel test af et Node-bibliotek på 16, 18 og 20, eller et Python-projekt på 3.10 og 3.12. Det er så simpelt som at deklarere et array af versioner og bruge det i jobkonfigurationen.
Denne tilgang er især nyttig i organisationer, der ønsker at understøtte flere stakke. (Java, Node, TypeScript, Python osv.) uden at skulle omskrive pipeline-logikken for hvert repository: Opgaven tilpasser sig hvert sprog, og de genanvendelige arbejdsgange forbliver stort set de samme.
Udgivelsesfase: versionsstyring, tagging og publiceringsartefakter
Når kontrollerne er bestået, er det tid til at bygge den artefakt, der rent faktisk skal implementeres.Docker-billede, JAR-fil, npm-pakke, hvad der end måtte være relevant. Dette involverer både sprogværktøjerne og organisationens registre og versionspolitik.
Nogle Java-projekter bruger plugins som Gradle Axion. at administrere versioner baseret på Git-tags. I blandede kontekster (Java, Node osv.) kan det være enklere at bruge et brugerdefineret bash-script, der beregner den næste version (for eksempel ved hjælp af SemVer), opretter tagget, sender det til fjernbetjeningen og genererer den tilsvarende udgivelse.
Værktøjer som git-cliff De hjælper med at generere ændringslogge Baseret på commit-meddelelser klassificeres ændringer efter type (funktion, rettelse, fejl osv.). Integration af dem i pipelinen sikrer, at hver udgivelse leveres med en tydelig ændringslog, uden at nogen behøver at skrive den manuelt.
For at udgive artefakter kombineres relevante handlinger og legitimationsoplysninger.Docker-registre (Docker Hub, GitHub Container Registry, Artifact Registry), Maven-lagre, npm-registre osv. Igen gemmes legitimationsoplysninger som hemmeligheder og injiceres kun i job, når det er nødvendigt.
Kontinuerlig implementering til Kubernetes, GCP, Kinsta og andre miljøer
Implementering er der, hvor CI/CD interagerer med infrastrukturenHer integreres GitHub Actions problemfrit med næsten enhver platform: Kubernetes, App Engine, Cloud Functions, traditionelle servere, platforme som Kinsta osv.
For Kubernetes (for eksempel i GKE) er det sædvanlige mønster Det er: godkend med Google Cloud (ved hjælp af officielle handlinger), konfigurer kubectl Inden for klyngekonteksten skal du anvende Helm-manifesterne eller -diagrammerne og, om nødvendigt, udføre en kontrolleret udrulning (f.eks. med canary eller blue-green) og verificere status med kommandoer fra kubectl rollout status.
I tilfælde af App Engine eller Cloud FunctionsPipelinen opbygger billedet eller artefakten, publicerer det til artefaktregistret og kalder derefter implementeringskommandoerne. gcloud passende, igen ved hjælp af administrerede legitimationsoplysninger såsom hemmeligheder og kortvarige løbere.
Når implementeringen udføres mod eksterne API'er som f.eks. Kinstasnormalt et trin på curl eller en specialiseret handling, der sender anmodningen med godkendelsestokenet og de nødvendige parametre (app-ID, branch osv.). Jobbet betragtes som vellykket, hvis API'en reagerer korrekt på den nye udgivelsesanmodning.
Implementeringen ledsages næsten altid af en meddelelse. til Slack, Teams eller andre kommunikationsværktøjer, med angivelse af hvilken tjeneste der blev implementeret, i hvilket miljø, med hvilken version, hvem der udløste den, og links til workflow-loggene. I produktion tjener dette også til revision og sporbarhed.
Kvalitetskontrol: sikkerhed, overvågning og logfiler
Automatisering af byggeri og implementering er fantastisk, men mangler overblik Med hensyn til hvad der sker, kan pipelinen blive en sort boks. GitHub Actions tilbyder detaljerede logfiler efter udførelse, job og trin, så du kan diagnosticere kompilerings-, test- eller implementeringsfejl.
Til mere avancerede behov er eksterne observationstjenester integreret. såsom Datadog, New Relic eller Splunk, som indsamler metrikker om arbejdsgange, udførelsestider, fejlrater osv., hvilket hjælper med at opdage flaskehalse og prioritere pipeline-optimeringer.
Samtidig spiller sikkerhed en central rolle: administration af krypterede hemmeligheder, minimum nødvendige adgangspolitikker, gennemgang af handlingstilladelser, inkorporering af kodesårbarhedsscannere og afhængigheder (kodescanning, hemmelighedsscanning, OWASP osv.) i selve arbejdsgangene.
Mange teams tilføjer også test efter implementering i det nyligt opdaterede miljø: end-to-end funktionstests, ydeevnetjek, grundlæggende røgtests og, hvis noget går i stykker, automatiserede rollback-mekanismer, der gendanner den tidligere stabile version.
Workflowstyring: beskyttede grene og pull-anmodninger
Måden at arbejde med branches og pull requests på skal stemme overens med CI/CD så alt giver mening. Det mest almindelige er at beskytte hovedgrenen (main o master) og kræver, at enhver ændring går gennem PR og består pipeline-tjek.
GitHub giver dig mulighed for at definere regler for grenbeskyttelse Disse politikker gennemtvinger brugen af pull-anmodninger, blokerer direkte commits og kræver, at visse statuskontroller (specifikke handlingsworkflows) er grønne, før sammenlægningen tillades. De kan også kræve minimumsrevisioner, godkendelsesregler osv.
Denne model sikrer, at den kode, der når produktionsstart Den har gennemgået menneskelig gennemgang og alle automatiserede pipeline-kontroller, hvilket drastisk reducerer risikoen for at glide igennem alvorlige fejl eller sårbarheder.
I virksomheder med flere miljøer (udvikling, staging, produktion) implementering til produktion er normalt reserveret til merges i hovedgrenen, mens andre grene kan udløse implementeringer til tidligere miljøer til intern test eller demoer.
Et godt designet CI/CD-pipeline med GitHub Actions, når man ser på det store billede Det bliver rygraden i udviklingen: integration af ændringer, kørsel af omfattende testsuiter, opbygning og publicering af artefakter, implementering på flere cloudplatforme, overvågning med observationsværktøjer og styring gennem klare forgrenings- og pull request-regler. Med genanvendelige arbejdsgange, brugerdefinerede handlinger, hjælpeværktøjer som Task, Rease Action og Git Cliff samt robust administration af hemmeligheder og tilladelser er det muligt at understøtte alt fra simple Python-apps til komplekse Kubernetes-arkitekturer, opretholde leveringshastighed, kodekvalitet og sikkerhed uden at overvælde teamet med manuelle opgaver.
