Hea CI/CD torujuhtme loomine GitHub Actionsi abil See pole enam lisavõimalus „kui aega on”: tänapäeva meeskondades on see praktiliselt kiire ja usaldusväärse juurutamise nõue. Sellegipoolest on tervikliku, üldise ja läbimõeldud näite leidmine, mida saate oma ettevõtte jaoks kohandada, sageli palju keerulisem, kui esmapilgul tundub.
Järgmistes ridades ühendame klassikalise CI/CD teooria reaalsete rakendusnäidetega, kasutades GitHubi toiminguid, korduvkasutatavaid torujuhtmeid, ülesandeid, bash-skripte, PowerShelli PnP moodulidJuurutused Kubernetesesse, Google Cloudi ja Kinstasse koos parimate turvalisuse, jälgimise ja skaleeritavuse tavadega. Idee seisneb selles, et saate need osad oma konteksti sobitada ja vältida paljusid tüüpilisi lõkse.
Miks on vaja hästi üles ehitatud CI/CD torujuhet?
Praeguses professionaalses arengus on CI/CD koodi vereringesüsteemSee integreerib muudatusi, käivitab teste, loob artefakte ja juurutab uusi versioone minimaalse sekkumisega. Ilma selle töövooeta muutub iga juurutamine aeglaseks, veaohtlikuks ja käsitsi tehtavaks katsumuseks.
Pidev integratsioon (CI) keskendub muudatuste valideerimisele Niipea kui need repositooriumisse üles laaditakse, käivitatakse vigade võimalikult kiireks avastamiseks ühiktestid, linterid ja staatilised analüüsid. Mida kiiremini tagasisidet saate, seda varem saate need parandada ja seda vähem valulik on igasugune regressioon.
Pidev juurutamine (CD pideva juurutamise tähenduses) või pidev edastamine (sõltuvalt automatiseerimise tasemest) lisab väljalaskeosa automatiseerimise: kujutiste loomine, pakettide avaldamine, juurutamine testimis-, proovi- või tootmiskeskkondadesse ja isegi liikluse muutmine sinakasroheliste või kanaaristrateegiate abil.
Ettevõtetes, kus on palju pärandkoodiHea torujuhe on üks parimaid hoobasid ökosüsteemi kaasajastamiseks: see võimaldab teil lisada teste pärandteenustesse, automatiseerida varem käsitsi tehtud ülesandeid ja vähendada vananenud infrastruktuuride, näiteks Jenkinsi või Nexuse, hoolduskulusid.
Mis on GitHub Actions ja miks see sobib nii hästi CI/CD-ga?
GitHub Actions on GitHubisse sisseehitatud automatiseerimisplatvorm. See võimaldab teil määratleda töövooge YAML-failides repositooriumis endas. Selle abil saate oma tarkvara kompileerida, testida, analüüsida ja juurutada ilma väliseid CI-servereid seadistamata.
Töövoog on tööde ja sammude kogum mis käivitub selliste sündmuste poolt nagu push, pull_request, schedule (CRON) workflow_dispatch (käsiraamat) või isegi probleemidega seotud toimingud. Iga töö käivitatakse jooksjana (näiteks ubuntu-latest) ja koosneb sammudest, mis kasutavad korduvkasutatavaid toiminguid või käske run.
GitHub pakub tohutut aktsiaturgu kus on valmis integratsioonid peaaegu kõige jaoks: Docker, Kubernetes, AWS, Azure, Google Cloud, SonarCloud, Slack, Jira, turvaanalüüs, tuhande keele linterid jne. See vähendab oluliselt täiustatud torujuhtmete seadistamiseks kuluvat aega.
Võrreldes selliste lahendustega nagu Jenkins või ConcourseGitHub Actionsil on mitu selget eelist: see on hallatud teenus (te ei halda servereid), see on tihedalt seotud koodiga, see kasutab tasu-käigu järgi mudelit ja seda toetab tohutu kogukond. Lisaks on paljud arendajad sellega juba isiklikest projektidest tuttavad, mis vähendab oluliselt õppimiskõverat.
GitHub Actionsi töövoo põhikomponendid
Kõik algab YAML-failist .github/workflows/, näiteks ci.yml o build-test-deploy.ymlKuigi süntaks võib märkimisväärselt laieneda, on põhistruktuur suhteliselt lihtne.
YAML-i põhiosad on järgmised: name (töövoo nimi), on (sündmused, mis seda käivitavad), jobs (loogiliste ülesannete kogum) ja iga töö piires runs-on (jooksja), steps (sammud), env (globaalsed muutujad) ja if (sammude või tööde teostamise tingimused).
Tööd esindavad tööplokke mida saab käivitada paralleelselt või ahelas, kasutades needsIga töö käigus kasutavad etapid toiminguid (uses:) või käske (run:Tüüpiline näide hõlmab: koodi kontrollimist, sõltuvuste installimist, linteri käivitamist, teste ja ehitamist.
Saladused ja keskkonnamuutujad Neid hallatakse hoidla, organisatsiooni või keskkonna tasandil. Töövoogudes viidatakse neile koos ${{ secrets.MI_SECRET }} ja lubada töötada API-võtmete, juurutusmärkide või pilveteenuste mandaatidega ilma neid repositooriumis avaldamata.
YAML võimaldab ka täitmismassiivide loomist koos strategy.matrix, väga kasulik koodi testimiseks Node'i, Pythoni või Java erinevates versioonides või isegi erinevates operatsioonisüsteemides ilma sama plokki mitu korda kirjutamata.
Projekteerige parim tava kasutades kaasaegne CI/CD torujuhe
Tervislik torujuhe jaguneb tavaliselt selgeteks faasidekskiirkontrollid (lint, ühiktestid), artefaktide koostamine, avaldamine (versioon, sildistamine, muudatuste logi, avaldamine artefaktide repositooriumis) ja juurutamine ühes või mitmes keskkonnas.
Pideva integratsiooni etapp peaks olema võimalikult kiire. See tagab, et iga push- või pull-päring saab peaaegu kohese tagasiside. Levinud praktika on käivitada erinevaid kontrolle paralleelselt, kasutades eraldi massiive või töid, eeldades veidi kõrgemaid kulusid vastutasuks üldise ooteaja vähendamise eest.
Torujuhtme eraldamiseks betoonist keelestVõite kasutada ülesannete tööriista nagu Task (sarnane Make'iga, aga kasutajasõbralikuma süntaksiga). Nii käivitab GitHub Actionsi töövoog ainult üldised ülesanded (task test, task lintjne) ja iga repositoorium määratleb, kuidas neid sisemiselt rakendatakse, olenevalt sellest, kas tegemist on Node'i, Java, Pythoni jne-ga.
Versioonimine ja artefaktid tulevad mängu väljalaskefaasis.Siin saate luua Dockeri kujutise, jar/war-faili, npm-paketi või mis tahes muu artefakti, laadida selle üles vastavasse registrisse (Dockeri register, Maven, npm artefaktide registris jne), sildistada commit'e ja genereerida GitHubi väljaandeid või muudatuste logisid selliste tööriistadega nagu git-cliff või vabastamistoimingud.
Lõpuks, juurutamisetapp Teisalda see artefakt käituskeskkonda: Kubernetes (GKE), Google App Engine, Cloud Functions, Kinsta teenused, oma serverid SSH kaudu jne. Siin saad siduda järgnevad sammud, näiteks funktsionaalsed testid pärast juurutamist või Slacki teated väljalaske üksikasjadega.
Näide: Täielik ESLintiga torujuhe, testid ja juurutamine Kinstas
Väga illustreeriv näide on GitHub Actionsi kasutamine. Reacti rakenduse valideerimine ESLinti ja ühiktestide abil ning seejärel selle Kinstasse juurutamine API abil. Kõik on korraldatud ühes CI/CD töövoogudes.
YAML-i esimene osa määratleb päästiku ja torujuhtme nimi. Näiteks, et see töötab igal push y pull_request filiaali juurde mainja isegi CRON-töödega ajastatud (näiteks iga päev südaööl või igal esmaspäeval kell 8:00 UTC) sündmuse abil schedule.
Esimest töökohta torujuhtmes võib nimetada eslint ja see vastutab koodisüntaksi kontrollimise eest. See töötab ubuntu-latest ja kasutab Node'i versioonide massiivi (nt 18.x, 20.x) koos sammudega Node'i kontrollimiseks ja konfigureerimiseks actions/setup-node, vahemälu npm sõltuvused, installimine koos npm ci ja viska npm run lint.
Teine töö, testsSee sõltub eslint läbi needs: eslintseega käivitub see ainult siis, kui süntaksikontroll on edukas. Sees kordub muster: kontrollimine, sõltuvuse paigaldamine ja käsu käivitamine. npm run test Node'i konkreetsel versioonil.
Kolmas töö, deploySee on pärast mõlemat tööd aheldatud kasutamine needs: ja kasutab sammu koos curl Kinsta API kutsumiseks. Selleks konfigureeritakse API võti ja rakenduse ID GitHubis saladustena (KINSTA_API_KEY y APP_ID) ja on töös avatud läbi env juurutamise käivitava POST-päringu loomiseks.
Oluline on mõista, et see juurutamistöö Kinsta peab API ainuüksi vastuvõtmist eduks; kui aga juurutamine hiljem Kinsta sees ebaõnnestub, võib GitHubi töövoog ikkagi rohelist staatust näidata. Seda tuleks meeles pidada, et vältida enesega rahulolu ja täiendada protsessi juurutamisjärgse jälgimisega.
Täiustatud croni haldus ja töövoo ajastamine
CRON-i süntaks GitHubi toimingutes See põhineb UNIX-i viieväljalisel vormingul: minut, tund, kuu päev, kuu ja nädalapäev. Iga väli saab kasutada tärnid, vahemikud, loendid ja sammud (*, 1-5, 1,15,30, */5), mis võimaldab ajastada hooldustöid, varukoopiaid, puhastusi või perioodilisi kontrolle.
Nt 0 0 * * * käivitage töövoog igal südaööl (UTC), samal ajal kui 0 8 * * 1 See toimub igal esmaspäeval kell 8.00. See sobib sujuvalt tavapäraste päästikutega push y pull_requestnii et sama YAML saab reageerida nii koodimuudatustele kui ka ajastatud täitmistele.
See võimekus sobib ideaalselt ülesannete jaoks, mida pole mõtet igas commit'is avaldada.intensiivsed turvaskaneeringud (nt OWASP sõltuvuskontrolliga Javas), sõltuvusauditid, testide katvuse kontrollid või vanade artefaktide puhastamine registrist.
Töövoo taaskasutamine: CI/CD skaleerimine sadadele repositooriumidele
Kui teie organisatsioonil on kümneid või sadu andmehoidlaidSama YAML-i kopeerimine ja kleepimine kõikjale viib kaoseni. Iga muudatus nõuab poole GitHub Enterprise'i muutmist, mis muudab järjepidevuse ja parimate tavade säilitamise peaaegu võimatuks.
Lahendus peitub korduvkasutatavate töövoogude kujundamises tsentraliseeritud CI/CD „malli” hoidlasse. Need töövood avaldavad sisendeid ja väljundeid ning iga teenus defineerib ainult väikese YAML-i, mis neid kutsub, edastades parameetreid, nagu artefakti tüüp (Docker, Java teek, npm pakett), juurutamise käituskeskkond (GKE, GAE, pilvefunktsioon jne) või ülesandeüksused, mida tuleb täita.
Levinud muster on eraldada kolm suurt korduvkasutatavat töövoogu: üks neist build-check-task (pidev integratsioon), veel üks build-release-dockerfile või muud esemed ja kolmas juurutus (deploy-gke, deploy-gaejne), nii et iga hoidla ehitab oma torujuhtme neid kombineerides.
Jagatud loogika koondamiseks saab määratleda ka kohandatud toiminguid. en .github/actionsNäiteks Gradle'i, Java, Node'i või Taski seadistamiseks, ehituse metaandmete saamiseks, Dockeri kujutiste avaldamiseks, versioonide sildistamiseks Gitis bash-skriptiga või teadete saatmiseks Slacki. Kuldreegel on, et teenusehoidlad peaksid kasutama ainult korduvkasutatavaid töövooge, mitte neid toiminguid otse, et tagasiühilduvus oleks paremini hallatav.
Kiire pidev integreerimine ülesannete, maatriksite ja staatilise analüüsiga
Ehitus- või kontrollifaasis on soovitatav käivitada palju asju paralleelselt.Ühiktestid, staatiline analüüs (PMD, Checkstyle, SpotBugs Javas; ESLint JS/TS-is), skannimine SonarCloudiga jne. See hoiab kogu torujuhtme aja mõistliku isegi suurte koodibaaside korral.
Ülesanne (Taskfile.yml) toimib abstraktsioonikihina kindlate käskude puhul, mis võimaldab CI töövoogu lihtsalt kutsuda task check, task test o task lintJava projekti puhul saab need ülesanded delegeerida Gradle'ile, kasutades JUnitit, PMD-d, Checkstyle'i ja SpotBugsi; Node projekti puhul Jestile, ESLintile ja turvatööriistadele, näiteks npm audit vms.
GitHub Actions lisab massiiviosa Samade ülesannete käitamiseks käituskeskkonna erinevates versioonides: näiteks Node'i teeki testimine versioonidel 16, 18 ja 20 või Pythoni projekti testimine versioonidel 3.10 ja 3.12. See on sama lihtne kui versioonide massiivi deklareerimine ja selle kasutamine töö konfiguratsioonis.
See lähenemisviis on eriti kasulik organisatsioonides, mis soovivad toetada mitut pinu. (Java, Node, TypeScript, Python jne) ilma iga repositooriumi torujuhtme loogikat ümber kirjutamata: Ülesanne kohandub iga keelega ja korduvkasutatavad töövood jäävad praktiliselt samaks.
Väljalaskefaas: versioonimine, sildistamine ja artefaktide avaldamine
Kui kontrollid on läbitud, on aeg luua artefakt, mis tegelikult kasutusele võetakse.Dockeri kujutis, JAR-fail, npm-pakett või mis iganes sobib. See hõlmab nii keeletööriistu kui ka organisatsiooni registreid ja versioonimispoliitikat.
Mõned Java projektid kasutavad pluginaid nagu Gradle Axion. Giti siltidel põhinevate versioonide haldamiseks. Segatud kontekstides (Java, Node jne) võib olla lihtsam kasutada kohandatud bash-skripti, mis arvutab järgmise versiooni (näiteks SemVeri abil), loob sildi, saadab selle kaugseadmesse ja genereerib vastava väljalaske.
Tööriistad nagu git-cliff Need aitavad luua muudatuste logisid Muudatused liigitatakse tüübi järgi (funktsioon, parandus, rike jne) vastavalt muudatuste kinnitamise teadetele. Nende integreerimine torujuhtmesse tagab, et iga väljalaskega kaasneb selge muudatuste logi ilma, et keegi peaks seda käsitsi kirjutama.
Artefaktide avaldamiseks kombineeritakse sobivad toimingud ja volikirjad.Dockeri registrid (Docker Hub, GitHub Container Registry, Artifact Registry), Maveni repositooriumid, npm-registrid jne. Jällegi salvestatakse volikirju saladustena ja süstitakse töödesse ainult vajadusel.
Pidev juurutamine Kubernetesesse, GCP-sse, Kinstasse ja teistesse keskkondadesse
Juurutamine on koht, kus CI/CD suhtleb infrastruktuurigaSiin integreerub GitHub Actions sujuvalt peaaegu iga platvormiga: Kubernetes, App Engine, Cloud Functions, traditsioonilised serverid, platvormid nagu Kinsta jne.
Kubernetesi puhul (näiteks GKE-s) on tavaline muster See on: autentimine Google Cloudiga (ametlike toimingute abil), seadistamine kubectl Klastri kontekstis rakendage Helmi manifeste või diagramme ja vajadusel teostage kontrollitud juurutamine (nt canary või blue-green abil) ning kontrollige olekut käskudega saidilt kubectl rollout status.
App Engine'i või pilvefunktsioonide puhulKonveier loob pildi või artefakti, avaldab selle artefaktide registris ja seejärel käivitab juurutamiskäsklused. gcloud asjakohane, kasutades jällegi hallatud volitusi, näiteks saladusi ja ajutisi käivitajaid.
Kui juurutamine toimub väliste API-de, näiteks Kinsta API-de, abiltavaliselt piisab ühest sammust curl või spetsiaalne toiming, mis saadab päringu koos autentimisloa ja vajalike parameetritega (rakenduse ID, haru jne). Töö loetakse edukaks, kui API vastab uue väljalaske taotlusele õigesti.
Juurutamisega kaasneb peaaegu alati teade. Slacki, Teamsi või muude suhtlusvahenditega, näidates ära, millist teenust juurutati, millises keskkonnas, millise versiooniga, kes selle käivitas, ja linke töövoo logidele. Tootmises kasutatakse seda ka auditeerimiseks ja jälgitavuse tagamiseks.
Kvaliteedikontroll: turvalisus, jälgimine ja logid
Ehituse ja juurutamise automatiseerimine on suurepärane, aga ilma nähtavuseta Mis puutub toimuvasse, siis torujuhtmest võib saada must kast. GitHub Actions pakub detailseid logisid teostuse, töö ja sammu kaupa, mis võimaldab diagnoosida kompileerimise, testimise või juurutamise tõrkeid.
Täiustatud vajaduste jaoks on integreeritud välised jälgitavuse teenused. näiteks Datadog, New Relic või Splunk, mis koguvad mõõdikuid töövoogude, täitmisaegade, tõrkemäärade jms kohta, aidates tuvastada kitsaskohti ja seada prioriteediks torujuhtme optimeerimise.
Samal ajal mängib turvalisus võtmerollikrüpteeritud saladuste haldamine, minimaalselt vajalikud juurdepääsupoliitikad, toimingulubade ülevaatamine, koodi haavatavuste skannerite ja sõltuvuste (koodi skannimine, salajaste andmete skannimine, OWASP jne) lisamine töövoogudesse endisse.
Paljud meeskonnad lisavad ka juurutamisjärgset testimist äsja uuendatud keskkonnas: otsast lõpuni funktsionaalsed testid, jõudluskontrollid, põhilised suitsutestid ja kui midagi peaks rikki minema, automaatsed tagasipööramismehhanismid, mis taastavad eelmise stabiilse versiooni.
Töövoo haldamine: kaitstud harud ja pull-taotlused
Harude ja pull-requestidega töötamise viis peab olema kooskõlas CI/CD-ga. et kõik oleks loogiline. Kõige tavalisem on kaitsta peamist haru (main o master) ja nõuavad, et kõik muudatused läbiksid PR-i ja läbiksid torujuhtme kontrollid.
GitHub võimaldab teil määratleda harukaitse reegleid Need poliitikad sunnivad kasutama pull requeste, blokeerivad otseseid commit'e ja nõuavad, et teatud olekukontrollid (konkreetsed toimingute töövood) oleksid enne ühendamise lubamist rohelised. Samuti võivad need nõuda minimaalseid parandusi, kinnitusreegleid jne.
See mudel tagab, et tootmisse jõudev kood See on läbinud inimeste poolt ülevaatuse ja kõik automatiseeritud torujuhtme kontrollid, mis vähendab oluliselt tõsiste vigade või haavatavuste ilmnemise ohtu.
Mitme keskkonnaga ettevõtetes (Arendus-, lavastus-, tootmis-) juurutamine tootmiskeskkonda on tavaliselt reserveeritud põhiharuga liitmiseks, samas kui teised harud võivad käivitada juurutamise eelmistesse keskkondadesse sisemise testimise või demode jaoks.
Suuremat pilti vaadates on hästi disainitud CI/CD torujuhe GitHub Actionsiga Sellest saab arenduse selgroog: muudatuste integreerimine, ulatuslike testimiskomplektide käitamine, artefaktide loomine ja avaldamine, juurutamine mitmele pilveplatvormile, jälgimine jälgitavustööriistadega ning selgete hargnemis- ja pull-taotlusreeglite haldamine. Korduvkasutatavate töövoogude, kohandatud toimingute, abitööriistade (nt Task, Rease Action ja Git Cliff) ning tugeva salajaste ja lubade haldamise abil on võimalik toetada kõike alates lihtsatest Pythoni rakendustest kuni keerukate Kubernetes'i arhitektuurideni, säilitades edastuskiiruse, koodi kvaliteedi ja turvalisuse ilma meeskonda käsitsi tehtavate ülesannetega üle koormamata.
