Pokud pracujete ve vývoji softwaru, pravděpodobně jste slyšeli frázi „na mém počítači to funguje“, ale v produkčním prostředí to padá. A právě v tom spočívá dobrý pracovní postup CI/CD s akcemi GitHubu : automatizujete testy, sestavení a nasazení a můžete přestat křížit palce pokaždé, když něco vydáte.
V tomto článku krok za krokem a podrobně uvidíte, jak vytvořit CI/CD pipeline od nuly pomocí GitHub Actions , a to v kombinaci s reálnými příklady: validace pomocí ESLint, spouštění testů, nasazení s externími API, jako je Kinsta, publikování na GitHub Pages, nasazení na servery pomocí SSH, integrace s cloudovými prostředími a návrh opakovaně použitelných pipeline pro velké organizace.
Proč se vyplatí nastavit seriózní CI/CD tok?
Kromě teorie řeší dobře navržený pipeline jeden velmi reálný problém: v kolaborativních projektech může nekontrolované automatizované nasazení narušit produkci kvůli jedinému špatně otestovanému commitu. Představte si, že každé nasazení do hlavní větve probíhá přímo; pokud nikdo nespustil testy ani lintery, je riziko pádu webu extrémně vysoké.
Díky dobře organizovanému pracovnímu postupu CI/CD všechny změny nejprve procházejí automatizovanými kontrolami : lintery, jednotkové testy, integrační testy, statickou analýzou atd. Teprve když tyto kontroly projdou úspěšně, je povoleno nasazení do různých prostředí. To je klíčové jak u malých projektů, tak v organizacích se stovkami repozitářů a velkým množstvím staršího kódu.
Navíc, když je vaše infrastruktura CI/CD rozptýlená (na jedné straně starší Jenkins, na druhé Concourse, manuální skripty, kroky zdokumentované na wiki… nebo jen v něčí hlavě), údržba se stává noční můrou. Centralizace všeho v GitHub Actions , spravované službě integrované s repozitářem, výrazně snižuje provozní náklady a poskytuje vám standardní základ, na kterém můžete stavět.
Co přesně jsou akce GitHubu a jak zapadají do CI/CD?
GitHub Actions je automatizační platforma zahrnutá v GitHubu, která umožňuje definovat pracovní postupy v souborech YAML přímo v repozitáři. Tyto pracovní postupy se spouštějí v reakci na události (push, pull request, vytvoření tagu, vydání, cron úlohy atd.) a provádějí vícekrokové úlohy .
Každá úloha běží v běžci (například ubuntu-latest ) a skládá se z kroků , které mohou být příkazy shellu nebo opakovaně použitelné akce Marketplace. S tímto modelem můžete dělat vše od kompilace, spouštění testů a lintingu až po nasazení na Kubernetes, GitHub Pages, servery s SSH, bezserverové funkce nebo služby jako Kinsta prostřednictvím jeho API.
Klíčové komponenty pracovního postupu v akcích GitHubu
Při definování kanálu CI/CD budete vždy pracovat se stejnými základními stavebními bloky, takže je důležité jim jasně porozumět a konzistentně je aplikovat napříč všemi vašimi repozitáři, abyste se vyhnuli konfiguracím typu Frankenstein , kterým nikdo nerozumí.
- Pracovní postupyYAML soubory v
.github/workflowskteré popisují automatizaci: spouštěče, úlohy a kroky. - Zaměstnání: pracovní jednotky, které běží v běžci; mohou běžet paralelně a být zřetězeny pomocí
needs. - Krokykroky v rámci úlohy; mohou to být akce (
uses:) nebo příkazy (run:). - Běžci: stroje, které provádějí úlohy. Mohou být hostil přes GitHub nebo hostované na vaší vlastní infrastruktuře.
- Akce: opakovaně použitelné části, které zapouzdřují logiku, a to jak od třetích stran (Marketplace), tak i od naší vlastní.
Kromě toho v pokročilých pipelinech často vstupuje do hry následující: strategická matice (strategy.matrix) otestovat stejný projekt v různých prostředích (různé verze Node, Javy, operačních systémů atd.), čímž se urychlí zpětná vazba bez nutnosti duplikovat konfigurační kód.
První kroky: příprava repozitáře a souboru pracovního postupu
Prvním krokem při nastavení vašeho pipeline je vytvoření složky .github/workflows v kořenovém adresáři vašeho repozitáře a uvnitř ní souboru YAML, například build-test-deploy.yml . Tento soubor popisuje kompletní chování vašeho workflow CI/CD, od toho, co ho spouští, až po způsob jeho nasazení.
Velmi běžným vzorem je aktivace workflowu v push a pull_request na hlavní větvi, něco jako main , aby se zajistilo, že jakákoli změna, která bude integrována do kódové základny, projde stejným filtrem kvality.
Kromě „interaktivních“ událostí, jako je push nebo PR, vám GitHub Actions umožňuje definovat naplánované úkoly s klíčem schedule a syntaxe cronu. Například byste mohli spustit denní úlohu údržby nebo zálohy o půlnoci pomocí 0 0 * * * nebo připravit úlohy, které se spouštějí každé pondělí v 8:00 UTC s 0 8 * * 1.
Pochopení syntaxe cronu v akcích GitHubu
Programovací část používá typickou syntaxi cron systému UNIX s pěti poli oddělenými mezerami, která označují minutu, hodinu, den v měsíci, měsíc a den v týdnu. Je poměrně flexibilní, takže se vyplatí jej zvládnout pro automatizaci opakujících se úloh v rámci pipeline.
- Minuta (0–59)například v jakou minutu je úloha spuštěna 15 do 15. minuty.
- Čas (0–23)například denní čas ve 24hodinovém formátu 8 do 8:00.
- Den v měsíci (1–31): konkrétní den v měsíci.
- Měsíc (1–12)například číslo měsíce 6 za červen.
- Den v týdnu (0–7)Neděle je 0 a 7, pondělí je 1 atd.
Můžete také použít speciální znaky k dosažení jemnějších pravidel a k vytvoření úloh, které vyhovují vašim potřebám , aniž byste museli zahlcovat dalšími soubory.
- *: například jakákoli hodnota v daném poli * v minutách znamená „každou minutu“.
- */nintervaly, jako například */5 za „každých 5 minut“.
- ,seznam hodnot, například 1,15,30 v minutách
- -rozsahy, jako například 1-5 v pracovní den (pondělí až pátek).
- ?: nespecifikovaná hodnota, užitečná, když definujete den v měsíci, ale nezáleží vám na dni v týdnu.
Navrhněte fázi kontinuální integrace: lint, testy a rychlé kontroly
Dobrou praxí v oblasti CI je provádět počáteční kontroly rychle, aby se získala okamžitá zpětná vazba: lintery, jednotkové testy a statická analýza by měly selhat co nejdříve, pokud se něco pokazí. Tento přístup používá několik reálných implementací, ať už se jedná o ověřování kódu JavaScript/TypeScript pomocí ESLint a Jest, nebo o projekty v Javě s Gradle, JUnit a analyzátory jako PMD, Checkstyle nebo SpotBugs.
Úloha Lint s ESLint jako prvním filtrem
Typická lint úloha v projektu Node/React nebo podobném se obvykle nazývá eslint a běží na Ubuntu. Pro pokrytí různých běhových prostředí můžete definovat pole verzí Node (například 18.x a 20.x), abyste zajistili, že se váš kód bude chovat stejně ve všech podporovaných verzích.
Mezi obvyklé kroky pro tuto práci patří kontrola kódu s actions/checkoutKonfigurace uzlu s actions/setup-node (povolení mezipaměti Npm), instalace závislostí s npm ci (ideální pro čistá a reprodukovatelná prostředí) a spuštění ESLint se skriptem definovaným v balíček.json, obvykle npm run lint.
Výhodou jasného názvu každého kroku je, že když něco selže, můžete na první pohled zjistit, která část kanálu selhává, a to prohlédnutím protokolů na kartě Akce.
Práce v oblasti jednotkového a integračního testování
Po lintu obvykle následuje práce s názvem něco jako Testy který explicitně závisí na eslint pomocí needs: eslint, aby Testy se nespustí, pokud je syntaxe již porušená.Tato úloha znovu provede kontrolu, nakonfiguruje příslušnou verzi uzlu (např. 18.x) a nainstaluje závislosti pomocí npm ci a hodit npm run test o npm run test:unit v závislosti na vašem stacku.
V případě projektu Vue.js který se nasazují například na stránky GitHubu, kanál nejprve nainstaluje závislosti a poté je spustí jednotkové testy s npm run test:unitpak sestavte zařízení s npm run build Pokud vše půjde dobře a nakonec použije akci jako peaceiris/actions-gh-pages publikovat složku dist na větvi gh-pages.
Průběžné nasazení: od kontrol až po produkci (bez ztráty výkonu při pokusu)
Jakmile je průběžná integrace dokončena, je čas přemýšlet o tom, jak automatizovat nasazení . Existuje mnoho možností: od API hostingových platforem až po stránky GitHub, tradiční servery s SSH nebo pokročilá cloudová prostředí, jako jsou GKE, GAE nebo Cloud Functions.
Nasazení přes API: příklad s Kinsta
Platformy jako Kinsta nabízejí REST API Pomocí tohoto nástroje můžete spravovat nasazení z vašeho pipeline. Cílem je bezpečně uložit klíč API a identifikátor aplikace a spustit... POST s curl k příslušnému koncovému bodu pro spuštění nové verze.
Abyste to mohli provést, musíte nejprve vygenerovat klíč API z dashboardu MyKinsta, uložit jej na bezpečné místo a poté jej nakonfigurovat jako tajný klíč na GitHubu (například KINSTA_API_KEY ). Totéž platí pro APP_ID vaší aplikace , které můžete získat výpisem aplikací pomocí samotného klíče API.
V pracovním postupu se úloha nasazení obvykle nazývá něčím jako rozmístit, spoléhající se na úlohy a testy s lint needs: [eslint, tests] a provést jeden krok kadeř použití proměnných prostředí namapovaných na tajné kódy: ${{ tajemství.KINSTA_API_KEY }} y ${{ tajemství.ID_APP }}Tímto způsobem kanál aktivuje nasazení na Kinsta bez zveřejnění přihlašovacích údajů v kódu.
Důležitým detailem je, že úloha nasazení může být označena jako úspěšná jednoduše proto, že API přijalo požadavek , a to i v případě, že následné nasazení selže. Pokud potřebujete zkontrolovat konečný stav, museli byste přidat další logiku pro dotazování na výsledek nebo propojení s událostmi platformy.
Nasazení na stránky GitHubu s kontrolou kvality
V příkladu Vue.js, který jsme diskutovali dříve, je cílem nasazení webu do Stránky GitHubu pouze po úspěšném provedení testůTok je velmi přímý: zatlačte na main, spuštění testů, sestavení a pokud vše půjde dobře, použití akce GitHub Pages k publikování složky ./vzdálenost.
Chcete-li povolit odeslání akce do větve gh-pages , musíte přejít do nastavení repozitáře, konkrétně do Nastavení > Akce > Obecné > Oprávnění pro pracovní postup , a udělit oprávnění pro čtení a zápis pro GITHUB_TOKEN . Jinak se při pokusu o nasazení zobrazí chyba 403 Forbidden.
Nasaďte na vlastní servery pomocí SSH a SCP
V prostředích, kde nadále pracujete s tradičními servery (např. sdílený hosting nebo VPS), je velmi praktickým přístupem použití SSH klíčů a akcí, jako je appleboy/scp-action, ke kopírování sestavení na server z akcí GitHubu.
Mechanika je jednoduchá: vygenerujete Pár SSH klíčů Na vašem lokálním počítači přidáte veřejný klíč do authorized_keys ze serveru a uložíte soukromý klíč jako tajný klíč v repozitáři (například STAGING_SSH_KEY o PROD_SSH_KEY). Také uložíte hostitele a uživatele (STAGING_HOST, STAGING_USER, Atd.).
V pracovním postupu můžete definovat jeden soubor rozmístit který se aktivuje při odesílání tagů, a použijte funkci endsWith(github.ref, '-staging') o endsWith(github.ref, '-prod') k určení, zda nasadit do testovacího nebo produkčního prostředí. Každá úloha instaluje závislosti, spustí sestavení (například) SvelteKit s npm run build), kopíruje konkrétní soubory, jako například . Htaccess y robots.txt v závislosti na prostředí a nakonec nahrajte složku stavět k serveru přes SCP.
Tento přístup umožňuje nasazení konzistentní a opakovatelnéVe svém každodenním životě děláš jen git pushA když chcete publikovat novou verzi, vytvoříte příslušnou značku (například) v1.2.3-staging o v1.2.3-prod) a necháme akce GitHubu postarat se o vše ostatní.
Navrhujte opakovaně použitelné a škálovatelné kanály pro velké organizace
Ve společnostech s mnoha repozitáři je kopírování a vkládání pipeline do každého projektu receptem na katastrofu: jakákoli globální změna zahrnuje úpravu desítek nebo dokonce stovek souborů . A právě zde přicházejí na řadu opakovaně použitelné pracovní postupy a pomocné nástroje jako Task, git-cliff nebo vlastní akce .
Myšlenkou je extrahovat společnou logiku do vyhrazeného repozitáře CI/CD, který zpřístupňuje opakovaně použitelné pracovní postupy , a pro každý projekt by měl být k dispozici pouze minimální soubor YAML, který je vyvolává s určitými parametry (jazyk, typ artefaktu, prostředí nasazení atd.). Tímto způsobem backendové a frontendové služby sdílejí stejný základní kanál a mění se pouze vstupy.
Samostatné fáze: sestavení, vydání a nasazení
Poměrně robustní design čerpá inspiraci z nástrojů, jako je HashiCorp Waypoint , který jasně rozlišuje mezi třemi fázemi: sestavení , vydání a nasazení . To umožňuje například rychle sestavovat a testovat, generovat artefakty a verze kontrolovaným způsobem a poté nasazovat pomocí různých strategií (modrozelená, kanárkově atd.).
Během fáze sestavení se jednotkové testy a statická analýza spouštějí paralelně (důrazně doporučeno, i když to mírně zvyšuje využití CPU), aby se zkrátil celkový čas. V projektech Java lze analýzy JUnit, PMD, Checkstyle, SpotBugs a SonarCloud spouštět paralelně, zatímco v projektech Node se používají jiné příkazy, ale struktura zůstává stejná.
Fáze vydání zahrnuje sestavení artefaktu (obraz Dockeru, knihovna Java, balíček NPM atd.), označení repozitáře novou verzí, vygenerování changelogu a publikování artefaktu do příslušného registru (Docker Registry, Maven, NPM, Artifact Registry atd.). Verzování lze provádět pomocí vlastního bash skriptu , který aktualizuje verzi a vytvoří tag, s podporou nástrojů jako git-cliff pro generování changelogů nebo akcí jako release-action pro vytváření vydání na GitHubu.
Fáze nasazení je nakonec specializována podle běhového prostředí: GKE pro Kubernetes, Google App Engine , Cloud Functions atd. Každý typ nasazení se nachází ve specifickém pracovním postupu s vlastními vstupy a sdílenými kroky, jako je konfigurace Google Cloudu nebo odesílání oznámení do Slacku pro audit a přehlednost.
Soubory úloh, pole a podpůrné akce
Pro oddělení projektového pipeline od konkrétního jazyka mnoho týmů používá Task (moderní alternativu k Make), který definuje projektové úkoly v souboru Taskfile.yml . Pracovní postup sestavení vyžaduje pouze vyvolání odpovídajících Tasků, a proto stejný pipeline funguje pro projekty v Javě, Node, TypeScriptu a dalších, aniž by se musel větvit do nespočtu podmíněných výrazů.
Kromě toho jsou vytvořeny interní podpůrné akce Pro opakující se úkoly: konfigurace Javy a Gradle, příprava úkolů, ověřování Google Cloudu, nasazení do GKE, odesílání oznámení do Slacku nebo správa verzí Gitu. Tyto akce se nacházejí v .github/actions a poté se používají z různých opakovaně použitelných pracovních postupů, přičemž se udržuje kód CI/CD modulární a snadno se vyvíjející.
Praktickým pravidlem v tomto přístupu je, že repozitáře služeb by měly využívat pouze opakovaně použitelné pracovní postupy a nikoli přímo akce . Tímto způsobem jsou veškeré interní změny akcí řízeny z repozitáře CI/CD, čímž je zachována zpětná kompatibilita.
Nejlepší postupy pro řízení toku změn
Kromě čistě technických aspektů musí být robustní CI/CD pipeline doprovázen politikami pro větvení a ochranou na GitHubu, aby se zajistilo, že nikdo neobejde kontroly zadními vrátky.
V sekci Nastavení > Větve v repozitáři můžete definovat pravidla ochrany pro hlavní větev: vyžadovat žádosti o nahrání před sloučením , vyžadovat kontrolu stavu před sloučením (například úlohy CI, které jsme definovali) a konfigurovat další možnosti, jako je minimální počet recenzentů, blokování přímého nahrání nebo povolená politika sloučení.
Díky těmto pravidlům musí všechny změny projít stejným pracovním postupem CI/CD a lidskou kontrolou před vstupem do hlavní verze, což výrazně snižuje riziko vzniku závažných chyb a zlepšuje sledovatelnost historie změn.
Správa tajných kódů, oprávnění a zabezpečení
V jakémkoli rozumně seriózním potrubí, se kterým se budete zabývat citlivé informaceSSH klíče, API tokeny, přihlašovací údaje k databázi atd. GitHub Actions má systém pro šifrovaná tajemství na úrovni úložiště nebo organizace, na které se odkazuje z pracovních postupů pomocí syntaxe ${{ secrets.NOMBRE }}.
Klíčem je nikdy nevkládat přihlašovací údaje přímo do YAML , ale místo toho je ukládat do Nastavení > Tajné klíče a proměnné > Akce a kontrolovat, kdo může tyto tajné klíče upravovat. Dále je vhodné pravidelně kontrolovat oprávnění tokenu (včetně samotného GITHUB_TOKEN ) a uplatňovat princip nejnižších oprávnění : udělovat pouze přístup nezbytně nezbytný pro každý pracovní postup.
Mezi další užitečná opatření patří povolení nástrojů GitHubu, jako je skenování kódu a skenování tajných dat , integrace analyzátorů zabezpečení závislostí (např. OWASP pro projekty Java) a využití integrací s externími platformami pro monitorování a protokolování (Datadog, New Relic, Splunk atd.) pro získání přehledu o tom, co se děje ve vašich nasazeních.
Monitorování, protokolování a řešení problémů
Každé spuštění pracovního postupu generuje podrobný protokol , který si můžete prohlédnout na kartě Akce v repozitáři. Tyto protokoly zobrazují výstup každého kroku, časy, chyby a všechny provedené příkazy, což vám umožňuje ladit, proč sestavení, test nebo nasazení selhalo.
Tyto informace můžete navíc doplnit integrací oznámení v reálném čase se Slackem nebo Microsoft Teams v případě selhání sestavení nebo nasazení, včetně přímých odkazů na odpovídající protokol. Týmy jsou tak okamžitě informovány a mohou reagovat, aniž by musely neustále kontrolovat GitHub.
Když si všimnete, že se váš pipeline začíná zpomalovat, vyplatí se zkontrolovat interní metriky, jako je průměrná doba sestavení, míra úspěšnosti, doba trvání konkrétních úloh a velikost artefaktů. Často má jednoduchá optimalizace (implementace ukládání závislostí do mezipaměti, paralelizace testů, rozdělení příliš velkých pracovních postupů na specifičtější) obrovský vliv na rychlost zpětné vazby.
Se vším, co je zahrnuto, si můžete vytvořit cokoli od základního pipeline, který jednoduše spouští testy a nasazuje je na GitHub Pages, až po kompletní platformu CI/CD na GitHub Actions , která orchestruje sestavení, vydání a nasazení v různých prostředích, integruje lintery, bezpečnostní testování, oznámení a monitorování a je poměrně dobře škálovatelná jak pro osobní projekty, tak pro organizace s rozsáhlými staršími systémy a náročnými požadavky na dodržování předpisů. Sdílejte tyto informace, aby se o nich dozvědělo více lidí.