CI/CD Pipeline – automatyzacja wdrożeń w 2026

TL;DR

CI/CD (Continuous Integration/Continuous Deployment) automatyzuje testy, build i wdrożenia. Zmniejsza błędy, przyspiesza development i poprawia jakość kodu. Oto jak skonfigurować CI/CD pipeline w 2026.

Dla kogo to jest

• Deweloperów chcących automatyzować wdrożenia
• Firm planujących DevOps practices
• Zespołów pracujących nad wieloma projektami

Fraza (SEO)

ci cd pipeline, continuous integration, continuous deployment, github actions, devops automation

Czym jest CI/CD?

CI (Continuous Integration):

• Automatyczne testy przy każdym commit
• Wykrywanie błędów wcześnie
• Automatyczny build
• Code quality checks

CD (Continuous Deployment/Delivery):

• Automatyczne wdrożenia
• Zero-downtime deployments
• Rollback capabilities
• Environment management

Korzyści:

• Szybsze wdrożenia
• Mniej błędów w produkcji
• Lepsza jakość kodu
• Większa pewność zmian

Workflow CI/CD

1. Developer pushuje kod

git add .
git commit -m "Add new feature"
git push origin main

2. CI Pipeline uruchamia się automatycznie

Kroki:

1. Lint check (ESLint, Prettier)
2. Unit tests
3. Integration tests
4. Build aplikacji
5. Security scan
6. Deploy do staging

3. CD Pipeline wdraża do produkcji

Po sukcesie CI:

1. Deploy do production
2. Smoke tests
3. Health checks
4. Rollback jeśli błąd

GitHub Actions

Podstawowa konfiguracja

.github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    
    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 tests
      run: npm test
    
    - name: Build
      run: npm run build

Deployment workflow

.github/workflows/deploy.yml:

name: Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: test
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Build
      run: npm run build
    
    - name: Deploy to production
      run: |
        # Twój deployment script
        npm run deploy
      env:
        DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

Matrix builds (wiele wersji)

jobs:
  test:
    strategy:
      matrix:
        node-version: [16, 18, 20]
        os: [ubuntu-latest, windows-latest, macos-latest]
    
    runs-on: ${{ matrix.os }}
    
    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 ci
    - run: npm test

GitLab CI

Podstawowa konfiguracja

.gitlab-ci.yml:

stages:
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "18"

before_script:
  - npm ci

test:
  stage: test
  script:
    - npm run lint
    - npm test
  only:
    - merge_requests
    - main

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour
  only:
    - main

deploy_staging:
  stage: deploy
  script:
    - npm run deploy:staging
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - develop

deploy_production:
  stage: deploy
  script:
    - npm run deploy:production
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - main

Jenkins

Jenkinsfile (Pipeline as Code)

pipeline {
    agent any
    
    environment {
        NODE_VERSION = '18'
        DEPLOY_ENV = 'production'
    }
    
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }
        
        stage('Test') {
            steps {
                sh 'npm run lint'
                sh 'npm test'
            }
        }
        
        stage('Build') {
            steps {
                sh 'npm run build'
            }
        }
        
        stage('Deploy') {
            steps {
                sh 'npm run deploy'
            }
        }
    }
    
    post {
        success {
            echo 'Pipeline succeeded!'
        }
        failure {
            echo 'Pipeline failed!'
        }
    }
}

Best Practices

1. Fast Feedback

Szybkie testy:

• Uruchamiaj szybkie testy najpierw
• Długie testy w osobnych jobach
• Parallel execution

jobs:
  quick-tests:
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:unit  # Szybkie
  
  slow-tests:
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:e2e   # Wolne

2. Cache dependencies

Szybsze buildy:

- name: Cache node modules
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

3. Environment variables

Bezpieczne secrets:

env:
  DATABASE_URL: ${{ secrets.DATABASE_URL }}
  API_KEY: ${{ secrets.API_KEY }}

Nie commituj:

• API keys
• Passwords
• Private keys
• Tokens

4. Conditional deployments

Deploy tylko z main:

deploy:
  if: github.ref == 'refs/heads/main'
  steps:
    - run: npm run deploy

Manual approval:

deploy_production:
  when: manual  # GitLab CI
  # Lub w GitHub Actions użyj environment protection rules

5. Rollback strategy

Automatyczny rollback:

- name: Deploy
  run: npm run deploy

- name: Health check
  run: |
    sleep 30
    curl -f https://example.com/health || exit 1

- name: Rollback on failure
  if: failure()
  run: npm run rollback

6. Notifications

Powiadomienia o statusie:

- name: Notify on failure
  if: failure()
  uses: 8398a7/action-slack@v3
  with:
    status: failure
    text: 'Deployment failed!'
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

Deployment strategies

1. Blue-Green Deployment

Dwa środowiska:

• Blue (produkcja)
• Green (nowa wersja)

Proces:

1. Deploy do Green
2. Testy na Green
3. Switch traffic Blue → Green
4. Blue jako backup

Zalety:

• Zero downtime
• Szybki rollback
• Bezpieczne wdrożenia

2. Canary Deployment

Stopniowe wdrożenie:

1. Deploy do małej części użytkowników (5%)
2. Monitorowanie
3. Stopniowe zwiększanie (25%, 50%, 100%)
4. Rollback jeśli problemy

Zalety:

• Wykrywanie problemów wcześnie
• Minimalny impact
• Bezpieczne testy w produkcji

3. Rolling Deployment

Stopniowe aktualizacje:

1. Aktualizuj serwery jeden po drugim
2. Każdy serwer offline krótko
3. Health checks między aktualizacjami

Zalety:

• Zero downtime (dla wielu serwerów)
• Proste wdrożenie
• Resource efficient

Monitoring i alerting

Health checks

- name: Health check
  run: |
    for i in {1..10}; do
      if curl -f https://example.com/health; then
        echo "Health check passed"
        exit 0
      fi
      sleep 10
    done
    echo "Health check failed"
    exit 1

Metrics

Monitoruj:

• Deployment success rate
• Build time
• Test coverage
• Error rate po deploy

FAQ

Jak długo trwa setup CI/CD?

Dla prostego projektu: 1-2 dni. Dla złożonego: tydzień. Warto inwestować czas - oszczędza go długoterminowo.

Czy CI/CD jest potrzebne dla małych projektów?

Tak, nawet dla małych projektów. GitHub Actions jest darmowy dla publicznych repo, GitLab CI też ma darmowy tier.

Jak często deployować?

Zależy od projektu. Niektóre firmy deployują wiele razy dziennie. Ważne: małe, częste deployy są bezpieczniejsze niż duże, rzadkie.

Chcesz skonfigurować CI/CD dla swojego projektu?

• Kontakt