Kas yra GitHub Actions ir kodėl jis keičia žaidimo taisykles
Prisimenu laikus, kai CI/CD buvo kažkas sudėtingo ir baisaus – reikėjo konfigūruoti Jenkins serverius, kovoti su XML failais ir maldauti DevOps komandos, kad padėtų viską sujungti. Dabar, kai GitHub Actions tapo pagrindiniu įrankiu daugelyje projektų, viskas pasikeitė. Tai ne tik automatizavimo įrankis – tai visiškai naujas būdas galvoti apie kodo pristatymą ir testavimą.
GitHub Actions leidžia automatizuoti beveik bet kokį procesą tiesiog jūsų repozitorijoje. Nereikia jokių išorinių serverių ar sudėtingų integracijų. Viskas gyvena ten pat, kur ir jūsų kodas. Tai tarsi turėti asmeninį robotą, kuris dirba 24/7 ir niekada nepamiršta paleisti testų prieš deployment’ą.
Pagrindinis privalumas – paprastumas. Sukuriate YAML failą `.github/workflows` kataloge, aprašote, ką norite automatizuoti, ir viskas. GitHub pats pasirūpina infrastruktūra, skalavimusi ir viskuo kitu. Tai demokratizavo CI/CD – dabar net mažos komandos ar individualūs kūrėjai gali turėti profesionalaus lygio automatizavimą be jokių papildomų išlaidų.
Pirmieji žingsniai: kaip sukurti savo pirmąjį workflow
Pradėkime nuo paprasčiausio pavyzdžio. Tarkime, turite Node.js projektą ir norite, kad testai būtų paleisti automatiškai kiekvieną kartą, kai kas nors pushina kodą. Štai kaip tai atrodo:
„`yaml
name: Test Application
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v3
– name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: ’18’
– run: npm install
– run: npm test
„`
Šis paprastas failas daro daug dalykų. Pirma, jis pasako GitHub, kad workflow turėtų veikti kiekvieną kartą, kai kas nors pushina kodą arba kuria pull request. Tada jis sukuria virtualią Ubuntu mašiną, įdiegia Node.js, parsisiunčia jūsų kodą ir paleidžia testus.
Gražiausia tai, kad viskas vyksta automatiškai. Jūs tiesiog commitinate šį failą į savo repozitoriją, ir GitHub pradeda stebėti. Kai tik kas nors pushina kodą, matote gražų žalią varnelę (arba raudoną kryželį, jei kažkas ne taip) šalia commit’o.
Pradedant verta suprasti tris pagrindinius komponentus: **events** (kas paleidžia workflow), **jobs** (kokie darbai turi būti atlikti) ir **steps** (konkretūs veiksmai kiekviename darbe). Šie trys elementai sudaro bet kokio workflow pagrindą.
Sudėtingesni scenarijai: matrix builds ir environment management
Kai įsivariate į GitHub Actions pasaulį, greitai suprasite, kad galite daryti daug daugiau nei tiesiog paleisti testus. Vienas iš galingiausių features yra matrix builds – galimybė paleisti tą patį workflow su skirtingomis konfigūracijomis vienu metu.
Pavyzdžiui, jei kuriate biblioteką, kuri turi veikti su keliais Node.js versijomis ir skirtingose operacinėse sistemose, galite padaryti taip:
„`yaml
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macos-latest]
node-version: [16, 18, 20]
steps:
– uses: actions/checkout@v3
– name: Setup Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
– run: npm install
– run: npm test
„`
Šis workflow sukurs 9 skirtingus darbus (3 OS × 3 Node versijos) ir paleis juos lygiagrečiai. Tai neįtikėtinai galinga, nes per kelias minutes gausite atsakymą, ar jūsų kodas veikia visose platformose.
Environment management taip pat yra kritiškai svarbus. GitHub Actions leidžia apibrėžti skirtingas aplinkas (development, staging, production) su skirtingomis paslaptimis ir apsaugos taisyklėmis. Galite nustatyti, kad deployment į production reikalauja manual approval, o į staging gali vykti automatiškai.
Secrets ir saugumo praktikos
Vienas dalykas, kurį matau nuolat darant neteisingai – secrets valdymas. Niekada, ir aš tikrai turiu omenyje NIEKADA, nekomitkite API raktų, slaptažodžių ar kitų jautrių duomenų tiesiai į workflow failus. GitHub Actions turi puikią secrets valdymo sistemą.
Eikite į savo repozitorijos Settings > Secrets and variables > Actions ir pridėkite savo secrets ten. Tada workflow faile galite juos naudoti taip:
„`yaml
steps:
– name: Deploy to production
env:
API_KEY: ${{ secrets.API_KEY }}
DATABASE_URL: ${{ secrets.DATABASE_URL }}
run: ./deploy.sh
„`
GitHub užmaskuos šias reikšmes visuose loguose, todėl net jei kas nors turės prieigą prie workflow run rezultatų, nematys jūsų slaptažodžių. Tai paprastas, bet neįtikėtinai svarbus saugumo sluoksnis.
Dar vienas patarimas – naudokite environment-specific secrets. Jei turite skirtingas aplinkas, sukurkite atskirus secrets rinkinius kiekvienai. Tai apsaugo nuo atsitiktinio deployment’o į production su development kredencialais.
Taip pat verta apriboti, kas gali paleisti workflows. GitHub leidžia nustatyti, kad workflows iš fork’ų reikalauja patvirtinimo prieš paleidžiant. Tai apsaugo nuo kenkėjiško kodo, kuris galėtų bandyti pavogti jūsų secrets per pull request.
Docker integracija ir konteinerizuoti workflows
Jei jūsų projektas naudoja Docker (o šiais laikais kas nenaudoja?), GitHub Actions puikiai integruojasi su konteineriais. Galite paleisti visą workflow Docker konteineryje arba naudoti Docker kaip dalį savo build proceso.
Paprasčiausias būdas – naudoti Docker konteinerį kaip workflow aplinką:
„`yaml
jobs:
build:
runs-on: ubuntu-latest
container:
image: node:18-alpine
steps:
– uses: actions/checkout@v3
– run: npm install
– run: npm test
„`
Bet daug įdomiau tampa, kai norite build’inti ir push’inti Docker images kaip dalį savo CI/CD proceso. Štai realus pavyzdys, kurį naudoju daugelyje projektų:
„`yaml
jobs:
docker:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v3
– name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
– name: Login to Docker Hub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
– name: Build and push
uses: docker/build-push-action@v4
with:
context: .
push: true
tags: myapp:${{ github.sha }},myapp:latest
cache-from: type=registry,ref=myapp:buildcache
cache-to: type=registry,ref=myapp:buildcache,mode=max
„`
Šis workflow ne tik build’ina ir push’ina jūsų Docker image, bet ir naudoja cache, kad pagreitintų būsimus builds. Tai gali sutaupyti daug laiko, ypač jei turite didelį projektą su daug dependencies.
Reusable workflows ir custom actions
Kai pradėsite naudoti GitHub Actions keliuose projektuose, greitai pastebėsite, kad kartojate tą patį kodą. Čia į pagalbą ateina reusable workflows ir custom actions.
Reusable workflows leidžia apibrėžti workflow vienoje vietoje ir naudoti jį keliuose projektuose. Tai puiku, kai turite organizaciją su daugeliu repozitorijų, kurie naudoja panašią CI/CD logiką. Sukuriate „template” workflow vienoje repozitorijoje ir kviečiate jį iš kitų:
„`yaml
jobs:
call-workflow:
uses: myorg/workflows/.github/workflows/deploy.yml@main
with:
environment: production
secrets:
api-key: ${{ secrets.API_KEY }}
„`
Custom actions dar galingesni. Galite sukurti savo action, kuris atlieka specifinę užduotį, ir dalintis juo su komanda arba net su visa bendruomene per GitHub Marketplace. Aš sukūriau kelis custom actions, kurie automatizuoja rutinines užduotis mūsų projektuose – nuo automatinio changelog generavimo iki Slack notifikacijų siuntimo.
Custom action gali būti parašytas JavaScript, Docker konteineryje arba net kaip composite action (kuris tiesiog sujungia keletą esamų actions). Štai paprastas JavaScript action pavyzdys:
„`javascript
const core = require(‘@actions/core’);
const github = require(‘@actions/github’);
try {
const nameToGreet = core.getInput(‘who-to-greet’);
console.log(`Hello ${nameToGreet}!`);
const time = (new Date()).toTimeString();
core.setOutput(„time”, time);
} catch (error) {
core.setFailed(error.message);
}
„`
Deployment strategijos ir blue-green deployments
Vienas iš svarbiausių CI/CD aspektų – kaip saugiai deploy’inti į production. GitHub Actions leidžia implementuoti įvairias deployment strategijas, nuo paprasčiausio „push and pray” iki sudėtingų blue-green ar canary deployments.
Blue-green deployment strategija reiškia, kad turite dvi identiškas production aplinkas. Viena veikia (blue), o kita laukia (green). Kai deploy’inate naują versiją, ji eina į green aplinką. Kai įsitikinote, kad viskas veikia, perjungiate traffic’ą į green, o blue tampa backup.
Su GitHub Actions tai galite implementuoti taip:
„`yaml
jobs:
deploy:
runs-on: ubuntu-latest
steps:
– name: Deploy to green environment
run: ./deploy-to-green.sh
– name: Run smoke tests
run: ./smoke-tests.sh green
– name: Switch traffic to green
if: success()
run: ./switch-traffic.sh green
– name: Rollback if failed
if: failure()
run: ./rollback.sh
„`
Svarbu turėti gerus smoke tests, kurie greitai patikrina, ar pagrindinės funkcijos veikia naujoje aplinkoje. Jei testai nepavyksta, workflow automatiškai gali atlikti rollback.
Canary deployments dar įdomesni – naują versiją deploy’inate tik mažai daliai vartotojų ir stebite metricas. Jei viskas gerai, palaipsniui didinat traffic’ą. GitHub Actions gali integruotis su įrankiais kaip Kubernetes ar AWS, kad tai automatizuotų.
Monitoring, debugging ir optimizavimas
Kai jūsų workflows tampa sudėtingesni, monitoring ir debugging tampa kritiškai svarbūs. GitHub Actions turi puikų logging sistemą, bet reikia žinoti, kaip jį efektyviai naudoti.
Visų pirma, naudokite `echo` komandas su prasmingais pranešimais. Tai atrodo paprasta, bet kai workflow failina 3 AM, tie pranešimai bus jūsų gelbėjimo ratas:
„`yaml
– name: Deploy application
run: |
echo „Starting deployment at $(date)”
echo „Deploying version: ${{ github.sha }}”
./deploy.sh
echo „Deployment completed successfully”
„`
GitHub Actions taip pat palaiko debug logging. Galite įjungti jį pridėdami secrets `ACTIONS_STEP_DEBUG` ir `ACTIONS_RUNNER_DEBUG` su reikšme `true`. Tai išves daug daugiau informacijos apie tai, kas vyksta kiekviename žingsnyje.
Optimizavimas taip pat svarbus. Workflows, kurie trunka per ilgai, sulėtina visą development procesą. Štai keletas patarimų:
1. **Naudokite cache** – GitHub Actions turi puikų caching mechanizmą dependencies. Naudokite jį npm, pip, maven ir kitiems package managers.
2. **Paralelizuokite** – jei turite nepriklausomus testus ar build steps, paleiskite juos lygiagrečiai.
3. **Optimizuokite Docker builds** – naudokite multi-stage builds ir cache layers.
4. **Fail fast** – jei vienas testas failina, nėra prasmės laukti, kol visi kiti užsibaigs.
„`yaml
strategy:
fail-fast: true
matrix:
test-suite: [unit, integration, e2e]
„`
Kai viskas sujungia: realaus pasaulio pavyzdys
Baigiant, noriu parodyti, kaip visa tai atrodo realiame projekte. Štai workflow, kurį naudoju vienam iš savo projektų – tai full-stack aplikacija su frontend, backend ir database migrations:
„`yaml
name: Full CI/CD Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:14
env:
POSTGRES_PASSWORD: postgres
options: >-
–health-cmd pg_isready
–health-interval 10s
–health-timeout 5s
–health-retries 5
steps:
– uses: actions/checkout@v3
– name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: ’18’
cache: ‘npm’
– name: Install dependencies
run: npm ci
– name: Run linter
run: npm run lint
– name: Run unit tests
run: npm run test:unit
– name: Run integration tests
run: npm run test:integration
env:
DATABASE_URL: postgresql://postgres:postgres@localhost:5432/test
build:
needs: test
runs-on: ubuntu-latest
if: github.ref == ‘refs/heads/main’
steps:
– uses: actions/checkout@v3
– name: Build Docker image
uses: docker/build-push-action@v4
with:
context: .
push: false
tags: myapp:${{ github.sha }}
– name: Run security scan
uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:${{ github.sha }}
deploy:
needs: build
runs-on: ubuntu-latest
environment: production
steps:
– name: Deploy to Kubernetes
run: |
kubectl set image deployment/myapp \
myapp=myapp:${{ github.sha }}
kubectl rollout status deployment/myapp
– name: Send Slack notification
if: always()
uses: 8398a7/action-slack@v3
with:
status: ${{ job.status }}
text: ‘Deployment ${{ job.status }}’
webhook_url: ${{ secrets.SLACK_WEBHOOK }}
„`
Šis workflow daro viską: paleidžia testus su realia database, build’ina Docker image, skenina saugumo pažeidžiamumus, deploy’ina į Kubernetes ir siunčia notifikaciją į Slack. Tai ne teorija – tai realus kodas, kuris veikia production aplinkoje.
Svarbiausia pamoka, kurią išmokau dirbant su GitHub Actions – pradėkite paprastai ir laipsniškai plėskite. Nereikia iš karto kurti super sudėtingo workflow. Pradėkite nuo paprastų testų, paskui pridėkite build, tada deployment. Kiekvienas žingsnis turėtų pridėti vertę ir spręsti realią problemą.
GitHub Actions pakeitė tai, kaip galvojame apie CI/CD. Tai nebėra kažkas, ko bijo junior developeriai ar kas reikalauja atskirų DevOps specialistų. Tai įrankis, kurį gali ir turėtų naudoti kiekvienas developeris. Automatizavimas nebėra prabanga – tai būtinybė šiuolaikiniame software development pasaulyje.
