- Startseite
- Skills
- Bereitstellung
- CI/CD-Pipeline-Architekt
CI/CD-Pipeline-Architekt
Effiziente CI/CD-Pipelines entwerfen, die Ihren Code automatisch testen, bauen und deployen — vom ersten Commit bis zur Produktion.
Das Problem
Manuelle Deployments sind fehleranfaellig, langsam und nicht reproduzierbar. Ohne eine CI/CD-Pipeline pusht Ihr Team Code und hofft auf das Beste — keine automatisierten Tests, keine Build-Verifikation, kein konsistenter Deployment-Prozess. Jedes Release wird zu einer manuellen Zeremonie, die Stunden verschlingt und menschliche Fehler zum schlechtesten Zeitpunkt einfuehrt.
Der Prompt
Du bist ein CI/CD-Architekt. Entwirf eine vollstaendige Pipeline fuer mein Projekt.
PROJEKTDETAILS:
- Repository: [z.B. GitHub, GitLab, Bitbucket]
- Sprache/Framework: [z.B. Node.js/Next.js, Python/Django, Go]
- Test-Suite: [z.B. Jest + Playwright, pytest, go test]
- Build-Output: [z.B. Docker-Image, statische Dateien, kompiliertes Binary]
- Deploy-Ziel: [z.B. Vercel, AWS ECS, Kubernetes, Netlify]
- Branch-Strategie: [z.B. Trunk-based, GitFlow, Feature-Branches]
Entwirf eine Pipeline mit diesen Stages:
1. **Trigger-Regeln**: Welche Events welche Pipeline ausloesen (Push, PR, Tag, Schedule).
2. **Quality Gate**: Linting, Type-Checking, Unit-Tests, Integrationstests — in optimaler paralleler Reihenfolge.
3. **Build-Stage**: Artefakte bauen mit Caching-Strategie fuer maximale Geschwindigkeit.
4. **Security-Scan**: Dependency-Audit, SAST, Container-Scan — was blockieren vs. warnen.
5. **Deploy-Stages**: Staging Auto-Deploy, Produktion mit manuellem Approval-Gate.
6. **Post-Deploy**: Smoke-Tests, Benachrichtigung, Rollback-Trigger.
7. **Optimierung**: Caching, Parallelisierung, bedingte Schritte zur Minimierung der Pipeline-Dauer.
Gib die vollstaendige Pipeline-Konfigurationsdatei fuer meine CI-Plattform aus.
Beispielausgabe
# .github/workflows/ci-cd.yml
name: CI/CD Pipeline
on:
push: { branches: [main] }
pull_request: { branches: [main] }
jobs:
quality:
runs-on: ubuntu-latest
steps: [checkout, setup-node, cache, lint, typecheck, test]
# Parallel: lint + typecheck + test (3 Min gesamt vs. 8 Min sequentiell)
build:
needs: quality
steps: [build-docker, push-to-registry]
# Cache: Docker-Layer-Cache spart ~4 Min pro Build
deploy-staging:
needs: build
if: github.ref == 'refs/heads/main'
# Auto-Deploy auf Staging, Smoke-Tests ausfuehren
deploy-production:
needs: deploy-staging
environment: production # Manuelle Freigabe erforderlich
Wann einsetzen
Verwenden Sie diesen Skill bei der Einrichtung eines neuen Projekts, bei der Migration von manuellen Deployments oder wenn Ihre bestehende Pipeline langsam oder unzuverlaessig ist. Ueberarbeiten Sie sie beim Hinzufuegen neuer Quality-Gates (z.B. Accessibility-Tests, Performance-Budgets) oder bei Aenderung der Deploy-Ziele.
Profi-Tipps
- Parallelisieren Sie alles was unabhaengig laufen kann — Lint, Type-Check und Unit-Tests haben keine Abhaengigkeiten zueinander. Parallele Ausfuehrung kann die Pipeline-Zeit um 60% reduzieren.
- Cachen Sie aggressiv — node_modules, Docker-Layer, Build-Artefakte. Eine gut gecachte Pipeline laeuft in 2 statt 15 Minuten.
- Fail Fast — setzen Sie die guenstigsten Checks zuerst (Lint dauert Sekunden, E2E-Tests Minuten). Beenden Sie die Pipeline frueh bei offensichtlichen Fehlern.
- Nutzen Sie Environment-Protection-Rules — verlangen Sie manuelle Freigabe fuer Produktions-Deploys. Ein versehentlicher Merge nach Main sollte nicht automatisch defekten Code deployen.