GitHub Actions — CI/CD od zera#

CI/CD w skrócie#

CI (Continuous Integration) automatycznie buduje i testuje każdą zmianę, zanim trafi do main. CD (Continuous Delivery/Deployment) automatyzuje wydanie. W ProfessNet używamy GitHub Actions — pipeline'y żyją w repo, w katalogu .github/workflows/.

Anatomia workflow#

Pojęcie	Czym jest
Workflow	Plik YAML z całym procesem
Event (on)	Co go uruchamia (push, pull_request, schedule)
Job	Grupa kroków na jednej maszynie (runner)
Step	Pojedyncza komenda lub akcja
Runner	Maszyna wykonująca job (np. ubuntu-latest)

Pierwszy pipeline CI#

Plik .github/workflows/ci.yml — lint, testy i build przy każdym PR:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Test
        run: npm test

      - name: Build
        run: npm run build

Wskazówka: Używaj npm ci, nie npm install, w CI. ci instaluje dokładnie wersje z package-lock.json i jest szybsze — to samo robi build na Vercelu, więc środowiska są spójne.

Macierz wersji (matrix)#

Chcesz przetestować na kilku wersjach Node naraz? Matrix zrównolegli joby:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci && npm test

Cache i szybkość#

actions/setup-node z cache: npm zapamiętuje pobrane pakiety między uruchomieniami, skracając czas instalacji. Każdy job startuje na czystej maszynie, więc cache i artefakty to sposób na przekazywanie danych.

Zależności między jobami#

Job może czekać na inny przez needs — np. deploy dopiero po zielonych testach:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - run: echo "Deploy tylko z main po zielonych testach"

Status checks i ochrona main#

Zielony workflow staje się status check widocznym w PR. Włączając branch protection na main z wymaganiem tego checka, blokujesz merge, dopóki CI nie przejdzie. To spina się z lekcją o code review.

Podsumowanie#

GitHub Actions to YAML w .github/workflows/: event uruchamia joby, joby mają kroki. Zacznij od checkout → setup-node → npm ci → lint → test → build. Dodaj cache dla szybkości, needs dla kolejności i wymagany status check na main, by nic niezgodnego nie weszło do produkcji.