Jó CI/CD folyamat létrehozása a GitHub Actions segítségével Ez már nem csak egy „arra az esetre való plusz megoldás”: a modern csapatokban gyakorlatilag a gyors és megbízható telepítés követelménye. Ennek ellenére egy teljes, általános és jól átgondolt, a vállalathoz adaptálható példa megtalálása gyakran sokkal bonyolultabb, mint amilyennek látszik.
A következő sorokban a CI/CD klasszikus elméletét fogjuk ötvözni valós megvalósítási példákkal GitHub Actions, újrafelhasználható folyamatok, Tasks és bash szkriptek használatával, PowerShell PnP modulokKubernetes, Google Cloud és Kinsta telepítések, valamint a biztonság, a monitorozás és a skálázhatóság legjobb gyakorlatai. Az ötlet az, hogy ezeket az elemeket a saját kontextusodba illesztve elkerülheted a tipikus buktatók nagy részét.
Miért van szüksége egy jól felépített CI/CD folyamatra?
A jelenlegi szakmai továbbképzésekben a CI/CD a kód keringési rendszere.Minimális beavatkozással integrálja a változtatásokat, teszteket futtat, összeállítja a melléktermékeket és telepít új verziókat. E munkafolyamat nélkül minden telepítés lassú, hibákra hajlamos, manuális megpróbáltatássá válik.
A folyamatos integráció (CI) a változások validálására összpontosít Amint feltöltik őket a tárolóba, egységteszteket, lintereket és statikus elemzéseket futtatnak le a hibák mielőbbi kiszűrése érdekében. Minél gyorsabban kapsz visszajelzést, annál hamarabb kijavíthatod őket, és annál kevésbé lesz fájdalmas bármilyen visszaesés.
Folyamatos telepítés (CD a folyamatos telepítés értelmében) vagy a folyamatos kézbesítés (az automatizálás szintjétől függően) automatizálja a kiadási részt: képfájlok létrehozása, csomagok közzététele, tesztelési, előkészítési vagy éles környezetbe való telepítés, sőt, akár a forgalom módosítása kék-zöld vagy kanári stratégiák használatával.
Olyan vállalatoknál, ahol sok régi kód vanEgy jó folyamatlánc az egyik legjobb eszköz az ökoszisztéma modernizálására: lehetővé teszi tesztek bevezetését a régi szolgáltatásokba, a korábban manuálisan elvégzett feladatok automatizálását, és az olyan elavult infrastruktúrák fenntartási költségeinek csökkentését, mint a Jenkins vagy a Nexus.
Mi a GitHub Actions, és miért illik olyan jól a CI/CD-hez?
A GitHub Actions a GitHubba beépített automatizálási platform. Lehetővé teszi munkafolyamatok definiálását YAML fájlokban, magán a tárházon belül. Segítségével külső CI-kiszolgálók beállítása nélkül fordíthatja, tesztelheti, elemezheti és telepítheti szoftverét.
A munkafolyamat feladatok és lépések összessége amelyet olyan események váltanak ki, mint például push, pull_request, schedule (CRON), workflow_dispatch (kézikönyv) vagy akár a problémákra vonatkozó műveletek. Minden feladat egy futtatófájlban fut (például ubuntu-latest) és olyan lépésekből áll, amelyek újrafelhasználható műveleteket vagy parancsokat használnak run.
A GitHub hatalmas piacot kínál a részvényeknek ahol szinte mindenhez készen állnak az integrációk: Docker, Kubernetes, AWS, Azure, Google Cloud, SonarCloud, Slack, Jira, biztonsági elemzés, linterek ezernyi nyelvhez stb. Ez jelentősen csökkenti a fejlett pipeline-ok beállításához szükséges időt.
Olyan megoldásokhoz képest, mint a Jenkins vagy a ConcourseA GitHub Actions számos egyértelmű előnnyel rendelkezik: felügyelt szolgáltatás (nem kell szervereket felügyelni), szorosan kötődik a kódhoz, használatalapú fizetési modellt használ, és egy hatalmas közösség támogatja. Továbbá sok fejlesztő már ismeri személyes projektjeiből, ami jelentősen lerövidíti a tanulási görbét.
A GitHub Actions munkafolyamat alapvető összetevői
Minden egy YAML fájllal kezdődik .github/workflows/, például ci.yml o build-test-deploy.ymlBár a szintaxis jelentősen bővülhet, az alapstruktúra viszonylag egyszerű.
A YAML főbb részei a következők: name (munkafolyamat neve), on (az azt kiváltó események), jobs (logikai feladatok halmaza), és minden egyes feladaton belül, runs-on (futó), steps (lépések), env (globális változók) és if (lépések vagy feladatok végrehajtásának feltételei).
A munkakörök a munkablokkokat jelentik. amely párhuzamosan vagy láncban futtatható a needsMinden egyes feladaton belül a lépések műveleteket használnak (uses:) vagy parancsok (run:Egy tipikus példa a következőket foglalja magában: kódellenőrzés, függőségek telepítése, linter végrehajtása, tesztek és build.
Titkok és környezeti változók Kezelése az adattár, a szervezet vagy a környezet szintjén történik. A munkafolyamatokban a következővel hivatkoznak rájuk: ${{ secrets.MI_SECRET }} és lehetővé teszi az API-kulcsokkal, telepítési tokenekkel vagy felhőalapú hitelesítő adatokkal való munkát anélkül, hogy azok a tárházban megjelennének.
A YAML lehetővé teszi a végrehajtási tömbök létrehozását is. a strategy.matrix, nagyon hasznos a kód tesztelésére a Node, Python vagy Java különböző verzióin, vagy akár különböző operációs rendszereken anélkül, hogy ugyanazt a blokkot többször meg kellene írni.
Tervezzen egy modern CI/CD folyamatot a legjobb gyakorlatok felhasználásával
Egy egészséges csővezeték általában egyértelmű fázisokra oszlikgyors ellenőrzések (lint, egységtesztek), artifaktumok buildje, kiadása (verzió, címkézés, változásnapló, közzététel az artifact repositoryban) és telepítés egy vagy több környezetben.
A folyamatos integrációs fázisnak a lehető leggyorsabbnak kell lennie. Ez biztosítja, hogy minden push vagy pull kérés szinte azonnali visszajelzést kapjon. Gyakori gyakorlat, hogy a különböző ellenőrzéseket párhuzamosan futtatják különálló tömbök vagy feladatok használatával, feltételezve a valamivel magasabb költségeket a teljes várakozási idő csökkentése érdekében.
A csővezeték leválasztása a konkrét nyelvrőlHasználhatsz egy olyan feladatkezelő eszközt, mint a Task (hasonló a Make-hez, de felhasználóbarátabb szintaxissal). Így a GitHub Actions munkafolyamat csak általános feladatokat hív meg (task test, task lintstb.) és minden adattár meghatározza, hogyan valósítják meg őket belsőleg attól függően, hogy Node, Java, Python stb.
A verziózás és a műtermékek a kiadási fázisban kerülnek szóba.Itt létrehozhatsz egy Docker rendszerképet, egy jar/war fájlt, egy npm csomagot vagy bármilyen más artefaktust, feltöltheted a megfelelő registrybe (Docker registry, Maven, npm az Artifact Registryben stb.), címkézheted a commitokat, és GitHub Release-eket vagy changelogokat generálhatsz olyan eszközökkel, mint a git-cliff vagy feloldási műveletek.
Végül a telepítési fázis Helyezd át ezt az elemet a futási környezetbe: Kubernetes (GKE), Google App Engine, Cloud Functions, Kinsta szolgáltatások, saját szervereid SSH-n keresztül stb. Itt láncolhatod össze a következő lépéseket, például a telepítés utáni funkcionális teszteket vagy a kiadási részleteket tartalmazó Slack értesítéseket.
Példa: Teljes folyamat ESLinttel, tesztekkel és telepítéssel a Kinstán
Egy nagyon szemléletes példa a GitHub Actions használata. Egy React alkalmazás validálása ESLint és egységtesztek segítségével, majd a Kinstára telepítése az API-ját használva. Minden egyetlen CI/CD munkafolyamatban van vezérelve.
A YAML első része definiálja a triggert. és a folyamat nevét. Például, hogy mindegyiken fut push y pull_request az ághoz main, sőt CRON feladatokkal is ütemezhető (például minden nap éjfélkor vagy minden hétfőn 8:00 UTC-kor) az esemény használatával schedule.
Az első feladat a folyamatban nevezhető eslint és ez felelős a kód szintaxisának ellenőrzéséért. A következő nyelven fut: ubuntu-latest és Node verziók tömbjét használja (pl. 18.x, 20.x), lépésekkel a Node ellenőrzéséhez és konfigurálásához a következővel: actions/setup-node, gyorsítótáraz npm függőségeket, telepítés ezzel: npm ci és dobja npm run lint.
A második munka, testsAttól függ eslint mediante needs: eslinttehát csak akkor fut le, ha a szintaxisellenőrzés sikeres. Belül a minta ismétlődik: kijelentkezés, függőség telepítése és a végrehajtása npm run test a Node egy adott verzióján.
A harmadik munka, deploy, mindkét feladat után láncba van kötve használatával needs: és egy lépést használ curl a Kinsta API meghívásához. Ehhez az API-kulcsot és az alkalmazásazonosítót titkos kulcsként kell konfigurálni a GitHub-ban (KINSTA_API_KEY y APP_ID) és a munkában ki vannak téve a env a telepítést kiváltó POST kérés felépítéséhez.
Fontos megérteni, hogy ez a telepítési feladat A Kinsta már az API elfogadását is sikernek tekinti; azonban ha a telepítés később a Kinstán belül meghiúsul, a GitHub munkafolyamat továbbra is zöld státuszt mutathat. Ezt szem előtt kell tartani az önelégültség elkerülése és a folyamat telepítés utáni monitorozással való kiegészítése érdekében.
Fejlett cron-kezelés és munkafolyamat-ütemezés
A CRON szintaxis a GitHub Actionsben Az UNIX öt mezős formátumán alapul: perc, óra, a hónap napja, hónap és a hét napja. Minden mező használható csillagok, tartományok, listák és lépések (*, 1-5, 1,15,30, */5), amely lehetővé teszi a karbantartási feladatok, biztonsági mentések, tisztítások vagy rendszeres ellenőrzések ütemezését.
Pl. 0 0 * * * a munkafolyamat végrehajtása minden éjfélkor (UTC), míg 0 8 * * 1 Ez minden hétfőn este 8-kor történik. Ez zökkenőmentesen kombinálható a szokásos kiváltó okokkal. push y pull_requesthogy ugyanaz a YAML reagálni tudjon mind a kódváltozásokra, mind az ütemezett végrehajtásokra.
Ez a képesség ideális olyan feladatokhoz, amelyeket nem érdemes minden commitban kiadni.intenzív biztonsági vizsgálatok (pl. OWASP függőségi ellenőrzéssel Java-ban), függőségi auditok, tesztlefedettségi ellenőrzések vagy régi összetevők eltávolítása a beállításjegyzékből.
Munkafolyamatok újrahasznosítása: CI/CD skálázása több száz adattárra
Amikor a szervezetének több tucat vagy több száz adattára vanUgyanazon YAML mindenhová másolása és beillesztése a káosz receptje. Bármilyen változtatás a GitHub Enterprise felét módosítja, ami szinte lehetetlenné teszi a következetesség és a legjobb gyakorlatok fenntartását.
A megoldás az újrafelhasználható munkafolyamatok tervezésében rejlik központosítva egy CI/CD „sablon” adattárban. Ezek a munkafolyamatok bemeneteket és kimeneteket tesznek elérhetővé, és minden szolgáltatás csak egy kis YAML-t definiál, amely meghívja őket, paramétereket átadva, például az artefaktum típusát (Docker, Java könyvtár, npm csomag), a telepítési futásidejű környezetet (GKE, GAE, Cloud Function stb.) vagy a végrehajtandó feladatelemeket.
Egy gyakori minta három nagyméretű, újrafelhasználható munkafolyamat szétválasztása: az egyik build-check-task (folyamatos integráció), egy másik build-release-dockerfile vagy más műtermékek és egy harmadik telepítés (deploy-gke, deploy-gaestb.), így minden adattár a saját folyamatát ezek kombinálásával építi fel.
A megosztott logika beágyazásához egyéni műveletek is definiálhatók. en .github/actionsPéldául a Gradle, Java, Node vagy Task konfigurálásához, build metaadatok lekéréséhez, Docker-képek közzétételéhez, verziók címkézéséhez a Gitben bash szkripttel, vagy értesítések küldéséhez a Slackbe. Az aranyszabály az, hogy a szolgáltatástárházak csak újrafelhasználható munkafolyamatokat használjanak, ne közvetlenül ezeket a műveleteket, így a visszafelé kompatibilitás könnyebben kezelhető.
Gyors, folyamatos integráció feladatokkal, mátrixokkal és statikus elemzéssel
Az építési vagy ellenőrzési fázisban célszerű sok dolgot párhuzamosan elindítani.Egységtesztek, statikus elemzés (PMD, Checkstyle, SpotBugs Java-ban; ESLint JS/TS-ben), szkennelés SonarClouddal stb. Ezáltal a teljes folyamatidő ésszerű marad még nagy kódbázisok esetén is.
A Task (Taskfile.yml) absztrakciós rétegként működik. adott parancsokra, lehetővé téve a CI munkafolyamat egyszerű meghívását task check, task test o task lintJava projektek esetén ezek a feladatok delegálhatók a Gradle-nek JUnit, PMD, Checkstyle és SpotBugs segítségével; Node projektek esetén Jest, ESLint és biztonsági eszközök, például npm audit vagy hasonló.
A GitHub Actions hozzáadja a tömb elemét Ugyanazon feladatok futtatása a futtatókörnyezet különböző verzióin: például egy Node könyvtár tesztelése 16-os, 18-as és 20-as verziókon, vagy egy Python projekt tesztelése 3.10-es és 3.12-es verziókon. Ez olyan egyszerű, mint deklarálni egy verziókból álló tömböt, és azt használni a feladat konfigurációjában.
Ez a megközelítés különösen hasznos azoknál a szervezeteknél, amelyek több rendszert szeretnének támogatni. (Java, Node, TypeScript, Python stb.) anélkül, hogy minden egyes adattárhoz újra kellene írni a folyamat logikáját: A feladat minden nyelvhez alkalmazkodik, és az újrafelhasználható munkafolyamatok gyakorlatilag ugyanazok maradnak.
Kiadási fázis: verziózás, címkézés és összetevők közzététele
Miután az ellenőrzések sikeresen megtörténtek, itt az ideje felépíteni a ténylegesen telepítendő műterméket.Docker rendszerkép, JAR fájl, npm csomag, bármi, ami megfelelő. Ez magában foglalja mind a nyelvi eszközöket, mind a szervezet nyilvántartásait és verziókezelési szabályzatát.
Néhány Java projekt olyan bővítményeket használ, mint a Gradle Axion. Git-címkék alapján kezelheti a verziókat. Vegyes környezetekben (Java, Node stb.) egyszerűbb lehet egy egyéni bash szkriptet használni, amely kiszámítja a következő verziót (például SemVer használatával), létrehozza a címkét, elküldi azt a távoli gépnek, és generálja a megfelelő kiadást.
Eszközök, mint git-cliff Segítenek a változásnaplók létrehozásában A véglegesítési üzenetek alapján a változtatásokat típus szerint osztályozzák (funkció, javítás, hibás működés stb.). A folyamatba való integrálásuk biztosítja, hogy minden kiadáshoz egyértelmű változásnapló tartozzon anélkül, hogy bárkinek manuálisan kellene írnia.
Az összetevők közzétételéhez a megfelelő műveleteket és hitelesítő adatokat kombinálják.Docker regisztrátorok (Docker Hub, GitHub Container Registry, Artifact Registry), Maven adattárak, npm regisztrátorok stb. A hitelesítő adatokat ismét titkokként tárolják, és csak szükség esetén injektálják a feladatokba.
Folyamatos telepítés Kubernetes, GCP, Kinsta és más környezetekbe
A telepítés során a CI/CD kölcsönhatásba lép az infrastruktúrával.A GitHub Actions itt zökkenőmentesen integrálható szinte bármilyen platformmal: Kubernetes, App Engine, Cloud Functions, hagyományos szerverek, olyan platformok, mint a Kinsta stb.
Kubernetes esetén (például a GKE-ben) a szokásos minta Ez a következő: hitelesítés a Google Clouddal (hivatalos műveletek használatával), konfigurálás kubectl A fürt kontextusán belül alkalmazza a Helm manifesteket vagy diagramokat, és szükség esetén hajtson végre szabályozott bevezetést (pl. canary vagy blue-green használatával), és ellenőrizze az állapotot a következő parancsokkal: kubectl rollout status.
App Engine vagy Cloud Functions eseténA folyamat létrehozza a rendszerképet vagy az összetethető elemet, közzéteszi azt az Összetehető elem beállításjegyzékében, majd meghívja a telepítési parancsokat. gcloud megfelelő, ismét felügyelt hitelesítő adatok, például titkos kódok és rövid ideig tartó futtatók használatával.
Amikor a telepítést külső API-k, például a Kinsta API-i ellen hajtják végreáltalában egy lépés elég curl vagy egy speciális művelet, amely elküldi a kérést a hitelesítési tokennel és a szükséges paraméterekkel (alkalmazásazonosító, ág stb.). A feladat akkor tekinthető sikeresnek, ha az API helyesen válaszol az új kiadási kérésre.
A telepítést szinte mindig értesítés kíséri. a Slackhez, Teamshez vagy más kommunikációs eszközökhöz, jelezve, hogy melyik szolgáltatást, melyik környezetben, melyik verzióval telepítették, ki aktiválta, valamint hivatkozásokat a munkafolyamat-naplókra. Éles környezetben ez auditálásra és nyomon követhetőségre is szolgál.
Minőségellenőrzés: biztonság, monitorozás és naplók
A build és a telepítés automatizálása nagyszerű, de láthatóság nélkül Ami a folyamatot illeti, a folyamat fekete dobozzá válhat. A GitHub Actions részletes naplókat kínál végrehajtás, feladat és lépés szerint, lehetővé téve a fordítási, tesztelési vagy telepítési hibák diagnosztizálását.
Összetettebb igények esetén külső megfigyelhetőségi szolgáltatásokat integrálnak. mint például a Datadog, a New Relic vagy a Splunk, amelyek mérőszámokat gyűjtenek a munkafolyamatokról, a végrehajtási időkről, a hibaszázalékokról stb., segítve a szűk keresztmetszetek észlelését és a folyamatoptimalizálások rangsorolását.
Ugyanakkor a biztonság kulcsszerepet játsziktitkosított titkok kezelése, minimálisan szükséges hozzáférési szabályzatok, műveleti engedélyek felülvizsgálata, kódsebezhetőség-keresők és függőségek (kódszkennelés, titkosszkennelés, OWASP stb.) beépítése magukba a munkafolyamatokba.
Sok csapat telepítés utáni tesztelést is végez az újonnan frissített környezetben: végponttól végpontig tartó funkcionális tesztek, teljesítményellenőrzések, alapvető füsttesztek, és ha valami elromlik, automatikus visszagörgetési mechanizmusok, amelyek visszaállítják az előző stabil verziót.
Munkafolyamat-irányítás: védett ágak és pull requestek
Az ágakkal és pull requestekkel való munkamódszernek összhangban kell lennie a CI/CD-vel. hogy minden értelmet nyerjen. A leggyakoribb dolog a főág védelme (main o master), és megkövetelik, hogy minden változás PR-en menjen keresztül, és megfeleljen a folyamatellenőrzéseknek.
A GitHub lehetővé teszi az ágvédelmi szabályok meghatározását Ezek a szabályzatok előírják a pull requestek használatát, blokkolják a közvetlen véglegesítéseket, és megkövetelik, hogy bizonyos állapotellenőrzések (meghatározott műveleti munkafolyamatok) zöldek legyenek az egyesítés engedélyezése előtt. Minimális módosításokat, jóváhagyási szabályokat stb. is előírhatnak.
Ez a modell biztosítja, hogy a kód elérje az éles környezetet. Emberi felülvizsgálaton és minden automatizált folyamatellenőrzésen átesett, ami drasztikusan csökkentette a súlyos hibák vagy sebezhetőségek elszenvedésének kockázatát.
Több környezettel rendelkező vállalatoknál Az éles környezetben történő telepítés (fejlesztési, előkészítési, éles környezetben) általában a fő ágba való egyesítésekhez van fenntartva, míg más ágak korábbi környezetekbe történő telepítéseket indíthatnak el belső tesztelés vagy demók céljából.
A teljes képet nézve egy jól megtervezett CI/CD folyamat a GitHub Actions segítségével Ez a fejlesztés gerincévé válik: változások integrálása, átfogó tesztcsomagok futtatása, műtermékek létrehozása és közzététele, több felhőplatformra történő telepítés, megfigyelés megfigyelhetőségi eszközökkel, valamint egyértelmű elágazási és pull request szabályokon keresztüli irányítás. Az újrafelhasználható munkafolyamatokkal, egyéni műveletekkel, olyan kiegészítő eszközökkel, mint a Task, a Rease Action és a Git Cliff, valamint a robusztus titkos- és jogosultságkezeléssel mindent támogatni lehet az egyszerű Python-alkalmazásoktól az összetett Kubernetes architektúrákig, fenntartva a szállítási sebességet, a kódminőséget és a biztonságot anélkül, hogy a csapatot manuális feladatokkal túlterhelnénk.
