CI/CD-Pipelines: GitHub Actions, GitLab CI

CI/CD-Pipelines: GitHub Actions, GitLab CI

1) CI/CD-Aufgabe und Platz in der Plattform

• Geschwindigkeit und Vorhersagbarkeit von Releases (kurze Lead-Zeit).
• Qualität (Autotests, statische/dynamische Analysen).
• Sicherheit der Lieferkette (Signatur von Artefakten, Zugriffskontrolle).
• Zuverlässigkeit (kanarische Deploys, schnelles Rollback).
• Beobachtbarkeit (Trace und Metriken in jeder Phase).

Schlüsselprinzipien: „Pipeline als Code“, immutable Artefakte, „build once - run many“, „shift-left security“, „least privilege“, deterministische Assemblies.

2) Architektonische Muster der Förderer

Stage-gate: build → test → security → package → deploy → post-deploy checks.
Fan-out/Fan-in: parallele Matrixbaugruppen (Sprachen/Plattformen) mit Ergebnisbündelung.
Förderung: Das gleiche Artefakt wird durch Umgebungen (dev → stage → prod) bewegt, anstatt neu zusammengesetzt zu werden.
Trunk-based + Short Branches: Driftminimierung, automatisierte Kontrollen bei PR/MR.
Wiederverwendbar: wiederverwendbare Workflows/Vorlagen (Aktionen: wiederverwendbare Workflows; GitLab: includes/child-pipelines).
GitOps (optional): Trennung von „Montage“ und „Lieferung“ (Argo CD/Flux überwachen deklarative Repos von Umgebungen).

3) Sicherheit der Lieferkette (Supply Chain)

Identifikation: OIDC-Föderation von runner'a zur Cloud (ohne langlebige Schlüssel).
Geheimnisse: zentrale Speicherung, Kontextbeschränkung, Verbot der Ausgabe in Logs.
Signatur von Artefakten/Containern (cosign/Sigstore), Überprüfung der Signatur in der Admissionskontrolle.
SBOM (CycloneDX/SPDX) und SCA, SAST/DAST/Container Scan sind „Must-Have-Gates“.
Policies: OPA/Conftest für IaC/Manifeste, „no latest“, Verbot von privilegierten Containern.
Isolierung der Runner's: Prod-Runner im privaten Netzwerk, abgehende Zugriffe vom öffentlichen Internet trennen.

4) GitHub Actions - Struktur und Praktiken

4. 1 Struktur der Workflows

`.github/workflows/.yml` — триггеры (`on: push, pull_request, schedule, workflow_call`).
Reusable Workflows zur Standardisierung (Linter, SCA, Container Assembly, Deploy).

4. 2 Beispiel: mehrstufige Pipeline mit OIDC und Bildsignatur

yaml name: ci-cd

on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]

permissions:
id-token: write  # для OIDC contents: read packages: write

jobs:
build_test_matrix:
runs-on: ubuntu-latest strategy:
matrix:
node: [18, 20]
os: [ubuntu-latest]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4 with: { node-version: ${{ matrix. node }} }
- name: Cache npm uses: actions/cache@v4 with:
path: ~/.npm key: npm-${{ runner. os }}-${{ matrix. node }}-${{ hashFiles('/package-lock. json') }}
- run: npm ci
- run: npm run lint && npm test -- --ci

docker_build_sign:
runs-on: ubuntu-latest needs: build_test_matrix steps:
- uses: actions/checkout@v4
- name: Login to GHCR uses: docker/login-action@v3 with:
registry: ghcr. io username: ${{ github. actor }}
password: ${{ secrets. GITHUB_TOKEN }}
- name: Build image run:
docker build --pull --no-cache -t ghcr. io/org/app:${{ github. sha }}.
docker push ghcr. io/org/app:${{ github. sha }}
- name: Generate SBOM uses: anchore/syft-action@v0 with:
image: ghcr. io/org/app:${{ github. sha }}
format: cyclonedx-json output-file: sbom. json
- name: Cosign sign (OIDC)
uses: sigstore/cosign-installer@v3
- name: Sign image run:
cosign sign ghcr. io/org/app:${{ github. sha }} \
--yes \
--identity-token $ACTIONS_ID_TOKEN_REQUEST_TOKEN \
--rekor-url https://rekor. sigstore. dev

deploy_stage:
runs-on: ubuntu-latest needs: docker_build_sign environment:
name: stage url: https://stage. example. com steps:
- uses: actions/checkout@v4
- name: Assume cloud role via OIDC uses: aws-actions/configure-aws-credentials@v4 with:
role-to-assume: arn:aws:iam::123456789012:role/github-deployer aws-region: eu-central-1
- name: Helm deploy (canary 10%)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=true --set canary. traffic=10
- name: Smoke checks run:./scripts/smoke. sh

promote_prod:
runs-on: ubuntu-latest needs: deploy_stage environment:
name: production url: https://app. example. com concurrency: prod-release steps:
- name: Manual approval gate run: echo "Requires environment approvers in repo settings"
- name: Promote canary → 100% (blue-green)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=false
- name: Post-deploy checks & rollback on SLO breach run:./scripts/verify_or_rollback. sh

• 'Berechtigungen' minimiert, 'id-token: write' für OIDC aktiviert.
• Umgebungen mit Approvern und URL, 'concurrency' schützt vor Rennen.
• Kanarische Verkehrsfreigabe und automatischer SLO-Rollback.

4. 3 Reusable workflow (Beispielaufruf)

yaml jobs:
security_suite:
uses: org/.github/.github/workflows/security. yml@v1 with:
severity_threshold: high

5) GitLab CI - Struktur und Praxis

5. 1 Grundstruktur

`.gitlab-ci. yml 'an der Wurzel; Schlüsseleinheiten: 'stages', 'jobs', 'rules', 'needs', 'artifacts', 'environments', 'manual'.
Reuse: 'include:' (lokale/remote templates), child/parent pipelines für komplexe Monorepos.

5. 2 Beispiel: Matrix, Cache, Signatur, Umgebungen und Zulassungen

yaml stages: [lint, test, build, security, deploy]

variables:
DOCKER_TLS_CERTDIR: "" # docker: dind acceleration
IMAGE_TAG: $CI_COMMIT_SHA

lint:
stage: lint image: node:20 script:
- npm ci
- npm run lint cache:
key: "npm-${CI_COMMIT_REF_SLUG}"
paths: [node_modules/]
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"

test:
stage: test image: node:20 parallel:
matrix:
- NODE_VERSION: ["18", "20"]
script:
- nvm install $NODE_VERSION          true
- npm ci
- npm test -- --ci artifacts:
when: always reports:
junit: report. xml

build_image:
stage: build image: docker:26. 1 services: [ "docker:26. 1-dind" ]
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG.
- docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG artifacts:
expire_in: 1 week paths: [ "sbom. json" ]
after_script:
- syft $CI_REGISTRY_IMAGE:$IMAGE_TAG -o cyclonedx-json > sbom. json

security_scans:
stage: security image: alpine:3. 20 script:
- trivy image --exit-code 0 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

deploy_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage url: https://stage. example. com on_stop: stop_stage script:
- kubectl set image deploy/app app=$CI_REGISTRY_IMAGE:$IMAGE_TAG -n stage
-./scripts/smoke. sh needs: [build_image, security_scans]
when: manual allow_failure: false

stop_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage action: stop script:
- kubectl rollout undo deploy/app -n stage

deploy_prod:
stage: deploy image: alpine/k8s:1. 30. 2 environment:
name: production url: https://app. example. com rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual allow_failure: false script:
-./scripts/canary_traffic. sh 10
-./scripts/verify_or_rollback. sh

• `parallel. matrix' simuliert Matrixbaugruppen.
• 'artifacts' + Testberichte.
• Umgebungen mit 'on _ stop', manuell 'when: manual' für Genehmigungen.
• DIND für Image Build (besser Kaniko/BuildKit im k8s Runner).

5. 3 Kinder Pipelines und Include für Monorepos

yaml include:
- local:.gitlab/ci/includes/security. yml
- project: org/platform/pipelines file: /k8s/deploy. yml ref: v1

stages: [prepare, component_a, component_b, deploy]

component_a:
stage: component_a trigger:
include:.gitlab/ci/component_a. yml strategy: depend

component_b:
stage: component_b trigger:
include:.gitlab/ci/component_b. yml strategy: depend

6) Monorepositorien und Multiservice

Verzeichnisbasierte Eigentümerschaft: CODEOWNERS und Scoped-Tests entlang der Pfade.
Incremental builds: wir identifizieren die betroffenen Pakete/Charts; Cache für Pfadschlüssel und Lock-Dateien.
Dynamische Pipelines: child-pipelines/' workflow _ call 'werden nur für geänderte Komponenten gestartet.
Versionierung: Semver für jedes Modul, Wechsel in der Release-Phase.

7) Caching und Beschleunigung

Inhaltsadressierte Caches (hashFiles/lockfile).
Separater Cache für Abhängigkeiten und Artefakte.
Pre-warm runner images (toolchains, SDK).
Lokale Paketspiegel (npm/pip/maven) und Container-Registry-Cache.

8) Release-Strategien und Rollback

Canary: allmählicher Anstieg des Prozentsatzes des Verkehrs; Auto-Stop bei SLO-Abbau.
Blau-Grün: parallele Stacks, sofortiges Umschalten.
Schatten: Duplizieren von Anfragen ohne Auswirkungen auf den Kunden.
Feature Flags: Rollout auf Flaggenebene, nicht Release.
Rollback: klare Skripte „mit einem Knopf“, die Version des Artefakts wird in den Metadaten der Veröffentlichung gespeichert.

9) Infrastruktur und GitOps

IaC: Terraform/Ansible/Helm werden in separaten Repos verwaltet; policy-as-code als Tor.
GitOps-Schaltung: Argo CD/Flux beobachten Repos mit Manifesten der Umgebung; Die Pipeline erstellt nur das Artefakt und aktualisiert die Versionen in Git.
Vorteile: explizite Geschichte von Umgebungsänderungen, Idempotenz, Standard-Pullbacks durch Git.

10) Beobachtbarkeit CI/CD

DORA-Metriken: Deployrate, Zeit von Commit bis Produktion, Ausfallrate, MTTR.
Telemetrie: Zeit der Job-Warteschlangen, Dauer der Phasen, Hit-Rate des Cache, Häufigkeit der Flaky-Tests.
Sicherheitsprotokolle: Wer die Freigabe veranlasst hat, welche Tore passiert wurden, welche Ausnahmen erteilt wurden.

11) Zugriffskontrolle und Zulassungen

Branch Protection und obligatorische Inspektionen.
Environment-approvals: separate approvers-Listen auf stage/prod.
JIT-Zugriff für manuelle Schritte, Protokollierung von Sitzungen.
Aufgabenteilung: verschiedene Rollen für „schreibt Code“, „genehmigt“, „gibt frei“.

12) Häufige Fehler (Anti-Muster)

Langlebige Cloud-Schlüssel in Repo-Geheimnissen statt OIDC-Rollen.
Zusammenbau verschiedener Artefakte für stage und prod (Verletzung von „build once“).
'neueste' Tags und mutable-Images.
Veröffentlichung der Geheimnisse in den Schrittprotokollen (nicht angeschlossenes Masking).
Ein gemeinsamer Public Runner für Prod Deploys.
Kein Sicherheitstor (SAST/SCA/Policy) und keine Post-Deploy-Prüfungen.

13) Implementierung Checkliste (0-60 Tage)

0-15 Tage

Einrichten trunk-based, PR/MR-Regeln, obligatorische statische Prüfungen.
OIDC-Föderation in die Cloud einbinden; Mindestberechtigungen.
Runner's zerlegen: öffentlich - für CI, privat - für CD.

16-30 Tage

SBOM hinzufügen, Bildsignatur; im Cluster - Überprüfung der Signatur.
Geben Sie canary/blue-green ein; Auto-Rollback nach SLO.
Cache von Abhängigkeiten und Artefakten, Pre-Warm-Bilder.

31-60 Tage

Split Montage und Lieferung (GitOps), Policy-as-Code Tore.
Richten Sie DORA-Metriken und Alerts für den Abbau von Piplines ein.
Template Piplines (reusable/child) für alle Dienste.

14) Praktische Tipps zur Zuverlässigkeit

Pflegen Sie kleine, schnelle Pipelines (10-12 Minuten vor dem Signal auf PR).
Kill flaky tests: quarantine-tags + parallel fix.
Mischen Sie keine CI-Artefakte und Release-Artefakte; Metadaten speichern (Commit, Zeit, SBOM, Signaturen).
Geben Sie den Entwicklern lokale Skripte, die mit den Pipelineschritten identisch sind (dev-prod parity).

15) Vorlagen zur Wiederverwendung

15. 1 GitHub Actions - Security reusable workflow (vereinfacht)

yaml name: security-suite on:
workflow_call:
inputs:
severity_threshold:
type: string required: false default: high jobs:
sast_sca:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run:./sec/sast. sh --threshold ${{ inputs. severity_threshold }}
- run:./sec/sca. sh --format cyclonedx-json --out sbom. json artifacts: # if using actions/upload-artifact
- sbom. json

15. 2 GitLab - mitgeliefertes Deploy-Template (vereinfacht)

yaml
.deployment_template:
image: alpine/k8s:1. 30 script:
- helm upgrade --install $APP charts/$APP --set image. tag=$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

16) Schlussfolgerung

GitHub Actions und GitLab CI bieten ausgereifte Mechanismen für einen schnellen und sicheren Code → Prod-Zyklus. Der Schlüssel zum Erfolg ist Standardisierung und Sicherheit: OIDC statt Schlüssel, Signatur und SBOM, Qualitätstor, einzelnes Artefakt mit Promotion, GitOps-Lieferung und Beobachtbarkeit über DORA. Bauen Sie Pipelines als Produkt: Messen, vereinfachen, beschleunigen - und Releases werden zur Routine, nicht zum Event.