Von Code Sentinel, Technical Project Manager bei Java Fleet Systems Consulting
Für dich und die Java Fleet Community
⚡ Was du in den nächsten 8 Minuten lernst
Nach diesem Beitrag kannst du:
- ✅ Verstehen, was CI/CD wirklich bedeutet (ohne Marketing-Buzzwords)
- ✅ Deine erste automatisierte Pipeline mit GitHub Actions bauen
- ✅ Die gleiche Pipeline in Jenkins umsetzen (Enterprise-Realität)
- ✅ Entscheiden, welches Tool für deine Situation passt
- ✅ Nie wieder manuell deployen müssen (Freitag 18:30 Uhr gehört der Vergangenheit an)
Dein größter Gewinn heute: Du baust in 10 Minuten eine Pipeline, die dir Stunden pro Woche spart und nachts ruhig schlafen lässt.
👋 Moin! Code Sentinel hier
Schön, dass du dabei bist!
Erinnerst du dich an Nova’s Git-Serie vom Oktober? Branches, Commits, Pull Requests – sie hat Git gemeistert. Und Elyndra’s Maven-Serie vom September? Build-Management, Dependencies, Profiles – alles sitzt. Und meine Docker-Serie, die gerade zu Ende ging? Container, Images, Production-Readiness.
Seitdem haben mir Stefan aus Berlin, Anna aus München und Sarah geschrieben – alle mit demselben Problem:
„Code Sentinel, ich habe Git. Ich habe Maven. Ich habe Docker. Aber jedes Mal wenn ich deploye, mache ich das manuell. Git push, dann SSH zum Server, dann Git pull, dann mvn package, dann Docker build… und dann ist es 19:00 Uhr und ich habe Kopfschmerzen.“
Und weißt du was? Ich kenne das Problem. Gestern stand Oliver (unser DevOps Engineer) neben mir, während ich für einen Kunden ein Deployment machte. Um 17:45 Uhr. „Gleich fertig“, sagte ich. Um 18:30 Uhr waren wir immer noch dabei. Oliver meinte nur trocken: „Mit Pipeline wären wir längst fertig.“ Er hatte recht.
Das Problem: Manuelle Prozesse sind fehleranfällig, zeitraubend und nervig.
Die Lösung: CI/CD – Continuous Integration und Continuous Deployment.
Lass uns das heute gemeinsam aufsetzen! 🔧
🎯 Das große Bild: Was ist CI/CD wirklich?
Kurz gesagt:
- CI (Continuous Integration): Jeder Git-Push löst automatisch Build und Tests aus
- CD (Continuous Deployment): Erfolgreiche Builds werden automatisch deployed
Noch kürzer: Die Maschine macht die Wiederholungen. Du machst das Denken.
Das Problem ohne CI/CD:
Stell dir vor, es ist Freitag, 16:45 Uhr. Du willst ein neues Feature deployen.
# Dein manueller Prozess (der Albtraum): 1. ✅ git push origin main 2. ⏰ ssh user@production-server 3. ⏰ cd /app && git pull 4. ⏰ mvn clean package 5. ❌ Build fails - falsche Java-Version auf Server! 6. 😰 Java-Version updaten (20 Minuten) 7. ⏰ mvn clean package (wieder) 8. ⏰ docker build -t app . 9. ❌ Docker build fails - Typo im Dockerfile 10. 😫 Dockerfile fixen, nochmal committen, nochmal pushen 11. 🔄 Zurück zu Schritt 2... # Es ist jetzt 18:30. # Du hast Kopfschmerzen. # Lisa wartet. # Das Feature ist immer noch nicht live.
Die Lösung mit CI/CD:
Gleiche Situation, mit Pipeline:
# Dein automatisierter Prozess (die Erlösung): 1. ✅ git push origin main # Pipeline übernimmt (automatisch): 2. ✅ Checkout Code (10 Sekunden) 3. ✅ Setup Java 21 (Cache - 5 Sekunden) 4. ✅ Maven Build (2 Minuten) 5. ✅ Run Tests (1 Minute) 6. ✅ Docker Build (3 Minuten) 7. ✅ Security Scan (1 Minute) 8. ✅ Deploy to Dev (30 Sekunden) # Zeit: 7 Minuten, 45 Sekunden # Du machst inzwischen Kaffee # Feierabend um 17:00 # Feature ist live # Keine Kopfschmerzen # Lisa ist happy
Das ist der Unterschied. Das ist CI/CD.
🔧 Hands-On: Deine erste Pipeline
Wir nutzen das Persons-API-Projekt aus meiner Docker-Serie. Du erinnerst dich? Spring Boot + PostgreSQL + Docker. Perfekt für CI/CD.
Tool-Entscheidung: GitHub Actions oder Jenkins?
Kurze Antwort: Beide. Ich zeige dir beide.
Warum?
- GitHub Actions: Modern, einfach, Cloud-native. Perfekt für neue Projekte.
- Jenkins: Enterprise-Standard, seit 2011 in Production. Die Realität in 70% der Firmen.
Welches zuerst? Egal. Pick one. Verstehe es. Das andere ist dann einfach.
🚀 Option 1: GitHub Actions
Setup in 5 Minuten:
Schritt 1: Datei erstellen
# In deinem Projekt-Root: mkdir -p .github/workflows cd .github/workflows touch ci.yml
Schritt 2: Pipeline definieren
# .github/workflows/ci.yml
name: CI Pipeline - Persons API
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
# Step 1: Code holen (Nova's Git!)
- name: Checkout code
uses: actions/checkout@v4
# Step 2: Java Setup (Elyndra's JDK!)
- name: Set up JDK 21
uses: actions/setup-java@v4
with:
java-version: '21'
distribution: 'temurin'
cache: 'maven'
# Step 3: Build (Elyndra's Maven!)
- name: Build with Maven
run: mvn clean verify
# Step 4: Docker Build (Meine Serie!)
- name: Build Docker image
run: docker build -t persons-api:${{ github.sha }} .
# Step 5: Security Check
- name: Run Trivy security scan
uses: aquasecurity/trivy-action@master
with:
image-ref: persons-api:${{ github.sha }}
format: 'sarif'
output: 'trivy-results.sarif'
Schritt 3: Committen und pushen
git add .github/workflows/ci.yml git commit -m "feat: Add CI pipeline" git push origin main # 🎉 Pipeline startet automatisch!
Was passiert jetzt?
- GitHub erkennt den Push
- Pipeline startet automatisch
- Ubuntu-Container wird hochgefahren
- Dein Code wird geclont
- Java 21 wird installiert
- Maven baut dein Projekt
- Tests laufen durch
- Docker-Image wird gebaut
- Security-Scan prüft Vulnerabilities
- Ergebnis: ✅ oder ❌
Du schaust zu. Oder machst Kaffee. Beides gut.
Wo siehst du die Ergebnisse?
GitHub → Dein Repo → Actions Tab Dort siehst du: - ✅ Erfolgreiche Builds (grün) - ❌ Fehlgeschlagene Builds (rot) - ⏳ Laufende Builds (orange) - 📊 Build-Logs (für Debugging)
🏢 Option 2: Jenkins (Enterprise-Realität)
„Aber Code Sentinel“, höre ich dich sagen, „wir haben bei uns Jenkins seit 2015. Migration zu GitHub Actions? Kein Budget, keine Zeit.“
Kenne ich. Habe ich letzte Woche beim Kunden gehört. Genau dieselben Worte.
Hier ist Jenkins. Gleiche Pipeline. Andere Syntax.
Setup (etwas länger, aber lohnt sich):
Schritt 1: Jenkins installieren (Docker-based, schnellster Weg)
# Jenkins als Container starten docker run -d \ --name jenkins \ -p 8080:8080 \ -p 50000:50000 \ -v jenkins_home:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ jenkins/jenkins:lts-jdk21 # Initial Admin Password holen docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword # Browser öffnen: http://localhost:8080 # Password eingeben, Setup durchlaufen
Schritt 2: Plugins installieren
Jenkins → Manage Jenkins → Manage Plugins → Available Installiere: - ✅ Git Plugin - ✅ Maven Integration - ✅ Docker Pipeline - ✅ Pipeline Utility Steps
Schritt 3: Jenkinsfile erstellen
// Jenkinsfile (im Projekt-Root)
pipeline {
agent any
tools {
maven 'Maven-3.9'
jdk 'JDK-21'
}
environment {
DOCKER_IMAGE = "persons-api"
}
stages {
stage('Checkout') {
steps {
// Nova's Git - automatisch von Jenkins
checkout scm
echo "✅ Code checked out from ${env.BRANCH_NAME}"
}
}
stage('Build with Maven') {
steps {
// Elyndra's Maven
sh 'mvn clean verify'
}
post {
always {
// Test-Reports für Jenkins UI
junit '**/target/surefire-reports/*.xml'
}
}
}
stage('Docker Build') {
steps {
script {
// Mein Docker
def imageTag = "${env.BUILD_NUMBER}-${env.GIT_COMMIT.take(7)}"
sh """
docker build -t ${DOCKER_IMAGE}:${imageTag} .
docker tag ${DOCKER_IMAGE}:${imageTag} ${DOCKER_IMAGE}:latest
"""
}
}
}
stage('Security Scan') {
steps {
script {
// Trivy-Scan
sh """
trivy image --severity HIGH,CRITICAL \
--exit-code 1 \
${DOCKER_IMAGE}:latest
"""
}
}
}
}
post {
failure {
// Mail bei Fehler
mail to: 'team@java-fleet.com',
subject: "Build Failed: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
body: "Check Jenkins: ${env.BUILD_URL}"
}
success {
echo "✅ Build successful! Ready for deployment."
}
}
}
Schritt 4: Job in Jenkins erstellen
1. New Item → Multibranch Pipeline 2. Name: persons-api 3. Branch Sources → Git → URL eingeben 4. Script Path: Jenkinsfile 5. Save
Pipeline läuft! 🎉
🤔 GitHub Actions vs Jenkins: Welches passt zu dir?
Quick Decision Tree:
START
↓
Neues Projekt oder Legacy?
↓
[Neu] → Cloud OK? → [Ja] → GitHub Actions ✅
↓
[Nein] → On-Premise nötig? → Jenkins ✅
[Legacy] → Jenkins vorhanden? → [Ja] → Jenkins ✅
↓
[Nein] → Team-Skill? → [Junior] → GitHub Actions ✅
↓
[Senior] → Beide möglich, pick one
Die ehrliche Vergleichstabelle:
| Kriterium | GitHub Actions | Jenkins | Code Sentinel’s Take |
|---|---|---|---|
| Setup-Zeit | 5 Minuten ⚡ | 2 Stunden 🐢 | Actions klar vorn |
| Lernkurve | Flach 📊 | Steil 📈 | Actions einfacher |
| Enterprise-Features | Basis ⭐⭐⭐ | Komplett ⭐⭐⭐⭐⭐ | Jenkins etablierter |
| Kosten (SaaS) | Free + $$$ | N/A | – |
| Kosten (Self-Hosted) | Nicht möglich | Server + Maintenance | Jenkins = Kontrolle |
| Plugin-Ökosystem | Wachsend | Gigantisch | Jenkins mehr Optionen |
| Cloud-Native | Ja ✅ | Mit Arbeit | Actions native |
| Compliance/Audit | OK | Exzellent | Jenkins für Regulated |
Meine persönliche Meinung:
„Wenn du die Wahl hast: GitHub Actions. Schneller, einfacher, moderner.
Wenn du sie nicht hast: Jenkins ist seit 2011 battle-tested und wird noch 2031 laufen.
Wenn du beides lernen willst: Diese Serie! 😉“
Oliver würde hinzufügen: „Und wenn du Cloud-native willst, nimm Actions. Für On-Premise bleibt Jenkins King. Ich manage beides täglich – beide haben ihre Berechtigung.“
⚠️ Wenn’s schief geht (und es wird schiefgehen)
Typische Fehler und Lösungen:
Problem 1: „Maven dependencies not found“
# ❌ Fehlt Cache
- name: Set up JDK 21
uses: actions/setup-java@v4
with:
java-version: '21'
distribution: 'temurin'
# cache: 'maven' ← FEHLT!
# ✅ Mit Cache
- name: Set up JDK 21
uses: actions/setup-java@v4
with:
java-version: '21'
distribution: 'temurin'
cache: 'maven' ← Jetzt geht's!
Problem 2: „Docker build fails: permission denied“
# Lösung: GitHub Actions braucht spezielle Docker-Permissions
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Build Docker image
uses: docker/build-push-action@v5
with:
context: .
push: false
tags: persons-api:latest
Problem 3: „Tests fail in pipeline but work locally“
# Häufig: Environment-Variablen fehlen env: SPRING_PROFILES_ACTIVE: test DB_HOST: localhost DB_PORT: 5432
Stefan aus Berlin hatte genau Problem 3 letzte Woche. Oliver (unser DevOps Engineer) hat ihm dann geholfen, die Environment-Variablen richtig zu setzen. Funktioniert jetzt perfekt.
📊 Dein Erfolg in Zahlen
Vorher (manuell):
- ⏰ 30 Minuten pro Deployment
- 😰 20% Fehlerquote
- 💸 Bei 20 Deployments/Monat = 10 Stunden verschwendet
- 😴 Schlaflose Nächte bei Production-Problemen
Nachher (mit CI/CD):
- ⚡ 7 Minuten automatisiert
- ✅ <5% Fehlerquote (nur bei echten Bugs)
- 💰 9+ Stunden gespart pro Monat
- 😴 Ruhiger Schlaf (Pipeline handled es)
ROI: Nach einem Monat hast du die Setup-Zeit wieder raus. Ab dann nur noch Gewinn.
✅ Deine Checkliste für heute
Hast du:
- [ ] Verstanden, was CI/CD ist? (Nicht nur Theory – das Warum!)
- [ ] Eine Pipeline-Option gewählt? (GitHub Actions ODER Jenkins)
- [ ] Deine erste Pipeline gebaut? (Copy-Paste zählt!)
- [ ] Einen erfolgreichen Build gesehen? (Grüner Haken = Sieg!)
- [ ] Die Pipeline für dein Projekt angepasst? (persons-api → dein-projekt)
Bonus-Aufgaben:
- [ ] Pipeline mit deinem Team geteilt
- [ ] Screenshot vom ersten grünen Build gemacht
- [ ] Überlegt, welche Steps du noch brauchst
🎯 Community-Challenge: „Deine erste Pipeline“
Die Challenge diese Woche:
- Baue deine erste CI-Pipeline (GitHub Actions oder Jenkins)
- Deploye erfolgreich (mindestens bis Docker-Build)
- Mache einen Screenshot vom grünen Build
- Teile ihn mit #JavaFleetCI auf Twitter/LinkedIn
- Bonus: Pipeline unter 5 Minuten? Extra-Punkte!
Die besten 3 Submissions bekommen:
- 🏆 Feature im nächsten Blogpost
- 🎁 Java Fleet CI/CD Cheat-Sheet (exclusive)
- ⭐ Shoutout auf allen Social Channels
Deadline: Nächsten Sonntag, 23:59 Uhr
💬 Deine Fragen – Meine Antworten
Q: Kostet GitHub Actions Geld?
A: Free tier: 2.000 Minuten/Monat. Für Hobby-Projekte reicht das locker. Public Repos: unlimited!
Q: Brauche ich einen eigenen Server für Jenkins?
A: Ja. Oder nutze Docker (wie oben gezeigt). Oder Cloud-Jenkins (Managed).
Q: Was, wenn ich GitLab benutze?
A: GitLab CI ist ähnlich wie GitHub Actions. Syntax anders, Konzept gleich. Kommt in Teil 6!
Q: Kann ich beide parallel nutzen?
A: Ja! Viele Firmen haben beides. GitHub Actions für neue Projekte, Jenkins für Legacy.
Q: Was kommt in Teil 2?
A: Quality Gates! Security-Scans, Code-Coverage, OWASP-Checks. Zero Tolerance für schlechten Code!
Q: Funktioniert das auch für andere Sprachen?
A: Ja! Python, JavaScript, Go, Rust – Konzepte bleiben gleich. Nur Tools ändern sich.
🎓 Was du heute gelernt hast
Du kannst jetzt:
- ✅ Erklären, was CI/CD ist (und warum es wichtig ist)
- ✅ GitHub Actions Pipeline schreiben
- ✅ Jenkins Pipeline erstellen
- ✅ Entscheiden, welches Tool für dich passt
- ✅ Typische Fehler debuggen
- ✅ Nie wieder manuell deployen
Du hast verstanden, dass CI/CD keine Magie ist. Es ist Automation. Und Automation spart Zeit, Nerven und lässt dich besser schlafen.
Und mein Team? Oliver baut gerade unsere nächste Cloud-Pipeline. Kofi optimiert den Code. Das ganze Java Fleet Team zieht an einem Strang. Gemeinsam machen wir CI/CD zur Routine.
Lisa würde trotzdem zustimmen – früher nach Hause ist immer gut. 😉
🔮 Ausblick: Was kommt als nächstes?
Teil 2 (nächste Woche): Quality Gates – Tests, Security, Code-Qualität
- OWASP Dependency Check
- JaCoCo Code Coverage
- SonarQube Integration
- Trivy Security Scanning
- „Grün“ bedeutet nichts, wenn du nicht weißt WAS du misst
Teil 3 (in 2 Wochen): Deployment-Strategien
- Blue-Green Deployment
- Canary Releases
- Zero-Downtime Updates
- Rollback-Strategien
Teil 4 (in 3 Wochen): Monitoring & Feedback
- Prometheus Integration
- Grafana Dashboards
- Alert-Management
- Incident-Response
Teil 5 (in 4 Wochen): Jenkins Enterprise Deep-Dive
- Shared Libraries
- Distributed Builds
- Configuration as Code
- Security Best Practices
Teil 6 (Finale): Multi-Platform CI/CD
- GitLab CI
- Azure DevOps
- Platform-Migration
- Tool-agnostisches Design
📥 Downloads & Ressourcen
Heute für dich:
Alle Templates getestet mit:
- ✅ Spring Boot 3.x
- ✅ Maven 3.9
- ✅ Java 21
- ✅ Docker 24
🎬 Bernd’s Corner
In diesem Blog dürfen auch andere zu Wort kommen. Heute: Bernd.
„CI/CD. Endlich. Wurde auch Zeit.
Ich sage seit 2011, dass manuelles Deployment Zeitverschwendung ist.
Damals hat’s keiner hören wollen.Jetzt, 14 Jahre später, wird’s ‚modern‘. Die Kids denken, sie haben’s erfunden.
Und CD? Continuous Deployment?
In der Realität steht’s für Continue Developing.
Weil nach dem Deployment ja erstmal die Bugs gefixt werden müssen.Spoiler: Jenkins läuft bei mir seit… ach egal.
Macht’s einfach. Automatisiert alles. Geht Feierabend machen.
— Bernd, der das schon gemacht hat, als ihr noch in Maven 2 kompiliert habt“
(Mehr von Bernd in seiner Kolumne: „Irgendwer muss es ja sagen.“)
🔍 Easter Egg Hunt
Für die aufmerksamen Leser: Irgendwo in diesem Post versteckt sich ein Code-Wort. Finde es und suche es auf unserer Website – dort wartet ein exklusives Behind-the-Scenes-Dokument auf dich.
Hinweis: Es hat mit einem bestimmten Deployment zu tun, das um eine bestimmte Uhrzeit nicht funktioniert hat. 😏
💌 Bis nächste Woche!
Danke, dass du dabei warst. Wenn du Fragen hast, schreib mir:
- 📧 code.sentinel@java-fleet.com
- 💬 Twitter: @CodeSentinelDev
- 💼 LinkedIn: Code Sentinel
Und vergiss nicht: Teile deine erste Pipeline mit #JavaFleetCI!
Wir sehen uns in den Builds. 🛡️
— Code Sentinel
P.S. Oliver meint, meine Pipelines könnten noch schneller sein. Challenge accepted!
P.P.S. Kofi zeigt mir gerade einen cleveren Algorithm-Trick für Build-Optimization.
P.P.P.S. Lisa? Eines Tages frage ich sie. Eines Tages…
📊 Nächster Post: Quality Gates – Warum „kompiliert“ nicht „gut“ bedeutet
📅 Erscheint: Nächsten Montag, 09:00 Uhr
🔔 Newsletter: Hier anmelden für Early Access
Tags: #CICD #GitHub #Jenkins #DevOps #JavaDevelopment #Automation #ContinuousIntegration #ContinuousDeployment #SpringBoot #Docker #Maven #Git
Serie: CI/CD-Grundlagen (Teil 1 von 6)
