CI/CD i GitHub Actions

CI automatyzuje sprawdzenie zmiany, a CD automatyzuje jej dostarczenie. Dobrze zaprojektowany pipeline powinien być powtarzalny, szybki do diagnozy i oparty na tych samych komendach, które można uruchomić lokalnie.

Powiązane tematy: Git w praktyce zespołowej, GitHub, Testowanie oprogramowania, Docker oraz Logi, monitoring i troubleshooting.

1. CI i CD

CI:

commit → test → build

CD:

build → deploy

Celem jest automatyzacja powtarzalnych kroków.

2. GitHub Actions

Workflow:

.github/workflows/ci.yml

3. Minimalny workflow

name: CI

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v7

      - name: Test
        run: echo "Run tests here"

4. Go

- uses: actions/setup-go@v5
  with:
    go-version: '1.25'

- run: go test ./...
- run: go build ./...

5. Node

- uses: actions/setup-node@v4
  with:
    node-version: 22

- run: npm ci
- run: npm test
- run: npm run build

6. Trigger

Branch:

on:
  push:
    branches: [main]

Ręczne uruchomienie:

on:
  workflow_dispatch:

7. Jobs

jobs:
  test:
    ...
  build:
    needs: test
    ...
  deploy:
    needs: build
    ...

8. Matrix

strategy:
  matrix:
    node: [20, 22]

Pozwala testować na wielu wersjach.

9. Secrets

GitHub:

Settings → Secrets and variables → Actions

W workflow:

env:
  API_TOKEN: ${{ secrets.API_TOKEN }}

Nie loguj sekretów.

10. Artifacts

- uses: actions/upload-artifact@v4
  with:
    name: build
    path: dist/

11. Docker build

- run: docker build -t myapp:${{ github.sha }} .

12. Container Registry

GitHub Container Registry:

ghcr.io/OWNER/IMAGE

Typowy flow:

commit
 ↓
test
 ↓
docker build
 ↓
push image
 ↓
deploy

13. Deployment po SSH

Możliwe podejście:

GitHub Actions
  ↓ SSH
VPS
  ↓
docker compose pull
docker compose up -d

Klucz wdrożeniowy trzymaj jako secret.

14. Environments

Możesz mieć:

development
staging
production

i osobne secrets/approval.

15. Pull Request checks

Przed merge wymagaj: - testów, - builda, - lintera.

Dzięki temu main jest stabilniejszy.

16. Cache

Node:

with:
  cache: npm

Go może cache'ować moduły i build cache.

17. Workflow permissions

Dawaj minimalne potrzebne uprawnienia.

permissions:
  contents: read

18. Release workflow

Przy tagu:

on:
  push:
    tags:
      - 'v*'

Możesz: - zbudować binarki, - utworzyć release, - opublikować obraz Docker.

19. CI dla małego projektu

Dobry początek:

push/PR
  ↓
format/lint
  ↓
tests
  ↓
build

Nie zaczynaj od skomplikowanego pipeline'u.

20. Typowe problemy

• różnice między środowiskiem lokalnym a runnerem,
• brak secret,
• złe permissions,
• niespójne wersje Node/Go,
• deployment mimo nieudanych testów,
• latest bez wersjonowania obrazów.

21. Co trzeba umieć

• napisać prosty workflow,
• uruchomić test/build,
• użyć secrets,
• zbudować kontener,
• połączyć CI z deploymentem,
• rozumieć zależności jobów.

Oficjalne źródła

• GitHub Actions documentation: https://docs.github.com/actions
• Workflow syntax: https://docs.github.com/actions/writing-workflows/workflow-syntax-for-github-actions