Hyvän CI/CD-putken rakentaminen GitHub Actionsin avulla Se ei ole enää vain ylimääräinen "silloin kun on aikaa": nykyaikaisissa tiimeissä se on käytännössä vaatimus nopealle ja luotettavalle käyttöönotolle. Silti täydellisen, yleisen ja hyvin harkitun esimerkin löytäminen, jota voit soveltaa yritykseesi, on usein paljon monimutkaisempaa kuin miltä se näyttää.
Seuraavissa riveissä sekoitamme klassisen CI/CD-teorian tosielämän toteutusesimerkeillä käyttäen GitHub Actionsia, uudelleenkäytettäviä provisions-työkaluja, Taskeja, bash-skriptejä, PowerShell PnP -moduulitKäyttöönotot Kubernetesiin, Google Cloudiin ja Kinstaan sekä parhaat käytännöt tietoturvan, valvonnan ja skaalautuvuuden osalta. Ajatuksena on, että voit ottaa nämä osat, sovittaa ne kontekstiisi ja välttää monia tyypillisiä sudenkuoppia.
Miksi tarvitset hyvin rakennetun CI/CD-putken
Nykyisessä ammatillisessa kehityksessä CI/CD on koodin verenkiertoelimistöSe integroi muutokset, suorittaa testejä, rakentaa artefakteja ja ottaa käyttöön uusia versioita minimaalisella puuttumisella. Ilman tätä työnkulkua jokaisesta käyttöönotosta tulee hidas, virheille altis ja manuaalinen koettelemus.
Jatkuva integraatio (CI) keskittyy muutosten validointiin Heti kun ne on ladattu repositorioon, suoritetaan yksikkötestejä, linttereitä ja staattisia analyysejä virheiden havaitsemiseksi mahdollisimman nopeasti. Mitä nopeammin saat palautetta, sitä nopeammin voit korjata ne ja sitä vähemmän tuskallista mahdollinen regressio on.
Jatkuva käyttöönotto (CD jatkuvan käyttöönoton merkityksessä) tai Jatkuva toimitus (automaatiotasosta riippuen) lisää julkaisuvaiheen automatisoinnin: levykuvien rakentamisen, pakettien julkaisemisen, käyttöönoton testi-, vaiheistus- tai tuotantoympäristöissä ja jopa liikenteen muuttamisen sinivihreällä tai canary-strategialla.
Yrityksissä, joissa on paljon vanhaa koodiaHyvä prosessi on yksi parhaista vipuvarsista ekosysteemin modernisointiin: sen avulla voit ottaa käyttöön testejä vanhoissa palveluissa, automatisoida aiemmin manuaalisesti tehtyjä tehtäviä ja vähentää vanhentuneiden infrastruktuurien, kuten Jenkinsin tai Nexuksen, ylläpitokustannuksia.
Mikä on GitHub Actions ja miksi se sopii niin hyvin yhteen CI/CD:n kanssa?
GitHub Actions on GitHubin sisäänrakennettu automaatioalusta. Sen avulla voit määrittää työnkulkuja YAML-tiedostoihin itse repositoriossa. Sen avulla voit kääntää, testata, analysoida ja ottaa käyttöön ohjelmistosi ilman ulkoisten CI-palvelimien asentamista.
Työnkulku on joukko töitä ja vaiheita joka laukaistaan tapahtumien, kuten push, pull_request, schedule (CRON) workflow_dispatch (manuaalinen) tai jopa ongelmakohtiin liittyviä toimia. Jokainen työ suoritetaan ajotiedostona (esimerkiksi ubuntu-latest) ja koostuu vaiheista, joissa käytetään uudelleenkäytettäviä toimintoja tai komentoja run.
GitHub tarjoaa valtavan markkinapaikan osakkeille jossa on valmiita integraatioita lähes kaikkeen: Docker, Kubernetes, AWS, Azure, Google Cloud, SonarCloud, Slack, Jira, tietoturva-analyysi, linterit tuhannelle kielelle jne. Tämä vähentää huomattavasti edistyneiden provision-prosessien asentamiseen kuluvaa aikaa.
Verrattuna ratkaisuihin, kuten Jenkins tai ConcourseGitHub Actionsilla on useita selkeitä etuja: se on hallittu palvelu (et hallinnoi palvelimia), se on tiiviisti sidottu koodiin, se käyttää käytön mukaan -mallia ja sitä tukee valtava yhteisö. Lisäksi monet kehittäjät tuntevat sen jo henkilökohtaisista projekteista, mikä lyhentää merkittävästi oppimiskäyrää.
GitHub Actions -työnkulun peruskomponentit
Kaikki alkaa YAML-tiedostosta .github/workflows/, esimerkiksi ci.yml o build-test-deploy.ymlVaikka syntaksi voi kasvaa huomattavasti, perusrakenne on suhteellisen yksinkertainen.
YAML:n keskeiset osiot ovat: name (työnkulun nimi), on (tapahtumat, jotka laukaisevat sen), jobs (loogisten tehtävien joukko) ja kunkin työn sisällä runs-on (juoksija), steps (askeleet), env (globaalit muuttujat) ja if (vaiheiden tai töiden suorittamisen ehdot).
Työt edustavat työlohkoja jota voidaan ajaa rinnakkain tai ketjussa käyttämällä needsKunkin työn vaiheet käyttävät toimintoja (uses:) tai komentoja (run:Tyypillinen esimerkki sisältää: koodin uloskirjauksen, riippuvuuksien asennuksen, linterin suorituksen, testit ja koontiversion.
Salaisuudet ja ympäristömuuttujat Niitä hallitaan tietovarasto-, organisaatio- tai ympäristötasolla. Työnkuluissa niihin viitataan seuraavasti: ${{ secrets.MI_SECRET }} ja sallia työskentely API-avainten, käyttöönottotunnusten tai pilvitunnistetietojen kanssa paljastamatta niitä tietovarastossa.
YAML sallii myös suoritustaulukoiden rakentamisen kanssa strategy.matrix, erittäin hyödyllinen koodin testaamiseen eri Node-, Python- tai Java-versioissa tai jopa eri käyttöjärjestelmissä kirjoittamatta samaa lohkoa useita kertoja.
Suunnittele moderni CI/CD-putki parhaiden käytäntöjen mukaisesti
Terve putki on yleensä jaettu selkeisiin vaiheisiinpikatarkistukset (lint, yksikkötestit), artefaktien koonti, julkaisu (versio, merkinnät, muutosloki, julkaisu artefaktiarkistoon) ja käyttöönotto yhdessä tai useammassa ympäristössä.
Jatkuvan integrointivaiheen tulisi olla mahdollisimman nopea. Tämä varmistaa, että kaikki push- tai pull-pyynnöt saavat lähes välittömän palautteen. Yleinen käytäntö on suorittaa eri tarkistukset rinnakkain käyttämällä erillisiä taulukoita tai töitä, olettaen hieman korkeammat kustannukset vastineeksi kokonaisodotusajan lyhenemisestä.
Putkilinjan irrottaminen betonikielestäVoit käyttää tehtävätyökalua, kuten Task (samanlainen kuin Make, mutta käyttäjäystävällisemmällä syntaksilla). Tällä tavoin GitHub Actions -työnkulku käynnistää vain yleisiä tehtäviä (task test, task lintjne.) ja jokainen repositorio määrittelee, miten ne toteutetaan sisäisesti riippuen siitä, onko kyseessä Node, Java, Python jne.
Versiointi ja artefaktit tulevat mukaan julkaisuvaiheeseen.Tässä voit luoda Docker-kuvan, jar/war-tiedoston, npm-paketin tai minkä tahansa muun artefaktin, ladata sen vastaavaan rekisteriin (Docker-rekisteri, Maven, npm Artifact-rekisterissä jne.), merkitä commitit ja luoda GitHub-julkaisuja tai muutoslokeja työkaluilla, kuten git-cliff tai vapautustoiminnot.
Lopuksi, käyttöönottovaihe Siirrä kyseinen artefakti suoritusympäristöön: Kubernetes (GKE), Google App Engine, Cloud Functions, Kinstan palvelut, omat palvelimesi SSH:n kautta jne. Täällä voit ketjuttaa seuraavia vaiheita, kuten toiminnallisia testejä käyttöönoton jälkeen tai Slack-ilmoituksia julkaisutiedoilla.
Esimerkki: Täydellinen ESLintin, testien ja käyttöönoton sisältävä prosessi Kinstassa
Hyvin havainnollistava esimerkki on GitHub Actionsin käyttö. React-sovelluksen validointi ESLintillä ja yksikkötesteillä ja sen käyttöönotto Kinstaan sen API:n avulla. Kaikki on organisoitu yhdessä CI/CD-työnkulussa.
YAML:n ensimmäinen osa määrittelee liipaisimen ja putken nimi. Esimerkiksi, että se toimii jokaisella push y pull_request haaraan mainja jopa ajoitettu CRON-töillä (esimerkiksi joka päivä keskiyöllä tai joka maanantai klo 8.00 UTC) tapahtuman avulla schedule.
Ensimmäistä työputkea voidaan kutsua eslint ja se vastaa koodin syntaksin tarkistamisesta. Se toimii ubuntu-latest ja käyttää useita Node-versioita (esim. 18.x, 20.x), sekä vaiheet Node-version tarkistamiseksi ja konfiguroimiseksi. actions/setup-node, välimuistiin tallennetut npm-riippuvuudet, asenna sovelluksella npm ci ja heittää npm run lint.
Toinen työ, testsSe riippuu eslint kautta needs: eslintjoten se suoritetaan vain, jos syntaksitarkistus onnistuu. Sisällä kuvio toistuu: uloskirjaus, riippuvuuden asennus ja suoritus npm run test tietyssä Node-versiossa.
Kolmas työpaikka, deploySe on ketjutettu molempien töiden jälkeen käyttäen needs: ja käyttää askelmaa curl kutsuakseen Kinstan API:a. Tätä varten API-avain ja sovellustunnus konfiguroidaan salaisuuksiksi GitHubissa (KINSTA_API_KEY y APP_ID) ja altistuvat työssä kautta env rakentaaksesi POST-pyynnön, joka käynnistää käyttöönoton.
On tärkeää ymmärtää, että tämä käyttöönottotyö Kinsta pitää jo pelkkää API:n hyväksymistä onnistuneena; jos käyttöönotto kuitenkin epäonnistuu Kinstan sisällä sisäisesti, GitHub-työnkulku saattaa silti näyttää vihreää statusta. Tämä on pidettävä mielessä, jotta vältetään itsetyytyväisyys ja prosessia täydennetään käyttöönoton jälkeisellä valvonnalla.
Edistynyt cron-hallinta ja työnkulun aikataulutus
CRON-syntaksi GitHub Actionsissa Se perustuu UNIXin viisikenttäiseen muotoon: minuutti, tunti, kuukaudenpäivä, kuukausi ja viikonpäivä. Jokaisessa kentässä voi käyttää tähdet, alueet, luettelot ja vaiheet (*, 1-5, 1,15,30, */5), jonka avulla voi ajoittaa ylläpitotehtäviä, varmuuskopioita, puhdistusta tai säännöllisiä tarkistuksia.
Esimerkiksi 0 0 * * * suorita työnkulku joka keskiyö (UTC), kun taas 0 8 * * 1 Se tekee tämän joka maanantai klo 8.00. Tämä yhdistyy saumattomasti tavallisiin laukaisimiin, kuten push y pull_requestjotta sama YAML voi reagoida sekä koodimuutoksiin että ajoitettuihin suorituksiin.
Tämä ominaisuus sopii erinomaisesti tehtäviin, joita ei ole järkevää julkaista jokaisessa commitissa.: perusteelliset tietoturvatarkistukset (esim. OWASP-riippuvuustarkistuksella Javassa), riippuvuusauditoinnit, testien kattavuustarkistukset tai vanhojen artefaktien puhdistaminen rekisteristä.
Työnkulun uudelleenkäyttö: CI/CD:n skaalaaminen satoihin tietovarastoihin
Kun organisaatiollasi on kymmeniä tai satoja tietovarastojaSaman YAML-koodin kopioiminen ja liittäminen kaikkialle johtaa kaaokseen. Mikä tahansa muutos vaatii puolen GitHub Enterprisen muokkaamista, mikä tekee johdonmukaisuuden ja parhaiden käytäntöjen ylläpitämisen lähes mahdottomaksi.
Ratkaisu piilee uudelleenkäytettävien työnkulkujen suunnittelussa keskitettynä CI/CD:n ”mallipohjaiseen” arkistoon. Nämä työnkulut paljastavat syötteet ja tuotokset, ja jokainen palvelu määrittelee vain pienen YAML-tiedoston, joka kutsuu niitä ja välittää parametreja, kuten artefaktityypin (Docker, Java-kirjasto, npm-paketti), käyttöönoton ajonaikaisen ympäristön (GKE, GAE, Cloud Function jne.) tai suoritettavat tehtäväelementit.
Yleinen kaava on erottaa kolme suurta uudelleenkäytettävää työnkulkua: Yksi build-check-task (jatkuva integrointi), toinen build-release-dockerfile tai muita esineitä ja kolmas käyttöönotto (deploy-gke, deploy-gaejne.), niin että jokainen tietovarasto rakentaa putkistonsa yhdistämällä ne.
Jaetun logiikan kiteyttämiseksi voidaan määrittää myös mukautettuja toimintoja. en .github/actionsEsimerkiksi Gradlen, Javan, Noden tai Taskin konfigurointiin, koontimetatietojen hakemiseen, Docker-kuvien julkaisemiseen, versioiden merkitsemiseen Gitissä bash-skriptillä tai ilmoitusten lähettämiseen Slackiin. Kultainen sääntö on, että palvelutietovarastojen tulisi käyttää vain uudelleenkäytettäviä työnkulkuja, ei näitä toimintoja suoraan, jotta taaksepäin yhteensopivuus on helpommin hallittavissa.
Nopea jatkuva integrointi tehtäviin, matriiseihin ja staattiseen analyysiin
Rakennus- tai tarkistusvaiheen aikana on suositeltavaa käynnistää useita asioita rinnakkain.Yksikkötestit, staattinen analyysi (PMD, Checkstyle, SpotBugs Javassa; ESLint JS/TS:ssä), skannaus SonarCloudilla jne. Tämä pitää kokonaisprosessin keston kohtuullisena myös suurissa koodikannoissa.
Task (Taskfile.yml) toimii abstraktiokerroksena tietyillä komennoilla, jolloin CI-työnkulku voi yksinkertaisesti kutsua task check, task test o task lintJava-projektissa nämä tehtävät voidaan delegoida Gradlelle JUnitin, PMD:n, Checkstylen ja SpotBugsin avulla; Node-projektissa Jestille, ESLintille ja tietoturvatyökaluille, kuten npm audit tai samankaltainen.
GitHub Actions lisää taulukon osan Samojen tehtävien suorittaminen eri suoritusympäristön versioilla, esimerkiksi Node-kirjaston testaaminen versioilla 16, 18 ja 20 tai Python-projektin testaaminen versioilla 3.10 ja 3.12, onnistuu helposti määrittämällä versiotaulukon ja käyttämällä sitä työkonfiguraatiossa.
Tämä lähestymistapa on erityisen hyödyllinen organisaatioissa, jotka haluavat tukea useita pinoja. (Java, Node, TypeScript, Python jne.) ilman, että jokaisen repositorion putken logiikkaa tarvitsee kirjoittaa uudelleen: Tehtävä mukautuu kuhunkin kieleen ja uudelleenkäytettävät työnkulut pysyvät käytännössä samoina.
Julkaisuvaihe: versiointi, tunnisteiden lisääminen ja artefaktien julkaiseminen
Kun tarkistukset on läpäisty, on aika rakentaa artefakti, joka varsinaisesti otetaan käyttöön.Docker-kuva, JAR-tiedosto, npm-paketti tai mikä tahansa muu sopiva vaihtoehto. Tämä koskee sekä kielityökaluja että organisaation rekistereitä ja versiointikäytäntöä.
Jotkut Java-projektit käyttävät laajennuksia, kuten Gradle Axion. hallita versioita Git-tunnisteiden perusteella. Sekaympäristöissä (Java, Node jne.) voi olla yksinkertaisempaa käyttää mukautettua bash-skriptiä, joka laskee seuraavan version (esimerkiksi SemVer-tunnisteen avulla), luo tunnisteen, lähettää sen etäpalvelimelle ja luo vastaavan julkaisun.
Työkalut kuten git-cliff Ne auttavat muutoslokien luomisessa Muutokset luokitellaan commit-viestien perusteella tyypin mukaan (ominaisuus, korjaus, rikkoutuminen jne.). Niiden integrointi prosessiin varmistaa, että jokaisella julkaisulla on selkeä muutosloki ilman, että kenenkään tarvitsee kirjoittaa sitä manuaalisesti.
Artefaktien julkaisemiseksi yhdistetään asianmukaiset toiminnot ja tunnistetiedot.Docker-rekisterit (Docker Hub, GitHub Container Registry, Artifact Registry), Maven-repositoriot, npm-rekisterit jne. Jälleen kerran tunnistetiedot tallennetaan salaisuuksina ja lisätään töihin vain tarvittaessa.
Jatkuva käyttöönotto Kubernetesiin, GCP:hen, Kinstaan ja muihin ympäristöihin
Käyttöönotto on vaihe, jossa CI/CD on vuorovaikutuksessa infrastruktuurin kanssa.Tässä GitHub Actions integroituu saumattomasti lähes mihin tahansa alustaan: Kubernetesiin, App Engineen, Cloud Functionsiin, perinteisiin palvelimiin, alustoihin, kuten Kinstaan, jne.
Kubernetesille (esimerkiksi GKE:ssä) tavanomainen kaava Se on: todennus Google Cloudilla (virallisilla toimilla), konfigurointi kubectl Käytä klusterikontekstissa Helmin manifesteja tai kaavioita ja suorita tarvittaessa hallittu käyttöönotto (esim. Canarylla tai sinivihreällä) ja tarkista tila komennoilla, jotka ovat saatavilla täältä. kubectl rollout status.
App Enginen tai pilvifunktioiden tapauksessaPutkilinja rakentaa kuvan tai artefaktin, julkaisee sen artefaktirekisteriin ja käynnistää sitten käyttöönottokomennot. gcloud tarvittaessa käyttämällä jälleen hallittuja tunnistetietoja, kuten salaisuuksia ja lyhytaikaisia käyttäjiä.
Kun käyttöönotto suoritetaan ulkoisia API-rajapintoja, kuten Kinstan API-rajapintoja, vastenyleensä yksi askel riittää curl tai erikoistunut toiminto, joka lähettää pyynnön todennustunnuksen ja tarvittavien parametrien (sovellustunnus, haara jne.) kanssa. Työ katsotaan onnistuneeksi, jos API vastaa oikein uuden julkaisun pyyntöön.
Käyttöönottoon liittyy lähes aina ilmoitus. Slackiin, Teamsiin tai muihin viestintätyökaluihin, jotka osoittavat, mikä palvelu on otettu käyttöön, missä ympäristössä, millä versiolla, kuka sen käynnisti, ja linkit työnkulun lokeihin. Tuotannossa tämä toimii myös auditointia ja jäljitettävyyttä varten.
Laadunvalvonta: turvallisuus, valvonta ja lokit
Rakentamisen ja käyttöönoton automatisointi on hienoa, mutta ilman näkyvyyttä Tapahtumien suhteen putkesta voi tulla musta laatikko. GitHub Actions tarjoaa yksityiskohtaisia lokeja suorituksen, työn ja vaiheen mukaan, joiden avulla voit diagnosoida käännös-, testaus- tai käyttöönottovirheitä.
Edistyneempiin tarpeisiin integroidaan ulkoisia havainnointipalveluita. kuten Datadog, New Relic tai Splunk, jotka keräävät mittareita työnkuluista, suoritusajoista, virheasteista jne., mikä auttaa havaitsemaan pullonkauloja ja priorisoimaan prosessien optimointeja.
Samalla turvallisuudella on keskeinen roolisalattujen salaisuuksien hallinta, vähimmäisvaatimukset täyttävät käyttöoikeuskäytännöt, toimintojen käyttöoikeuksien tarkistus, koodin haavoittuvuuksien skannaustyökalujen ja riippuvuuksien (koodin skannaus, salaisuuksien skannaus, OWASP jne.) sisällyttäminen itse työnkulkuihin.
Monet tiimit lisäävät myös käyttöönoton jälkeisen testauksen äskettäin päivitetyssä ympäristössä: kokonaisvaltaiset toiminnalliset testit, suorituskykytarkastukset, perussavutestit ja jos jokin hajoaa, automaattiset palautusmekanismit, jotka palauttavat edellisen vakaan version.
Työnkulun hallinta: suojatut haarat ja pull-pyynnöt
Haarojen ja pull-pyyntöjen käsittelytavan on oltava CI/CD-standardin mukainen. jotta kaikki olisi järkevää. Yleisintä on suojata päähaara (main o master) ja vaativat, että kaikki muutokset käyvät läpi PR:n ja läpäisevät prosessitarkastukset.
GitHubin avulla voit määrittää haarautumissuojaussäännöt Nämä käytännöt pakottavat pull-pyyntöjen käytön, estävät suoria commit-muutoksia ja edellyttävät, että tietyt tilatarkistukset (tiettyjen toimintojen työnkulut) ovat vihreitä ennen yhdistämisen sallimista. Ne voivat myös edellyttää vähimmäismuutoksia, hyväksymissääntöjä jne.
Tämä malli varmistaa, että tuotantoon päätyvä koodi Se on läpäissyt ihmisen tekemän tarkastuksen ja kaikki automatisoidut prosessitarkastukset, mikä vähentää merkittävästi vakavien virheiden tai haavoittuvuuksien riskiä.
Yrityksissä, joissa on useita ympäristöjä (kehitys-, vaiheistus-, tuotanto-) käyttöönotto tuotantoympäristöön on yleensä varattu päähaaraan yhdistämisille, kun taas muut haarat voivat käynnistää käyttöönotot aiempiin ympäristöihin sisäistä testausta tai demoja varten.
Kokonaiskuvaa tarkasteltaessa hyvin suunniteltu CI/CD-putki GitHub Actionsin avulla Siitä tulee kehityksen selkäranka: muutosten integrointi, kattavien testisarjojen suorittaminen, artefaktien rakentaminen ja julkaiseminen, käyttöönotto useille pilvialustoille, valvonta havainnointityökaluilla ja hallinta selkeiden haarautumis- ja pull-pyyntösääntöjen avulla. Uudelleenkäytettävien työnkulkujen, mukautettujen toimintojen, aputyökalujen, kuten Task, Rease Action ja Git Cliff, sekä vankan salaisuuksien ja käyttöoikeuksien hallinnan avulla on mahdollista tukea kaikkea yksinkertaisista Python-sovelluksista monimutkaisiin Kubernetes-arkkitehtuureihin, ylläpitäen toimitusnopeutta, koodin laatua ja turvallisuutta ilman, että tiimiä kuormitetaan manuaalisilla tehtävillä.
