Laba CI/CD cauruļvada izveide, izmantojot GitHub Actions Tā vairs nav tikai papildu lieta "kad ir laiks": mūsdienu komandās tā praktiski ir prasība ātrai un uzticamai ieviešanai. Tomēr atrast pilnīgu, vispārīgu un pārdomātu piemēru, ko var pielāgot savam uzņēmumam, bieži vien ir daudz sarežģītāk, nekā šķiet.
Turpmākajās rindās mēs apvienosim klasisko CI/CD teoriju ar reālās pasaules ieviešanas piemēriem, izmantojot GitHub darbības, atkārtoti izmantojamus cauruļvadus, uzdevumus, bash skriptus, PowerShell PnP moduļiIzvietošana pakalpojumos Kubernetes, Google Cloud un Kinsta, kā arī drošības, uzraudzības un mērogojamības paraugprakse. Ideja ir tāda, ka jūs varat ņemt šos elementus, pielāgot tos savam kontekstam un izvairīties no daudzām tipiskām kļūmēm.
Kāpēc jums ir nepieciešams labi izveidots CI/CD cauruļvads
Pašreizējā profesionālajā attīstībā CI/CD ir koda asinsrites sistēma.Tā integrē izmaiņas, veic testus, veido artefaktus un izvieto jaunas versijas ar minimālu iejaukšanos. Bez šīs darbplūsmas katra izvietošana kļūst par lēnu, kļūdu pakļautu, manuālu pārbaudījumu.
Nepārtrauktā integrācija (CI) koncentrējas uz izmaiņu validēšanu Tiklīdz tie ir augšupielādēti repozitorijā, tiek veiktas vienības pārbaudes, linteru analīzes un statiskās analīzes, lai pēc iespējas ātrāk atklātu kļūdas. Jo ātrāk saņemsiet atsauksmes, jo ātrāk varēsiet tās novērst un jo mazāk sāpīga būs jebkāda regresija.
Nepārtraukta izvietošana (CD nepārtrauktas izvietošanas nozīmē) vai nepārtraukta piegāde (atkarībā no automatizācijas līmeņa) pievieno izlaišanas daļas automatizāciju: attēlu veidošanu, pakotņu publicēšanu, izvietošanu testēšanas, izstrādes vai ražošanas vidēs un pat datplūsmas maiņu, izmantojot zili zaļas vai kanārijputniņu stratēģijas.
Uzņēmumos ar daudz mantota kodaLabs cauruļvads ir viens no labākajiem ekosistēmas modernizēšanas svirām: tas ļauj ieviest testus mantotos pakalpojumos, automatizēt uzdevumus, kas iepriekš tika veikti manuāli, un samazināt novecojušu infrastruktūru, piemēram, Jenkins vai Nexus, uzturēšanas izmaksas.
Kas ir GitHub Actions un kāpēc tas tik labi iederas CI/CD?
GitHub Actions ir automatizācijas platforma, kas iebūvēta GitHub. Tas ļauj definēt darbplūsmas YAML failos pašā repozitorijā. Ar to var kompilēt, testēt, analizēt un izvietot programmatūru, neizveidojot ārējus CI serverus.
Darbplūsma ir uzdevumu un darbību kopums. ko izraisa tādi notikumi kā push, pull_request, schedule (CRON), workflow_dispatch (manuāli) vai pat darbības ar problēmām. Katrs uzdevums tiek izpildīts noteiktā skrējienā (piemēram, ubuntu-latest) un sastāv no soļiem, kuros tiek izmantotas atkārtoti lietojamas darbības vai komandas run.
GitHub piedāvā milzīgu akciju tirgu kur ir pieejamas gatavas integrācijas gandrīz visam: Docker, Kubernetes, AWS, Azure, Google Cloud, SonarCloud, Slack, Jira, drošības analīze, tūkstoš valodu linters utt. Tas ievērojami samazina laiku, kas nepieciešams, lai iestatītu modernus cauruļvadus.
Salīdzinot ar tādiem risinājumiem kā Jenkins vai ConcourseGitHub Actions ir vairākas nepārprotamas priekšrocības: tas ir pārvaldīts pakalpojums (jūs nepārvaldāt serverus), tas ir cieši saistīts ar kodu, tas izmanto priekšapmaksas modeli un to atbalsta milzīga kopiena. Turklāt daudzi izstrādātāji to jau pazīst no personīgajiem projektiem, kas ievērojami samazina apguves laiku.
GitHub darbību darbplūsmas pamatkomponenti
Viss sākas ar YAML failu iekšā .github/workflows/, piemēram ci.yml o build-test-deploy.ymlLai gan sintakse var ievērojami paplašināties, pamatstruktūra ir samērā vienkārša.
YAML galvenās sadaļas ir: name (darbplūsmas nosaukums), on (notikumi, kas to izraisa), jobs (loģisko uzdevumu kopums) un katrā uzdevumā runs-on (skrējējs), steps (soļi), env (globālie mainīgie) un if (nosacījumi darbību vai uzdevumu izpildei).
Darbi pārstāv darba blokus ko var darbināt paralēli vai ķēdē, izmantojot needsKatrā uzdevumā soļi izmanto darbības (uses:) vai komandas (run:Tipisks piemērs ietver: koda pārbaudi, atkarību instalēšanu, lintera izpildi, testus un būvēšanu.
Noslēpumi un vides mainīgie Tie tiek pārvaldīti repozitorija, organizācijas vai vides līmenī. Darbplūsmās uz tiem ir atsauces ar ${{ secrets.MI_SECRET }} un ļauj strādāt ar API atslēgām, izvietošanas žetoniem vai mākoņa akreditācijas datiem, neatklājot tos repozitorijā.
YAML ļauj arī veidot izpildes masīvus. ar strategy.matrix, ļoti noderīgi koda testēšanai dažādās Node, Python vai Java versijās vai pat dažādās operētājsistēmās, nerakstot vienu un to pašu bloku vairākas reizes.
Izstrādājiet modernu CI/CD cauruļvadu, izmantojot labāko praksi
Veselīgs cauruļvads parasti tiek sadalīts skaidrās fāzēs: ātrās pārbaudes (lint, vienību testi), artefaktu izveide, izlaišana (versija, marķēšana, izmaiņu žurnāls, publicēšana artefaktu krātuvē) un izvietošana vienā vai vairākās vidēs.
Nepārtrauktās integrācijas fāzei jābūt pēc iespējas ātrākai. Tas nodrošina, ka jebkurš pieprasījuma nosūtīšanas vai nosūtīšanas pieprasījums saņem gandrīz tūlītēju atgriezenisko saiti. Ierasta prakse ir veikt dažādas pārbaudes paralēli, izmantojot atsevišķus masīvus vai uzdevumus, pieņemot nedaudz augstākas izmaksas apmaiņā pret kopējā gaidīšanas laika samazināšanu.
Atvienot cauruļvadu no konkrētās valodasVarat izmantot uzdevumu rīku, piemēram, Task (līdzīgu Make, bet ar lietotājam draudzīgāku sintaksi). Tādā veidā GitHub Actions darbplūsma izsauc tikai vispārīgus uzdevumus (task test, task lintutt.) un katrs repozitorijs definē, kā tie tiek ieviesti iekšēji atkarībā no tā, vai tas ir Node, Java, Python utt.
Versiju veidošana un artefakti tiek ņemti vērā izlaišanas fāzē.Šeit jūs izveidojat Docker attēlu, jar/war failu, npm pakotni vai jebkuru citu artefaktu, augšupielādējat to atbilstošajā reģistrā (Docker reģistrā, Maven, npm Artifact Registry utt.), atzīmējat izmaiņas un ģenerējat GitHub laidienus vai izmaiņu žurnālus ar tādiem rīkiem kā git-cliff vai atbrīvošanas darbības.
Visbeidzot, izvietošanas fāze Pārvietojiet šo artefaktu uz izpildlaika vidi: Kubernetes (GKE), Google App Engine, Cloud Functions, Kinsta pakalpojumus, savus serverus, izmantojot SSH, utt. Šeit varat ķēdē savienot nākamās darbības, piemēram, funkcionālos testus pēc izvietošanas vai Slack paziņojumus ar izlaiduma informāciju.
Piemērs: Pilnīgs cauruļvads ar ESLint, testiem un izvietošanu Kinsta platformā
Ļoti ilustratīvs piemērs ir GitHub darbību izmantošana. Lai validētu React lietojumprogrammu ar ESLint un vienības testiem un pēc tam izvietotu to Kinsta platformā, izmantojot tās API. Viss tiek organizēts vienā CI/CD darbplūsmā.
YAML pirmā daļa definē aktivizētāju (trigeri). un cauruļvada nosaukumu. Piemēram, ka tas darbojas katrā push y pull_request uz filiāli mainun pat ieplānot ar CRON uzdevumiem (piemēram, katru dienu pusnaktī vai katru pirmdienu plkst. 8:00 UTC), izmantojot notikumu schedule.
Pirmo darbu cauruļvadā var saukt par eslint un tas ir atbildīgs par koda sintakses pārbaudi. Tas darbojas ubuntu-latest un izmanto Node versiju masīvu (piemēram, 18.x, 20.x), ar darbībām, lai pārbaudītu un konfigurētu Node ar actions/setup-node, kešatmiņā saglabāt npm atkarības, instalēt ar npm ci un mest npm run lint.
Otrais darbs, testsTas ir atkarīgs no eslint ar needs: eslinttāpēc tas darbojas tikai tad, ja sintakses pārbaude ir veiksmīga. Iekšpusē modelis tiek atkārtots: pārbaude, atkarības instalēšana un izpilde npm run test noteiktā Node versijā.
Trešais darbs, deploy, tas tiek saķēdēts pēc abiem darbiem izmantojot needs: un izmanto soli ar curl lai izsauktu Kinsta API. Lai to izdarītu, API atslēga un lietojumprogrammas ID tiek konfigurēti kā slepenie atslēgas dati pakalpojumā GitHub (KINSTA_API_KEY y APP_ID) un ir pakļauti darbam, izmantojot env lai izveidotu POST pieprasījumu, kas aktivizē izvietošanu.
Ir svarīgi saprast, ka šis izvietošanas uzdevums Kinsta uzskata API pieņemšanu par veiksmīgu; tomēr, ja ieviešana vēlāk neizdodas Kinsta iekšēji, GitHub darbplūsma joprojām var rādīt zaļu statusu. Tas jāpatur prātā, lai izvairītos no pašapmierinātības un papildinātu procesu ar uzraudzību pēc ieviešanas.
Uzlabota cron pārvaldība un darbplūsmas plānošana
CRON sintakse GitHub darbībās Tas ir balstīts uz UNIX piecu lauku formātu: minūte, stunda, mēneša diena, mēnesis un nedēļas diena. Katrā laukā var izmantot zvaigznītes, diapazoni, saraksti un soļi (*, 1-5, 1,15,30, */5), kas ļauj plānot apkopes uzdevumus, dublēšanu, tīrīšanu vai periodiskas pārbaudes.
Piemēram 0 0 * * * izpildīt darbplūsmu katru pusnakti (UTC), kamēr 0 8 * * 1 Tas notiek katru pirmdienu plkst. 8:00. Tas nemanāmi apvienojas ar parastajiem aktivizēšanas mehānismiem, piemēram, push y pull_requestlai viens un tas pats YAML varētu reaģēt gan uz koda izmaiņām, gan uz plānotajām izpildēm.
Šī iespēja ir ideāli piemērota uzdevumiem, kurus nav jēgas izlaist katrā izpildes reizē.intensīvas drošības skenēšanas (piemēram, ar OWASP atkarību pārbaudi Java valodā), atkarību auditi, testu pārklājuma pārbaudes vai vecu artefaktu tīrīšana reģistrā.
Darbplūsmas atkārtota izmantošana: CI/CD mērogošana simtiem repozitoriju
Ja jūsu organizācijai ir desmitiem vai simtiem repozitorijuViena un tā paša YAML kopēšana un ielīmēšana visur ir haosa recepte. Jebkuras izmaiņas prasa modificēt pusi no GitHub Enterprise, padarot gandrīz neiespējamu saglabāt konsekvenci un labāko praksi.
Risinājums slēpjas atkārtoti izmantojamu darbplūsmu izstrādē centralizēti CI/CD “veidnes” krātuvē. Šīs darbplūsmas atklāj ievades un izvades datus, un katrs pakalpojums definē tikai nelielu YAML, kas tos izsauc, nododot tādus parametrus kā artefakta tips (Docker, Java bibliotēka, npm pakotne), izvietošanas izpildlaiks (GKE, GAE, mākoņa funkcija utt.) vai uzdevumu vienumi, kas jāizpilda.
Bieži vien tiek atdalītas trīs lielas, atkārtoti izmantojamas darbplūsmas.: viens no build-check-task (nepārtraukta integrācija), vēl viens no build-release-dockerfile vai citi artefakti un trešais izvietojums (deploy-gke, deploy-gaeutt.), lai katrs repozitorijs veidotu savu cauruļvadu, tos apvienojot.
Lai iekapsulētu koplietoto loģiku, var definēt arī pielāgotas darbības. en .github/actionsPiemēram, lai konfigurētu Gradle, Java, Node vai Task, iegūtu būvējuma metadatus, publicētu Docker attēlus, atzīmētu versijas pakalpojumā Git ar bash skriptu vai nosūtītu paziņojumus pakalpojumam Slack. Zelta likums ir tāds, ka pakalpojumu krātuvēm jāizmanto tikai atkārtoti izmantojamas darbplūsmas, nevis tieši šīs darbības, lai atpakaļejoša saderība būtu vieglāk pārvaldāma.
Ātra nepārtraukta integrācija ar uzdevumu, matricām un statisko analīzi
Izveidošanas vai pārbaudes fāzē ieteicams paralēli aktivizēt daudzas lietas.Vienības testi, statiskā analīze (PMD, Checkstyle, SpotBugs Java valodā; ESLint JS/TS valodā), skenēšana ar SonarCloud utt. Tas nodrošina saprātīgu kopējo cauruļvada laiku pat lielās koda bāzēs.
Uzdevums (Taskfile.yml) darbojas kā abstrakcijas slānis uz konkrētām komandām, ļaujot CI darbplūsmai vienkārši izsaukt task check, task test o task lintJava projektam šos uzdevumus var deleģēt Gradle, izmantojot JUnit, PMD, Checkstyle un SpotBugs; Node projektam — Jest, ESLint un drošības rīkiem, piemēram, npm audit vai tamlīdzīgi.
GitHub Actions pievieno masīva elementu Lai palaistu tos pašus uzdevumus dažādās izpildlaika versijās: piemēram, Node bibliotēkas testēšana 16., 18. un 20. versijās vai Python projekta testēšana 3.10. un 3.12. Tas ir tikpat vienkārši kā versiju masīva deklarēšana un tā izmantošana darba konfigurācijā.
Šī pieeja ir īpaši noderīga organizācijās, kas vēlas atbalstīt vairākus stekus. (Java, Node, TypeScript, Python utt.) bez nepieciešamības pārrakstīt katras repozitorija cauruļvada loģiku: uzdevums pielāgojas katrai valodai, un atkārtoti izmantojamās darbplūsmas praktiski nemainās.
Izlaiduma fāze: versiju veidošana, tagu pievienošana un artefaktu publicēšana
Kad pārbaudes ir izturētas, ir pienācis laiks izveidot artefaktu, kas faktiski tiks izvietots.Docker attēls, JAR fails, npm pakotne vai kas cits, kas ir piemērots. Tas ietver gan valodas rīkus, gan organizācijas reģistrus un versiju veidošanas politiku.
Daži Java projekti izmanto spraudņus, piemēram, Gradle Axion. lai pārvaldītu versijas, pamatojoties uz Git tagiem. Jauktos kontekstos (Java, Node utt.) var būt vienkāršāk izmantot pielāgotu bash skriptu, kas aprēķina nākamo versiju (piemēram, izmantojot SemVer), izveido tagu, nosūta to uz attālo serveri un ģenerē atbilstošo laidienu.
Līdzīgi rīki git-cliff Tie palīdz ģenerēt izmaiņu žurnālus Pamatojoties uz izmaiņu apstiprināšanas ziņojumiem, izmaiņas tiek klasificētas pēc veida (funkcija, labojums, pārrāvums utt.). To integrēšana caurulē nodrošina, ka katram laidienam ir skaidrs izmaiņu žurnāls, un nevienam tas nav jāraksta manuāli.
Lai publicētu artefaktus, tiek apvienotas atbilstošas darbības un akreditācijas dati.Docker reģistri (Docker Hub, GitHub Container Registry, Artifact Registry), Maven repozitoriji, npm reģistri utt. Arī šajā gadījumā akreditācijas dati tiek glabāti kā slepenie dati un ievietoti darbos tikai nepieciešamības gadījumā.
Nepārtraukta izvietošana Kubernetes, GCP, Kinsta un citās vidēs
Izvietošana ir vieta, kur CI/CD mijiedarbojas ar infrastruktūru.Šeit GitHub Actions nemanāmi integrējas gandrīz ar jebkuru platformu: Kubernetes, App Engine, Cloud Functions, tradicionālajiem serveriem, tādām platformām kā Kinsta utt.
Kubernetes (piemēram, GKE) gadījumā parastais modelis Tas ir: autentificējieties ar Google Cloud (izmantojot oficiālas darbības), konfigurējiet kubectl Klastera kontekstā lietojiet Helm manifestus vai diagrammas un, ja nepieciešams, veiciet kontrolētu ieviešanu (piemēram, ar Canary vai Blue-Green) un pārbaudiet statusu ar komandām no kubectl rollout status.
App Engine vai Cloud Functions gadījumāCauruļvads izveido attēlu vai artefaktu, publicē to artefaktu reģistrā un pēc tam izsauc izvietošanas komandas. gcloud nepieciešams, atkal izmantojot pārvaldītus akreditācijas datus, piemēram, slepenos datus un īslaicīgos izpildītājus.
Kad izvietošana tiek veikta, izmantojot ārējās API, piemēram, Kinsta APIparasti pietiek ar vienu soli curl vai specializēta darbība, kas nosūta pieprasījumu ar autentifikācijas marķieri un nepieciešamajiem parametriem (lietotnes ID, atzars utt.). Uzdevums tiek uzskatīts par veiksmīgu, ja API pareizi atbild uz jaunās versijas pieprasījumu.
Izvietošanai gandrīz vienmēr tiek pievienots paziņojums. uz Slack, Teams vai citiem saziņas rīkiem, norādot, kurš pakalpojums tika izvietots, kurā vidē, ar kuru versiju, kas to aktivizēja, un saites uz darbplūsmas žurnāliem. Ražošanas vidē tas kalpo arī auditēšanai un izsekojamībai.
Kvalitātes kontrole: drošība, uzraudzība un žurnāli
Izveides un izvietošanas automatizācija ir lieliska, taču bez redzamības Runājot par notiekošo, cauruļvads var kļūt par melno kasti. GitHub Actions piedāvā detalizētus žurnālus pēc izpildes, pēc uzdevuma un pēc soļa, ļaujot diagnosticēt kompilācijas, testēšanas vai izvietošanas kļūmes.
Sarežģītākām vajadzībām ir integrēti ārējie novērošanas pakalpojumi. piemēram, Datadog, New Relic vai Splunk, kas apkopo rādītājus par darbplūsmām, izpildes laikiem, kļūmju līmeni utt., palīdzot atklāt vājās vietas un noteikt prioritātes cauruļvadu optimizācijām.
Vienlaikus drošībai ir svarīga lomaŠifrētu noslēpumu pārvaldība, minimāli nepieciešamās piekļuves politikas, darbību atļauju pārskatīšana, koda ievainojamību skeneru un atkarību (koda skenēšana, slepeno datu skenēšana, OWASP utt.) iekļaušana pašās darbplūsmās.
Daudzas komandas pievieno arī testēšanu pēc izvietošanas jaunizveidotajā vidē: pilnīgas funkcionālās pārbaudes, veiktspējas pārbaudes, pamata dūmu testi un, ja kaut kas sabojājas, automātiski atcelšanas mehānismi, kas atjauno iepriekšējo stabilo versiju.
Darbplūsmas pārvaldība: aizsargātas filiāles un pull pieprasījumi
Darbības veidam ar atzariem un pull pieprasījumiem ir jābūt saskaņotam ar CI/CD. lai viss būtu saprotams. Visizplatītākā lieta ir aizsargāt galveno zaru (main o master) un pieprasa, lai visas izmaiņas tiktu pārbaudītas pēc pieprasījuma (PR) un tiktu veiktas cauruļvada pārbaudes.
GitHub ļauj definēt zaru aizsardzības noteikumus Šīs politikas piespiež izmantot pieprasījumus (pull requests), bloķē tiešas izmaiņas un pieprasa, lai noteiktām statusa pārbaudēm (konkrētām darbību darbplūsmām) būtu zaļa atzīme, pirms tiek atļauta apvienošana. Tās var arī pieprasīt minimālās pārskatīšanas, apstiprināšanas noteikumus utt.
Šis modelis nodrošina, ka kods, kas nonāk ražošanas vidē, Tas ir izturējis cilvēka pārskatīšanu un visas automatizētās cauruļvada pārbaudes, ievērojami samazinot nopietnu kļūdu vai ievainojamību risku.
Uzņēmumos ar vairākām vidēm (Izstrādes, iestudēšanas, ražošanas) izvietošana ražošanas vidē parasti ir paredzēta apvienošanai ar galveno atzaru, savukārt citas atzares var izraisīt izvietošanu iepriekšējās vidēs iekšējai testēšanai vai demonstrācijām.
Raugoties plašākā mērogā, labi izstrādāts CI/CD cauruļvads ar GitHub Actions Tas kļūst par izstrādes mugurkaulu: izmaiņu integrēšana, visaptverošu testu komplektu palaišana, artefaktu veidošana un publicēšana, izvietošana vairākās mākoņplatformās, uzraudzība ar novērošanas rīkiem un pārvaldība, izmantojot skaidrus sazarojuma un pieprasījuma noteikumus. Izmantojot atkārtoti izmantojamas darbplūsmas, pielāgotas darbības, palīgrīkus, piemēram, Task, Rease Action un Git Cliff, kā arī stabilu slepeno atslēgu un atļauju pārvaldību, ir iespējams atbalstīt visu, sākot no vienkāršām Python lietotnēm līdz sarežģītām Kubernetes arhitektūrām, saglabājot piegādes ātrumu, koda kvalitāti un drošību, nepārslogojot komandu ar manuāliem uzdevumiem.
