Jenkins vs GitLab CI vs GitHub Actions - ktore narzedzie CI/CD wybrac?

Continuous Integration i Continuous Delivery (CI/CD) to fundamenty nowoczesnego procesu wytwarzania oprogramowania. Automatyzacja budowania, testowania i wdrazania kodu pozwala zespolom dostarczac oprogramowanie szybciej, bezpieczniej i z wieksza powtarzalnoscia. Wybor odpowiedniego narzedzia CI/CD ma bezposredni wplyw na produktywnosc zespolu, koszty infrastruktury i jakosc dostarczanego oprogramowania.

W tym artykule szczegolowo porownujemy trzy najpopularniejsze platformy CI/CD: Jenkins - weterana automatyzacji, GitLab CI/CD - zintegrowane rozwiazanie platformowe oraz GitHub Actions - nowoczesne narzedzie wbudowane w najpopularniejszy hosting repozytoriow. Analizujemy kazde z nich pod katem architektury, skladni pipeline'ow, integracji z Docker, zarzadzania sekretami, kosztow i przypadkow uzycia, abys mogl podjac swiadoma decyzje.

Architektura - jak dzialaja pod maska#

Jenkins - architektura Master-Agent#

Jenkins opiera sie na modelu Master-Agent (dawniej Master-Slave). Serwer glowny (controller) zarzadza konfiguracja, harmonogramem zadan i interfejsem webowym, natomiast agenci (nodes) wykonuja faktyczne zadania budowania. Ta architektura pozwala na rozproszone wykonywanie pipeline'ow na roznych maszynach i systemach operacyjnych.

Kluczowe elementy architektury Jenkins:

Controller (Master) - centralny serwer zarzadzajacy kolejka zadan, konfiguracja i UI
Agents (Nodes) - maszyny wykonujace buildy, polaczone przez SSH, JNLP lub WebSocket
Executors - watki na agentach, kazdy obsluguje jeden build jednoczesnie
Plugins - ponad 1800 wtyczek rozszerzajacych funkcjonalnosc bazowego systemu
Shared Libraries - wspoldzielone biblioteki Groovy do reuzywania logiki pipeline'ow

Jenkins wymaga samodzielnej instalacji na serwerze (fizycznym, VM lub kontenerze). Nie oferuje natywnego rozwiazania chmurowego - zawsze musisz zarzadzac wlasna infrastruktura.

GitLab CI/CD - zintegrowana platforma DevOps#

GitLab CI/CD jest wbudowany bezposrednio w platforme GitLab, co oznacza, ze nie musisz konfigurowac oddzielnego systemu CI/CD. Architektura opiera sie na GitLab Runners - lekkich agentach wykonujacych joby zdefiniowane w pliku .gitlab-ci.yml.

Kluczowe elementy architektury GitLab CI/CD:

GitLab Server - zarzadza pipeline'ami, przechowuje konfiguracje i wyniki
GitLab Runners - agenci wykonujacy joby (shared, group lub project runners)
Executors - sposob uruchamiania jobow: Shell, Docker, Docker Machine, Kubernetes, VirtualBox
Container Registry - wbudowany rejestr obrazow Docker
Artifacts & Cache - natywne przechowywanie artefaktow i cache'u miedzy jobami

GitLab oferuje model hybrydowy: mozesz korzystac z gitlab.com (SaaS) lub zainstalowac GitLab self-hosted (CE/EE). Runners moga byc wspoldzielone (GitLab-hosted) lub prywatne.

GitHub Actions - event-driven automation#

GitHub Actions przyjmuje architekture event-driven - workflow'y sa wyzwalane przez zdarzenia w repozytorium (push, pull request, release, issue, cron i inne). Kazdy workflow sklada sie z jobow, a kazdy job z krokow (steps).

Kluczowe elementy architektury GitHub Actions:

Workflows - pliki YAML w katalogu .github/workflows/ definiujace automatyzacje
Jobs - grupy krokow uruchamiane na jednym runnerze, domyslnie rownolegle
Steps - pojedyncze polecenia lub akcje (actions) z Marketplace
Runners - maszyny wykonujace joby: GitHub-hosted (Ubuntu, Windows, macOS) lub self-hosted
Actions - reuzywalne komponenty z Marketplace lub wlasnych repozytoriow

GitHub Actions jest natywnie zintegrowany z GitHubem i dzialal domyslnie w chmurze. Self-hosted runners sa opcjonalne dla specjalnych wymagan.

Skladnia pipeline'ow - porownanie#

Jednym z najwazniejszych aspektow przy wyborze narzedzia CI/CD jest skladnia definiowania pipeline'ow. Kazde z trzech narzedzi oferuje inne podejscie.

Jenkins - Jenkinsfile (Groovy)#

Jenkins oferuje dwa typy pipeline'ow: deklaratywny (prostszy, strukturalny) i skryptowy (pelna moc Groovy). Jenkinsfile zyje w repozytorium obok kodu.

// Jenkinsfile - deklaratywny pipeline
pipeline {
    agent {
        docker {
            image 'node:20-alpine'
        }
    }

    environment {
        CI = 'true'
        NODE_ENV = 'test'
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Unit Tests') {
                    steps {
                        sh 'npm run test:unit'
                        junit 'reports/junit.xml'
                    }
                }
                stage('Integration Tests') {
                    steps {
                        sh 'npm run test:integration'
                    }
                }
            }
        }

        stage('Build') {
            steps {
                sh 'npm run build'
                archiveArtifacts artifacts: 'dist/**/*'
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                withCredentials([string(credentialsId: 'deploy-token', variable: 'TOKEN')]) {
                    sh './scripts/deploy.sh'
                }
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build Failed: ${env.JOB_NAME}",
                 body: "Check: ${env.BUILD_URL}"
        }
        always {
            cleanWs()
        }
    }
}

Zalety skladni Jenkins: Pelna moc jezyka programowania (Groovy), mozliwosc tworzenia zlozonych warunkow i petli, shared libraries do wspoldzielenia logiki.

Wady: Stroma krzywa uczenia Groovy, trudniejsze debugowanie, brak natywnego auto-complete w IDE.

GitLab CI/CD - .gitlab-ci.yml (YAML)#

GitLab definiuje pipeline'y w pliku .gitlab-ci.yml w katalogu glownym repozytorium. Skladnia jest deklaratywna i oparta na YAML.

# .gitlab-ci.yml
image: node:20-alpine

variables:
  CI: "true"
  NODE_ENV: test

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - .npm/

stages:
  - install
  - test
  - build
  - deploy

install:
  stage: install
  script:
    - npm ci --cache .npm

lint:
  stage: test
  script:
    - npm run lint
  needs: [install]

unit-tests:
  stage: test
  script:
    - npm run test:unit
  artifacts:
    reports:
      junit: reports/junit.xml
  needs: [install]

integration-tests:
  stage: test
  script:
    - npm run test:integration
  services:
    - postgres:15
    - redis:7
  needs: [install]

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

deploy-production:
  stage: deploy
  script:
    - ./scripts/deploy.sh
  environment:
    name: production
    url: https://example.com
  only:
    - main
  when: manual

Zalety skladni GitLab CI: Czytelny YAML, proste definiowanie serwisow (bazy danych, cache), wbudowane srodowiska, slowo kluczowe needs do tworzenia DAG.

Wady: YAML moze byc rozwlekly, ograniczone mozliwosci logiki warunkowej (rules vs only/except), trudniejsze debugowanie zlozonych pipeline'ow.

GitHub Actions - workflow YAML#

GitHub Actions definiuje workflow'y w plikach YAML w katalogu .github/workflows/. Kazdy plik to oddzielny workflow z wlasnymi triggerami.

# .github/workflows/ci.yml
name: CI/CD Pipeline

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

env:
  CI: true
  NODE_ENV: test

jobs:
  install:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci

  lint:
    needs: install
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    needs: install
    runs-on: ubuntu-latest
    strategy:
      matrix:
        test-type: [unit, integration]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run test:${{ matrix.test-type }}

  build:
    needs: [lint, test]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: dist/
      - run: ./scripts/deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Zalety skladni GitHub Actions: Intuicyjny YAML, reuzywalne akcje z Marketplace, matrix builds, wyrazne trigery na eventy, wbudowane expressions.

Wady: Kazdy job uruchamia nowy runner (brak wspoldzielenia stanu), pliki moga byc rozwlekle przy zlozonych workflow'ach.

Konfiguracja i latwosci startu#

Jenkins - wymaga najwiecej pracy#

Ustawienie Jenkinsa od zera wymaga:

Zainstalowania Javy (JDK 11+) na serwerze
Pobrania i uruchomienia Jenkins WAR lub pakietu systemowego
Przejscia przez kreator konfiguracji (wybor pluginow, utworzenie admina)
Skonfigurowania agentow budowania
Utworzenia pipeline'u i polaczenia z repozytorium
Skonfigurowania webhookow dla automatycznych triggerow

Czas do pierwszego dzialajacego pipeline'u: 1-4 godziny (wiecej jesli potrzebujesz agentow Docker/Kubernetes).

GitLab CI/CD - srednia zlozonosc#

Jesli korzystasz z gitlab.com:

Utworzenie pliku .gitlab-ci.yml w repozytorium
Pipeline automatycznie startuje przy kolejnym pushu

Jesli korzystasz z self-hosted GitLab:

Instalacja GitLab (Omnibus, Docker lub Helm)
Rejestracja runnera (gitlab-runner register)
Utworzenie .gitlab-ci.yml

Czas do pierwszego pipeline'u: 5-15 minut (gitlab.com) lub 1-2 godziny (self-hosted).

GitHub Actions - najszybszy start#

Utworzenie pliku .github/workflows/ci.yml w repozytorium
Push na GitHub
Pipeline automatycznie startuje

GitHub oferuje rowniez gotowe szablony pipeline'ow (starter workflows) dla popularnych jezykow i frameworkow.

Czas do pierwszego pipeline'u: 2-5 minut.

Self-hosted vs Cloud - modele hostingu#

Jenkins - wylacznie self-hosted#

Jenkins jest z natury rozwiazaniem self-hosted. Musisz samodzielnie zarzadzac infrastruktura, aktualizacjami, bezpieczenstwem i skalowaniem. To daje pelna kontrole, ale wymaga dedykowanego zespolu DevOps.

Zalety: Pelna kontrola nad danymi i infrastruktura, brak limitow na minuty budowania, mozliwosc pracy w sieciach air-gapped, zgodnosc z rygorystycznymi wymogami compliance.

Wady: Koszty utrzymania infrastruktury (serwery, monitoring, backupy), odpowiedzialnosc za bezpieczenstwo i aktualizacje, koniecznosc recznego skalowania, potrzeba dedykowanego administratora.

GitLab CI/CD - model hybrydowy#

GitLab oferuje dwa modele: w pelni zarzadzana chmura (gitlab.com) lub instalacja self-hosted (GitLab CE/EE). Runnery moga byc zarowno wspoldzielone (GitLab-hosted), jak i prywatne (self-hosted). To daje ogromna elastycznosc - mozesz np. korzystac z gitlab.com do hostingu kodu, ale uruchamiac buildy na wlasnych runnerach.

Zalety: Elastyczny wybor miedzy chmura a self-hosted, mozliwosc mieszania runnerow, wbudowany Container Registry, Auto DevOps dla automatycznej konfiguracji.

Wady: Wspoldzielone runnery moga byc wolne i maja ograniczone zasoby, self-hosted wymaga zarzadzania, wersja Ultimate jest kosztowna.

GitHub Actions - cloud-first z opcja self-hosted#

GitHub Actions dziala domyslnie w chmurze na GitHub-hosted runnerach (Ubuntu, Windows, macOS). Runnery maja preinstalowane popularne narzedzia (Docker, Node.js, Python, Java, .NET). Self-hosted runners sa opcja dla specjalnych wymagan (GPU, specyficzny hardware, sieci prywatne).

Zalety: Zero konfiguracji infrastruktury, gotowe srodowiska z preinstalowanymi narzedziami, automatyczne aktualizacje, natywna integracja z GitHub.

Wady: Limity na minuty w darmowym planie, macOS runners sa drogie, ograniczona kontrola nad srodowiskiem hosted runners, self-hosted runners wymagaja dodatkowej konfiguracji bezpieczenstwa.

Ekosystem wtyczek i Marketplace#

Jenkins - krol wtyczek#

Z ponad 1800 wtyczkami Jenkins oferuje najszerszy ekosystem rozszerzen wsrod wszystkich narzedzi CI/CD. Znajdziesz pluginy do integracji z praktycznie kazdym narzedziem: SonarQube, Artifactory, AWS, Azure, GCP, Slack, Jira, Docker, Kubernetes i wieloma innymi.

// Przyklad uzycia wtyczki Docker w Jenkinsfile
pipeline {
    agent {
        docker {
            image 'maven:3.9-eclipse-temurin-21'
            args '-v $HOME/.m2:/root/.m2'
        }
    }
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package -DskipTests'
            }
        }
        stage('SonarQube Analysis') {
            steps {
                withSonarQubeEnv('sonar-server') {
                    sh 'mvn sonar:sonar'
                }
            }
        }
    }
}

Minusy: Jakosc wtyczek bywa nierownomierna, niektore sa porzucone lub nieaktualne, konflikty miedzy wersjami wtyczek sa czestzym problemem, aktualizacje wtyczek moga zepszuc istniejace pipeline'y.

GitLab CI/CD - wbudowana funkcjonalnosc#

GitLab stawia na wbudowana funkcjonalnosc zamiast wtyczek. Wiekszosc funkcji (Container Registry, Package Registry, Security Scanning, Monitoring, Wiki, Issue Tracker) jest czescia platformy. Dostepne sa rowniez szablony CI/CD, ktore mozna importowac i rozszerzac.

# Uzycie gotowego szablonu GitLab
include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Code-Quality.gitlab-ci.yml

# Nadpisanie konfiguracji szablonu
sast:
  variables:
    SAST_EXCLUDED_PATHS: "tests/, docs/"

Zalety: Spatna integracja miedzy funkcjami, brak problemow z kompatybilnoscia wtyczek, jednolity interfejs.

Wady: Mniej elastyczne niz system wtyczek, zaawansowane funkcje (SAST, DAST) dostepne tylko w drogim planie Ultimate.

GitHub Actions - Marketplace#

GitHub Actions Marketplace oferuje tysiac gotowych akcji stworzonych przez spolecznosc, dostawcow i sam GitHub. Kazda akcja to repozytorium GitHub, ktore mozna przegladzac, forkowac i modyfikowac.

# Przyklad uzycia akcji z Marketplace
steps:
  - uses: docker/build-push-action@v5
    with:
      context: .
      push: true
      tags: myapp:latest
      cache-from: type=gha
      cache-to: type=gha,mode=max

  - uses: sonarsource/sonarqube-scan-action@v2
    env:
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

  - uses: slackapi/slack-github-action@v1
    with:
      payload: '{"text": "Deploy completed!"}'
    env:
      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

Zalety: Ogromna spolecznosc, latwe tworzenie wlasnych akcji (Docker lub JavaScript), wersjonowanie akcji (pinning do SHA), reusable workflows.

Wady: Ryzyko supply chain attacks (trzeba audytowac uzywane akcje), niektorzy dostawcy porzucaja swoje akcje, brak centralnej kontroli jakosci.

Model cenowy#

Jenkins - darmowy, ale koszty infrastruktury#

Jenkins jest calkowicie darmowy i open-source (licencja MIT). Jednak realne koszty obejmuja:

Infrastrukture (serwery, storage, siec) - od 100 do 1000+ USD/mies.
Czas zespolu na utrzymanie, aktualizacje i rozwiazywanie problemow
Ewentualne komercyjne dystrybucje (CloudBees CI) - od 3000 USD/rok

Szacunkowy koszt miesieczny dla zespolu 10 deweloperow: 200-800 USD za infrastrukture plus koszty roboczogodzin DevOps.

GitLab CI/CD#

| Plan | Cena/uzytk./mies. | Minuty CI/mies. | Kluczowe funkcje CI/CD | |------|-------------------|-----------------|----------------------| | Free | 0 USD | 400 min | Podstawowe CI/CD, 5 GB storage | | Premium | 29 USD | 10 000 min | Merge trains, Code Review, Protected Environments | | Ultimate | 99 USD | 50 000 min | SAST/DAST, Security Dashboard, Compliance |

Dodatkowe minuty: Linux 0.005 USD/min, Windows 0.01 USD/min, macOS - niedostepne na shared runners.

GitHub Actions#

| Plan | Cena | Minuty/mies. | Storage | |------|------|-------------|---------| | Free | 0 USD | 2 000 min | 500 MB | | Team | 4 USD/uzytk. | 3 000 min | 2 GB | | Enterprise | 21 USD/uzytk. | 50 000 min | 50 GB |

Dodatkowe minuty: Linux 0.008 USD/min, Windows 0.016 USD/min, macOS 0.08 USD/min.

Wazne: Projekty open-source na GitHubie maja nieograniczone darmowe minuty na publicznych repozytoriach.

Integracja z Docker#

Wszystkie trzy narzedzia doskonale integruja sie z Docker, ale na rozne sposoby.

Jenkins + Docker#

Jenkins moze uruchamiac pipeline'y wewnatrz kontenerow Docker (agent docker), budowac obrazy i pushowac je do rejestrow. Wymaga zainstalowanego Dockera na agencie i odpowiedniego pluginu Docker Pipeline.

// Jenkins - budowanie multi-stage Docker image
pipeline {
    agent any
    stages {
        stage('Build & Push') {
            steps {
                script {
                    def image = docker.build("myapp:${env.BUILD_NUMBER}")
                    docker.withRegistry('https://registry.example.com', 'registry-credentials') {
                        image.push()
                        image.push('latest')
                    }
                }
            }
        }
    }
}

GitLab CI/CD + Docker#

GitLab oferuje natywna integracje z Docker, wlacznie z wbudowanym Container Registry. Kazde repozytorium ma wlasny rejestr obrazow. Uslugi (services) pozwalaja na uruchomienie dodatkowych kontenerow podczas budowania.

# GitLab CI - budowanie i pushowanie obrazu Docker
build-image:
  image: docker:24.0
  services:
    - docker:24.0-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker build -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

GitHub Actions + Docker#

GitHub Actions oferuje preinstalowanego Dockera na runnerach Linux. Dedykowane akcje upraszczaja budowanie i pushowanie obrazow. GitHub Packages (ghcr.io) sluzy jako rejestr kontenerow.

# GitHub Actions - budowanie i pushowanie Docker image
build-image:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}

    - uses: docker/build-push-action@v5
      with:
        context: .
        push: true
        tags: |
          ghcr.io/${{ github.repository }}:${{ github.sha }}
          ghcr.io/${{ github.repository }}:latest
        cache-from: type=gha
        cache-to: type=gha,mode=max

Rownolegle wykonywanie zadan i Matrix builds#

Rownolegle uruchamianie zadan drastycznie skraca czas pipeline'u. Matrix builds pozwalaja testowac na wielu wersjach jednoczesnie.

Jenkins - parallel i matrix#

// Jenkins - matrix build
pipeline {
    agent none
    stages {
        stage('Test Matrix') {
            matrix {
                axes {
                    axis {
                        name 'NODE_VERSION'
                        values '18', '20', '22'
                    }
                    axis {
                        name 'OS'
                        values 'linux', 'windows'
                    }
                }
                stages {
                    stage('Test') {
                        agent {
                            label "${OS}"
                        }
                        steps {
                            sh "nvm use ${NODE_VERSION} && npm test"
                        }
                    }
                }
            }
        }
    }
}

GitLab CI/CD - parallel matrix#

# GitLab - matrix build
test:
  stage: test
  image: node:${NODE_VERSION}-alpine
  parallel:
    matrix:
      - NODE_VERSION: ['18', '20', '22']
        DATABASE: ['postgres', 'mysql']
  script:
    - npm ci
    - npm test
  services:
    - name: ${DATABASE}:latest

GitHub Actions - strategy matrix#

# GitHub Actions - matrix build
test:
  runs-on: ${{ matrix.os }}
  strategy:
    fail-fast: false
    matrix:
      os: [ubuntu-latest, windows-latest, macos-latest]
      node-version: [18, 20, 22]
      exclude:
        - os: macos-latest
          node-version: 18
      include:
        - os: ubuntu-latest
          node-version: 22
          coverage: true
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test
    - if: matrix.coverage
      run: npm run test:coverage

GitHub Actions oferuje najbardziej intuicyjna skladnie matrix builds z wbudowana obsluga include, exclude i fail-fast.

Zarzadzanie sekretami#

Bezpieczne przechowywanie i uzycie tajnych wartosci (klucze API, hasla, certyfikaty) to krytyczny aspekt kazdego pipeline'u CI/CD.

Jenkins - Credentials Store#

Jenkins przechowuje sekrety w wewnetrznym Credential Store, ktory szyfruje wartosci na dysku za pomoca klucza specyficznego dla instancji. Wspiera rozne typy: hasla, tokeny, certyfikaty SSH, pliki, certyfikaty X.509. Integracja z zewnetrznymi dostawcami (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) wymaga dodatkowych pluginow.

// Jenkins - uzycie roznych typow sekretow
pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                withCredentials([
                    string(credentialsId: 'api-token', variable: 'API_TOKEN'),
                    usernamePassword(credentialsId: 'db-creds', usernameVariable: 'DB_USER', passwordVariable: 'DB_PASS'),
                    file(credentialsId: 'kubeconfig', variable: 'KUBECONFIG')
                ]) {
                    sh './deploy.sh'
                }
            }
        }
    }
}

GitLab CI/CD - zmienne CI/CD#

GitLab oferuje zmienne CI/CD na poziomie projektu, grupy lub instancji. Zmienne moga byc oznaczone jako "masked" (ukryte w logach) i "protected" (dostepne tylko na chronionych branchach). Integracja z HashiCorp Vault jest wbudowana w plan Premium.

# GitLab - uzycie zmiennych chronionych i Vault
deploy:
  script:
    - echo "$KUBE_CONFIG" | base64 -d > kubeconfig
    - kubectl --kubeconfig=kubeconfig apply -f k8s/
  variables:
    KUBE_CONFIG: $KUBE_CONFIG  # Zmienna protected + masked
  secrets:
    DATABASE_PASSWORD:
      vault:
        engine:
          name: kv-v2
          path: secret
        path: production/db
        field: password
  only:
    - main

GitHub Actions - GitHub Secrets#

GitHub Secrets sa dostepne na poziomie repozytorium, srodowiska (environment) i organizacji. Wartosci sa szyfrowane za pomoca libsodium i automatycznie maskowane w logach. Srodowiska (environments) pozwalaja na dodatkowa kontrole: wymagane zatwierdzenie przez recenzentow, opoznienie czasowe (wait timer), ograniczenie do konkretnych galezi.

# GitHub Actions - sekrety i srodowiska
deploy:
  runs-on: ubuntu-latest
  environment:
    name: production
    url: https://example.com
  steps:
    - uses: actions/checkout@v4
    - uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - run: az webapp deploy --name myapp --src-path dist/
    - uses: actions/github-script@v7
      with:
        script: |
          await github.rest.repos.createDeploymentStatus({
            owner: context.repo.owner,
            repo: context.repo.repo,
            deployment_id: context.payload.deployment.id,
            state: 'success'
          });

Tabela porownawcza#

| Kryterium | Jenkins | GitLab CI/CD | GitHub Actions | |-----------|:-------:|:------------:|:--------------:| | Model hostingu | Self-hosted | Cloud + Self-hosted | Cloud + Self-hosted | | Skladnia pipeline | Groovy (Jenkinsfile) | YAML (.gitlab-ci.yml) | YAML (workflow) | | Krzywa uczenia | Stroma | Umiarkowana | Lagodna | | Czas do pierwszego pipeline | 1-4 godz. | 5-15 min (SaaS) | 2-5 min | | Ekosystem | 1800+ pluginow | Wbudowane + szablony | Marketplace (tysiac akcji) | | Docker | Bardzo dobra (plugin) | Doskonala (natywna) | Doskonala (natywna) | | Container Registry | Brak (zewnetrzny) | Wbudowany | GitHub Packages (ghcr.io) | | Matrix builds | Tak (od Jenkins 2.x) | Tak (parallel:matrix) | Tak (strategy:matrix) | | Sekrety | Credential Store + pluginy | Zmienne CI/CD + Vault | GitHub Secrets + Environments | | Artefakty | archiveArtifacts | Wbudowane (expire_in) | actions/upload-artifact | | Cache | Pluginy (Job Cacher) | Wbudowany (key/paths) | actions/cache | | Darmowe minuty | Bez limitu (self-hosted) | 400 min/mies. | 2 000 min/mies. | | Security scanning | Pluginy | Wbudowane (Ultimate) | Marketplace + Dependabot | | Srodowiska | Pluginy | Wbudowane | Wbudowane | | Wsparcie spolecznosci | Ogromne (legacy) | Duze i rosnace | Bardzo duze |

Kiedy wybrac kazde narzedzie?#

Wybierz Jenkins, gdy:#

Potrzebujesz pelnej kontroli nad infrastruktura CI/CD i nie chcesz zalezec od dostawcy chmury
Pracujesz w srodowisku air-gapped lub z rygorystycznymi wymogami bezpieczenstwa i compliance
Masz zlozony, niestandardowy proces budowania wymagajacy maksymalnej elastycznosci Groovy
Twoj zespol ma doswiadczenie z Jenkinsem i istniejaca, dzialajaca infrastrukture
Potrzebujesz integracji z egzotycznymi narzedziami, dla ktorych istnieja pluginy Jenkins
Budzet na infrastrukture jest dostepny, ale chcesz uniknac oplat per-user

Wybierz GitLab CI/CD, gdy:#

Szukasz zintegrowanej platformy DevOps (kod + CI/CD + Container Registry + monitoring + security w jednym)
Potrzebujesz wbudowanych narzedzi bezpieczenstwa (SAST, DAST, dependency scanning, container scanning)
Chcesz elastycznosci miedzy chmura a self-hosted z mozliwoscia migracji
Zarzadzasz wieloma projektami i grupami i potrzebujesz hierarchicznego zarzadzania
Cenisz Auto DevOps - automatyczne wykrywanie jezyka i konfiguracje pipeline'u
Potrzebujesz wbudowanego Container Registry i Package Registry

Wybierz GitHub Actions, gdy:#

Twoj kod jest juz na GitHubie i chcesz najprostszej mozliwej integracji CI/CD
Potrzebujesz szybkiego startu bez konfiguracji infrastruktury - dzialajacy pipeline w 5 minut
Chcesz korzystac z bogatego ekosystemu gotowych akcji z Marketplace
Budujesz projekty open-source - darmowe minuty bez limitow na publicznych repozytoriach
Potrzebujesz matrix builds testujacych na wielu systemach operacyjnych jednoczesnie
Cenisz event-driven automation - nie tylko CI/CD, ale tez automatyzacje issues, releases, PR

Migracja miedzy narzedziami#

Jesli rozwazsz migracje z jednego narzedzia na inne, warto wiedziec o dostepnych narzedziach:

Jenkins do GitHub Actions: GitHub oferuje oficjalny Actions Importer konwertujacy Jenkinsfile na workflow YAML
Jenkins do GitLab CI: GitLab oferuje Jenkins CI migration guide
GitLab do GitHub Actions: Wymaga recznej konwersji, ale skladnia YAML jest podobna
GitHub Actions do GitLab CI: Podobnie - reczna konwersja z uzyciem dokumentacji GitLab

W kazdym przypadku migracja wymaga tez przeniesienia sekretow, konfiguracji srodowisk i dostosowania integracji.

Podsumowanie#

Nie istnieje jedno "najlepsze" narzedzie CI/CD - wybor zalezy od kontekstu organizacji, istniejacego ekosystemu i specyficznych wymagan projektu.

Jenkins to solidny wybor dla firm potrzebujacych pelnej kontroli nad infrastruktura CI/CD. Jego elastycznosc i ekosystem wtyczek sa niezrownane, ale wiaza sie z wyzszym kosztem utrzymania i stroma krzywa uczenia.

GitLab CI/CD to najlepszy wybor dla organizacji szukajacych zintegrowanej platformy DevOps "all-in-one". Jesli potrzebujesz CI/CD, container registry, security scanning i project management w jednym narzedziu - GitLab jest oczywistym wyborem.

GitHub Actions to idealny punkt startowy dla zespolow juz korzystajacych z GitHuba. Oferuje najszybszy czas od zera do dzialajacego pipeline'u, doskonaly ekosystem gotowych akcji i najhojniejszy darmowy plan.

Wiele organizacji stosuje podejscie hybrydowe - np. GitHub Actions dla CI (budowanie i testy) w polaczeniu z ArgoCD dla CD (wdrozenia na Kubernetes). Klucz to dopasowanie narzedzia do potrzeb zespolu, a nie odwrotnie.

Potrzebujesz pomocy w konfiguracji CI/CD?#

W MDS Software Solutions Group specjalizujemy sie w projektowaniu i wdrazaniu pipeline'ow CI/CD dopasowanych do potrzeb Twojego zespolu. Mamy doswiadczenie z Jenkins, GitLab CI/CD, GitHub Actions oraz narzedziami takimi jak ArgoCD, Terraform i Kubernetes.

Niezaleznie od tego, czy budujesz pipeline od zera, migrujesz z Jenkinsa na GitHub Actions, czy potrzebujesz optymalizacji istniejacych procesow - nasz zespol pomoze Ci dostarczac oprogramowanie szybciej i bezpieczniej.

Skontaktuj sie z nami i porozmawiajmy o automatyzacji Twojego procesu wytwarzania oprogramowania. Pierwsza konsultacja jest bezplatna.