Ile trwa typowy pipeline CI dla Next.js?

Z włączonym cache podstawowy zestaw (lint, type check, build, testy jednostkowe) zamyka się zwykle w kilku minutach. Bez cache te same kroki potrafią zająć dwa-trzy razy dłużej, bo za każdym razem instalują zależności i budują od zera. Testy E2E i Lighthouse CI dokładają kolejne kilka minut, bo wymagają uruchomienia aplikacji. Dlatego cache zależności i `.next/cache` to jedna z pierwszych rzeczy, które warto skonfigurować.

Czy potrzebuję CI/CD dla jednoosobowego projektu?

Tak, choć w okrojonej formie. Nawet sam lint plus sprawdzenie buildu chroni przed wypchnięciem kodu, który się nie kompiluje albo nie buduje — a takie błędy zdarzają się każdemu, niezależnie od wielkości zespołu. Konfiguracja podstawowego pipeline to kwestia kilkunastu minut, a potrafi oszczędzić godziny debugowania na produkcji. Pełny zestaw z E2E i Lighthouse dokładaj wtedy, gdy projekt rośnie i ma realnych użytkowników.

Jak bezpiecznie zarządzać sekretami w GitHub Actions?

Przez wbudowany mechanizm: Settings → Secrets and variables → Actions, gdzie dodajesz wartości takie jak `DATABASE_URL`, `SSH_PRIVATE_KEY` czy `SERVER_HOST` jako zaszyfrowane sekrety. W workflow odwołujesz się do nich przez `${{ secrets.NAZWA }}`, a GitHub maskuje je w logach. Żelazna zasada: nigdy nie commituj sekretów do repozytorium — raz wypchnięty sekret traktuj jako skompromitowany i zrotuj go, nawet jeśli usuniesz go z historii.

Czy na Vercel potrzebuję osobnego pipeline do deployu?

Nie. Vercel automatycznie wdraża każdy push na main oraz tworzy preview deployment dla każdego pull requesta, więc nie musisz pisać workflow deployującego. GitHub Actions wykorzystujesz wtedy wyłącznie do kontroli jakości — lint, testy, Lighthouse — które mają zablokować merge, jeśli coś jest nie tak. Osobny job deploy piszesz dopiero przy self-hostingu, gdzie to Ty odpowiadasz za dostarczenie kodu na serwer.

Co powinno być wymaganym sprawdzeniem przed mergem?

Minimum to lint, type check i build — bez nich nie ma sensu wpuszczać kodu do main. W dojrzalszym projekcie dokładasz testy jednostkowe i E2E, a często także Lighthouse CI jako performance gate. Kluczowe jest oznaczenie tych jobów jako wymaganych sprawdzeń statusu w regułach ochrony gałęzi — dopiero wtedy zielony pipeline staje się warunkiem mergowania, a nie tylko informacją, którą można zignorować.

CI/CD dla Next.js — GitHub Actions, preview deployments i automatyczne testy

Po co CI/CD w projekcie Next.js?

Artykuł w skrócie

Minimum to lint, type check i build — nawet ten najprostszy pipeline gwarantuje, że nie wdrożysz kodu, który się nie kompiluje albo nie buduje; dla jednoosobowego projektu też ma sens.
Pełny pipeline dokłada testy — unit testy, E2E w Playwright i Lighthouse CI łapią regresje funkcjonalne i wydajnościowe, zanim trafią na produkcję.
Cache przyspiesza pipeline o połowę i więcej — cache zależności (pnpm) i cache .next/cache skracają czas z minut do ułamka przy niezmienionych plikach.
Lighthouse CI jako performance gate — progi w lighthouserc (np. performance ≥ 0.9) wywalą build, gdy wydajność spadnie, więc regresja nie przechodzi dalej.
Na Vercel CI to tylko testy — deploy jest automatyczny przy pushu na main; GitHub Actions służy do kontroli jakości, a nie do wdrażania.
Self-hosting dokłada job deploy — przez SSH albo obraz Docker, uruchamiany tylko po przejściu testów na gałęzi main; zawsze z weryfikacją, że aplikacja wstała.

Minimalna korzyść z : nigdy nie wdrożysz kodu, który nie przechodzi testów lub nie buduje się poprawnie.

Podstawowy pipeline — lint, test, build

Code

# .github/workflows/ci.yml
name: CI
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  quality:
    name: Code Quality
    runs-on: ubuntu-latest
 
    steps:
      - uses: actions/checkout@v4
 
      - uses: pnpm/action-setup@v4
        with:
          version: 9
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
 
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
 
      - name: Lint
        run: pnpm lint
 
      - name: Type check
        run: pnpm tsc --noEmit
 
      - name: Unit tests
        run: pnpm test
 
      - name: Build
        run: pnpm build
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
          NEXT_PUBLIC_APP_URL: https://strivelab.pl

Ten pipeline uruchamia się na każdym PR i pushu na main. Jeśli lint, type check, testy lub build failują — PR jest blokowany.

Cache zależności i build cache

Przyspieszenie pipeline'u o 50–70% dzięki cachowaniu:

Code

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
 
      - name: Cache Next.js build
        uses: actions/cache@v4
        with:
          path: |
            .next/cache
          key: nextjs-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}-${{ hashFiles('**/*.ts', '**/*.tsx') }}
          restore-keys: |
            nextjs-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}-
            nextjs-${{ runner.os }}-

Testy E2E z Playwright

Code

  e2e:
    name: E2E Tests
    runs-on: ubuntu-latest
    needs: quality # Uruchom po quality check
 
    steps:
      - uses: actions/checkout@v4
 
      - uses: pnpm/action-setup@v4
        with:
          version: 9
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
 
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
 
      - name: Install Playwright browsers
        run: pnpm exec playwright install --with-deps chromium
 
      - name: Build
        run: pnpm build
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
 
      - name: Run E2E tests
        run: pnpm exec playwright test
        env:
          BASE_URL: http://localhost:3000
 
      - name: Upload test results
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-report
          path: playwright-report/

Lighthouse CI — automatyczny audyt wydajności

Code

  lighthouse:
    name: Lighthouse CI
    runs-on: ubuntu-latest
    needs: quality
 
    steps:
      - uses: actions/checkout@v4
 
      - uses: pnpm/action-setup@v4
        with:
          version: 9
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
 
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
 
      - name: Build
        run: pnpm build
 
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          configPath: './lighthouserc.json'
          uploadArtifacts: true

Code

// lighthouserc.json
{
  "ci": {
    "collect": {
      "startServerCommand": "pnpm start",
      "url": ["http://localhost:3000", "http://localhost:3000/blog"],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "categories:accessibility": ["error", { "minScore": 0.9 }],
        "categories:best-practices": ["error", { "minScore": 0.9 }],
        "categories:seo": ["error", { "minScore": 0.9 }]
      }
    }
  }
}

Jeśli wynik Performance spadnie poniżej 90 — pipeline failuje. Wyłapujesz regresje wydajności, zanim trafią na produkcję. Lighthouse CI sam uruchamia serwer aplikacji dzięki startServerCommand w konfiguracji powyżej, więc nie musisz robić tego osobno.

Przy okazji warto domknąć konfigurację testów E2E z poprzedniej sekcji — żeby Playwright miał uruchomiony serwer, najczyściej zdefiniować webServer w playwright.config.ts:

Code

// playwright.config.ts
import { defineConfig } from '@playwright/test';
 
export default defineConfig({
  use: {
    baseURL: 'http://127.0.0.1:3000',
  },
  webServer: {
    command: 'pnpm start',
    url: 'http://127.0.0.1:3000',
    reuseExistingServer: !process.env.CI,
  },
});

Dzięki temu Playwright sam wystartuje aplikację przed testami w CI, a lokalnie wykorzysta już działający serwer, jeśli go masz.

Deploy na produkcję

Vercel — automatyczny

Na Vercel nie potrzebujesz workflow'u deploy — Vercel automatycznie deployuje każdy push na main. GitHub Actions używasz tylko do testów.

Self-hosted (Coolify/VPS) — SSH deploy

Code

  deploy:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: [quality, e2e]
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
 
    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /opt/apps/strivelab
            git pull origin main
            pnpm install --frozen-lockfile
            pnpm build
            pm2 restart strivelab
 
      - name: Verify deployment
        run: |
          sleep 10
          curl -f https://strivelab.pl || exit 1

Docker deploy

Code

  deploy:
    name: Build & Deploy Docker
    runs-on: ubuntu-latest
    needs: [quality]
    if: github.ref == 'refs/heads/main'
 
    steps:
      - uses: actions/checkout@v4
 
      - name: Login to registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
 
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:latest
 
      - name: Deploy to server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            docker pull ghcr.io/${{ github.repository }}:latest
            docker stop strivelab || true
            docker rm strivelab || true
            docker run -d --name strivelab \
              -p 3000:3000 \
              --env-file /opt/apps/.env \
              ghcr.io/${{ github.repository }}:latest

Preview deployments na Vercel

Każdy PR automatycznie dostaje na Vercel. Aby dodać komentarz z linkiem do PR:

Code

  preview-comment:
    name: Preview URL Comment
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - name: Wait for Vercel
        uses: patrickedqvist/wait-for-vercel-preview@v1.3.2
        id: vercel
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          max_timeout: 300
 
      - name: Comment PR
        uses: actions/github-script@v7
        with:
          script: |
            const previewUrl = '${{ steps.vercel.outputs.url }}';
 
            await github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `Preview: ${previewUrl}`
            });

Werdykt Labu

Dobry pipeline CI/CD dla Next.js buduje się warstwami. Minimum, które ma sens nawet w jednoosobowym projekcie, to lint, type check i build — gwarancja, że nie wdrożysz kodu, który się nie kompiluje. Na to dokładasz, w miarę dojrzewania projektu, testy jednostkowe, E2E w Playwright i Lighthouse CI jako performance gate, a cache zależności i .next/cache sprawiają, że to wszystko nadal mieści się w kilku minutach.

Strona deploymentu zależy od hostingu i tu reguła jest prosta. Na Vercel CI sprowadza się do kontroli jakości, bo wdrożenie i preview deployments dzieją się automatycznie; przy self-hostingu dokładasz job deploy przez SSH albo Docker, uruchamiany tylko po przejściu testów na main i zawsze z weryfikacją, że aplikacja wstała. Niezależnie od wariantu, sens całego pipeline'u realizuje się dopiero, gdy oznaczysz kluczowe joby jako wymagane sprawdzenia — wtedy zielony build naprawdę staje się warunkiem wejścia kodu na produkcję.

Chcesz ustawić solidny pipeline CI/CD dla projektu Next.js — od testów po automatyczny deploy? Napisz do mnie — pomagam budować procesy, które łapią błędy wcześnie i nie spowalniają zespołu.

Po co CI/CD w projekcie Next.js?

Artykuł w skrócie

Minimum to lint, type check i build — nawet ten najprostszy pipeline gwarantuje, że nie wdrożysz kodu, który się nie kompiluje albo nie buduje; dla jednoosobowego projektu też ma sens.
Pełny pipeline dokłada testy — unit testy, E2E w Playwright i Lighthouse CI łapią regresje funkcjonalne i wydajnościowe, zanim trafią na produkcję.
Cache przyspiesza pipeline o połowę i więcej — cache zależności (pnpm) i cache .next/cache skracają czas z minut do ułamka przy niezmienionych plikach.
Lighthouse CI jako performance gate — progi w lighthouserc (np. performance ≥ 0.9) wywalą build, gdy wydajność spadnie, więc regresja nie przechodzi dalej.
Na Vercel CI to tylko testy — deploy jest automatyczny przy pushu na main; GitHub Actions służy do kontroli jakości, a nie do wdrażania.
Self-hosting dokłada job deploy — przez SSH albo obraz Docker, uruchamiany tylko po przejściu testów na gałęzi main; zawsze z weryfikacją, że aplikacja wstała.

Minimalna korzyść z : nigdy nie wdrożysz kodu, który nie przechodzi testów lub nie buduje się poprawnie.

Podstawowy pipeline — lint, test, build

Code

# .github/workflows/ci.yml
name: CI
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  quality:
    name: Code Quality
    runs-on: ubuntu-latest
 
    steps:
      - uses: actions/checkout@v4
 
      - uses: pnpm/action-setup@v4
        with:
          version: 9
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
 
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
 
      - name: Lint
        run: pnpm lint
 
      - name: Type check
        run: pnpm tsc --noEmit
 
      - name: Unit tests
        run: pnpm test
 
      - name: Build
        run: pnpm build
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
          NEXT_PUBLIC_APP_URL: https://strivelab.pl

Ten pipeline uruchamia się na każdym PR i pushu na main. Jeśli lint, type check, testy lub build failują — PR jest blokowany.

Cache zależności i build cache

Przyspieszenie pipeline'u o 50–70% dzięki cachowaniu:

Code

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
 
      - name: Cache Next.js build
        uses: actions/cache@v4
        with:
          path: |
            .next/cache
          key: nextjs-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}-${{ hashFiles('**/*.ts', '**/*.tsx') }}
          restore-keys: |
            nextjs-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}-
            nextjs-${{ runner.os }}-

Testy E2E z Playwright

Code

  e2e:
    name: E2E Tests
    runs-on: ubuntu-latest
    needs: quality # Uruchom po quality check
 
    steps:
      - uses: actions/checkout@v4
 
      - uses: pnpm/action-setup@v4
        with:
          version: 9
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
 
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
 
      - name: Install Playwright browsers
        run: pnpm exec playwright install --with-deps chromium
 
      - name: Build
        run: pnpm build
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
 
      - name: Run E2E tests
        run: pnpm exec playwright test
        env:
          BASE_URL: http://localhost:3000
 
      - name: Upload test results
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-report
          path: playwright-report/

Lighthouse CI — automatyczny audyt wydajności

Code

  lighthouse:
    name: Lighthouse CI
    runs-on: ubuntu-latest
    needs: quality
 
    steps:
      - uses: actions/checkout@v4
 
      - uses: pnpm/action-setup@v4
        with:
          version: 9
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
 
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
 
      - name: Build
        run: pnpm build
 
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          configPath: './lighthouserc.json'
          uploadArtifacts: true

Code

// lighthouserc.json
{
  "ci": {
    "collect": {
      "startServerCommand": "pnpm start",
      "url": ["http://localhost:3000", "http://localhost:3000/blog"],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "categories:accessibility": ["error", { "minScore": 0.9 }],
        "categories:best-practices": ["error", { "minScore": 0.9 }],
        "categories:seo": ["error", { "minScore": 0.9 }]
      }
    }
  }
}

Przy okazji warto domknąć konfigurację testów E2E z poprzedniej sekcji — żeby Playwright miał uruchomiony serwer, najczyściej zdefiniować webServer w playwright.config.ts:

Code

// playwright.config.ts
import { defineConfig } from '@playwright/test';
 
export default defineConfig({
  use: {
    baseURL: 'http://127.0.0.1:3000',
  },
  webServer: {
    command: 'pnpm start',
    url: 'http://127.0.0.1:3000',
    reuseExistingServer: !process.env.CI,
  },
});

Dzięki temu Playwright sam wystartuje aplikację przed testami w CI, a lokalnie wykorzysta już działający serwer, jeśli go masz.

Deploy na produkcję

Vercel — automatyczny

Na Vercel nie potrzebujesz workflow'u deploy — Vercel automatycznie deployuje każdy push na main. GitHub Actions używasz tylko do testów.

Self-hosted (Coolify/VPS) — SSH deploy

Code

  deploy:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: [quality, e2e]
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
 
    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /opt/apps/strivelab
            git pull origin main
            pnpm install --frozen-lockfile
            pnpm build
            pm2 restart strivelab
 
      - name: Verify deployment
        run: |
          sleep 10
          curl -f https://strivelab.pl || exit 1

Docker deploy

Code

  deploy:
    name: Build & Deploy Docker
    runs-on: ubuntu-latest
    needs: [quality]
    if: github.ref == 'refs/heads/main'
 
    steps:
      - uses: actions/checkout@v4
 
      - name: Login to registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
 
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:latest
 
      - name: Deploy to server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            docker pull ghcr.io/${{ github.repository }}:latest
            docker stop strivelab || true
            docker rm strivelab || true
            docker run -d --name strivelab \
              -p 3000:3000 \
              --env-file /opt/apps/.env \
              ghcr.io/${{ github.repository }}:latest

Preview deployments na Vercel

Każdy PR automatycznie dostaje na Vercel. Aby dodać komentarz z linkiem do PR:

Code

  preview-comment:
    name: Preview URL Comment
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - name: Wait for Vercel
        uses: patrickedqvist/wait-for-vercel-preview@v1.3.2
        id: vercel
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          max_timeout: 300
 
      - name: Comment PR
        uses: actions/github-script@v7
        with:
          script: |
            const previewUrl = '${{ steps.vercel.outputs.url }}';
 
            await github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `Preview: ${previewUrl}`
            });

CI/CD dla Next.js — GitHub Actions, preview deployments i automatyczne testy

Po co CI/CD w projekcie Next.js?

Podstawowy pipeline — lint, test, build

Cache zależności i build cache

Testy E2E z Playwright

Lighthouse CI — automatyczny audyt wydajności

Deploy na produkcję

Vercel — automatyczny

Self-hosted (Coolify/VPS) — SSH deploy

Docker deploy

Preview deployments na Vercel

Czytaj dalej

CI/CD dla Next.js — GitHub Actions, preview deployments i automatyczne testy

Po co CI/CD w projekcie Next.js?

Podstawowy pipeline — lint, test, build

Cache zależności i build cache

Testy E2E z Playwright

Lighthouse CI — automatyczny audyt wydajności

Deploy na produkcję

Vercel — automatyczny

Self-hosted (Coolify/VPS) — SSH deploy

Docker deploy

Preview deployments na Vercel

Czytaj dalej