Miért van szükséged CI/CD pipeline-ra?

Ha a telepítési folyamatod úgy néz ki, hogy valaki SSH-zik a szerverre és kézzel futtatja a parancsokat — akkor minden telepítés egy kockázat. Elfelejtett lépések, eltérő konfigurációk, emberi hibák.

A CI/CD (Continuous Integration / Continuous Delivery) pipeline automatizálja ezt a teljes folyamatot: a kód megírásától az éles rendszerre kerülésig. Így:

  • Minden telepítés azonos és megismételhető
  • A hibák korábban kiderülnek (automatizált tesztek)
  • Bárki telepíthet, nem csak a senior mérnök
  • Van rollback — ha valami elromlik, egy kattintás visszaállni

A CI/CD pipeline rétegei

Egy jól megtervezett pipeline-nak öt rétege van:

1. réteg: Forráskód-kezelés

Minden a Git-tel kezdődik. Ha a kódod nincs verziókezelve, ott kell kezdeni.

Alapelvek:

  • Branching stratégia — trunk-based development (rövid életű branch-ek) a legegyszerűbb és leghatékonyabb
  • PR/MR review — minden változtatás átmegy code review-n
  • Védett main branch — senki sem push-ol közvetlenül main-re

2. réteg: Continuous Integration (CI)

Minden PR-nál automatikusan lefutnak:

Build:

# GitHub Actions példa
- name: Build
  run: docker build -t myapp:${{ github.sha }} .

Tesztek:

  • Unit tesztek (gyorsak, minden PR-nál)
  • Integrációs tesztek (lassabbak, de fontosak)
  • Linting és kódminőség-ellenőrzés

Biztonsági vizsgálat:

  • Dependency scanning (Dependabot, Snyk)
  • Container image scanning (Trivy)
  • Secrets detection (TruffleHog, GitLeaks)

3. réteg: Artifact Management

A sikeres build eredményeként létrejön egy artifact (konténer image, csomag):

  • Konténer image push → ECR, GCR, Docker Hub, vagy Harbor
  • Verziókezelés — git SHA vagy szemantikus verziószám
  • Image signing — garantálja, hogy az image nem módosult

4. réteg: Continuous Delivery (CD)

Az artifact eljut a célkörnyezetbe. Itt két megközelítés van:

Push-based (hagyományos): A CI pipeline telepíti az alkalmazást. Egyszerű, de a CI rendszernek szüksége van a klaszter hozzáférésre.

Pull-based (GitOps): ArgoCD figyeli a GitOps repót, és automatikusan szinkronizálja az állapotot. Biztonságosabb, mert a klaszter húzza a változtatásokat.

Ajánlás: ha Kubernetest használsz, a GitOps/ArgoCD megközelítés egyértelműen jobb. Ha egyszerűbb az infrastruktúrád, a push-based is megfelel.

5. réteg: Környezetek és promóció

A tipikus környezet-hierarchia:

dev → staging → production

Promóciós szabályok:

  • Dev: automatikus telepítés minden main merge után
  • Staging: automatikus vagy manuális trigger, automatizált E2E tesztek
  • Production: manuális jóváhagyás (vagy automatikus, ha elég érett a pipeline)

Gyakorlati példa: GitHub Actions + ArgoCD

Íme egy valós pipeline felépítés:

CI rész (GitHub Actions)

name: CI Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
      - name: Lint
        run: make lint

  build:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and push image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker push myapp:${{ github.sha }}          
      - name: Update GitOps repo
        run: |
          # Frissítjük az image tag-et a GitOps repóban
          cd gitops-repo
          sed -i "s|image: myapp:.*|image: myapp:${{ github.sha }}|" dev/deployment.yaml
          git commit -am "Update dev to ${{ github.sha }}"
          git push

CD rész (ArgoCD)

ArgoCD figyeli a GitOps repót és automatikusan szinkronizálja a dev környezetet. A staging és production promóció PR-rel történik.

Gyakori hibák

1. Túl bonyolult pipeline az elején

Kezdd egyszerűen: build, test, deploy. A többi (security scanning, performance testing, canary releases) később jön, amikor szükség van rá.

2. Nincs rollback terv

Minden pipeline-nak tartalmaznia kell egy rollback mechanizmust. GitOps-szal ez egy git revert. Push-based pipeline-nál definiáld előre.

3. Lassú pipeline

Ha a pipeline 30+ percig tart, senki sem fogja használni. Optimalizálj: párhuzamos futás, Docker layer cache, szelektív tesztek.

4. Titkok a kódban

Soha, semmilyen körülmények között ne tárold a titkokat (API kulcsok, jelszavak) a git repóban. Használj GitHub Secrets-et, HashiCorp Vault-ot, vagy AWS Secrets Manager-t.

Összefoglalás

Egy jó CI/CD pipeline nem luxus — alapvető szükséglet. Nem kell tökéletesnek lennie az első naptól. Kezdd egyszerűen, mérd az eredményeket, és iterálj.

A legfontosabb lépések:

  1. Git + branching stratégia rendbe tétele
  2. Automatizált build és tesztek beállítása
  3. Automatizált telepítés legalább dev környezetbe
  4. Monitorozás — tudnod kell, ha valami elromlik
  5. Fokozatos bővítés — security scanning, staging, production automation

Ha segítségre van szükséged a CI/CD pipeline tervezésében vagy implementálásában — beszéljünk róla. Az első konzultáció ingyenes.