Building an Automated CI/CD Pipeline on AWS

3.5) GitHub Webhook

Der GitHub Webhook verbindet das GitHub-Repository direkt mit Jenkins und ermöglicht das automatische Starten des CI-Pipelines bei jedem Code-Commit.

- Ziel:

• Automatischer Build bei jedem git push
• Kein manueller Start des Jenkins Jobs
• Schnelles Feedback über Build- und Code-Qualität

- Ablauf:

1. Developer pusht Code in das GitHub Repository
2. GitHub Webhook sendet ein HTTP POST Event
3. Jenkins empfängt das Event
4. Jenkins startet automatisch den CI Pipeline Job

- Konfiguration in Jenkins:

• Jenkins Job → Build Triggers
• Option aktivieren: GitHub hook trigger for GITScm polling

- Konfiguration in GitHub

• Repository → Settings → Webhooks → Add Webhook
• Payload URL: http://<JENKINS_PUBLIC_IP>:8080/github-webhook/
• Content type: application/json
• Trigger Event: Just the push event

- Sicherheit & Netzwerk

• Jenkins Security Group erlaubt eingehenden Traffic auf Port 8080
• Webhook Endpoint ist öffentlich erreichbar

- Ergebnis

Jeder Push auf GitHub triggert automatisch den Jenkins CI Pipeline (Build → SonarQube → Quality Gate → Nexus Upload).

3.6) SonarQube Server Integration Stage

Nach dem Build durchläuft die CI-Pipeline mehrere Qualitätsstufen. Diese Stages stellen sicher, dass nur getesteter, sauberer und qualitativ hochwertiger Code weiterverarbeitet wird.

1- Stage: Test

stage('Test') {
  steps {
    sh 'mvn -s settings.xml test'
  }
}

• Führt alle Unit-Tests des Projekts aus
• Nutzt settings.xml, um Abhängigkeiten über Nexus zu beziehen
• Erzeugt JUnit-Testberichte in target/surefire-reports
• ❌ Bei fehlgeschlagenen Tests wird die Pipeline abgebrochen

Ziel: Sicherstellen, dass die Anwendung funktional korrekt ist.

2- Stage: Checkstyle-Analyse

stage('Checkstyle Analysis') {
  steps {
    sh 'mvn -s settings.xml checkstyle:checkstyle'
  }
}

• Überprüft den Java-Code-Stil anhand definierter Regeln
• Erkennt Verstöße gegen Coding-Standards (Naming, Struktur, Komplexität)
• Erzeugt den Bericht target/checkstyle-result.xml
• Der Bericht wird später von SonarQube ausgewertet

- Ziel: Einheitlicher, wartbarer und sauberer Quellcode.

3- Stage: SonarQube-Analyse

Voraussetzungen:

• SonarQube läuft auf eigener EC2 (z.B. http://<SONAR_PUBLIC_IP>)
• Jenkins kann SonarQube erreichen (Security Group / Netzwerk ok)
• In Jenkins ist SonarQube als Server registriert (Manage Jenkins → System → SonarQube servers)
• Ein Sonar Token ist in Jenkins Credentials gespeichert (Secret Text)
• SonarScanner ist verfügbar (Jenkins Tool oder per Maven Plugin)

Credentials (Best Practice):

• sonarserver (Jenkins SonarQube Server Name) → wird in Pipeline referenziert
• sonartoken (Secret Text) → Zugriff für Scanner auf SonarQube

Jenkins Konfiguration (einmalig)

1. SonarQube Token erstellen in SonarQube:
   My Account → Security → Generate Token → z.B. jenkins-token
2. Token in Jenkins speichern:
   Manage Jenkins → Credentials → (global) → Add Credentials → Secret text
   Secret = <SONAR_TOKEN>
ID = sonartoken
3. SonarQube Server in Jenkins registrieren:
   Manage Jenkins → System → SonarQube servers
   Name: sonarserver
Server URL: http://<SONAR_PRIVATE_IP>
Authentication Token: sonartoken

SonarQube Stage in Pipeline

stage('Sonar Analysis') {
  environment {
    scannerHome = tool "${SONARSCANNER}"
  }
  steps {
    withSonarQubeEnv("${SONARSERVER}") {
      sh '''
      ${scannerHome}/bin/sonar-scanner \
      -Dsonar.projectKey=profile \
      -Dsonar.projectName=profile \
      -Dsonar.projectVersion=1.0 \
      -Dsonar.sources=src/ \
      -Dsonar.java.binaries=target/test-classes \
      -Dsonar.junit.reportsPath=target/surefire-reports/ \
      -Dsonar.jacoco.reportsPath=target/jacoco.exec \
      -Dsonar.java.checkstyle.reportPaths=target/checkstyle-result.xml
      '''
    }
  }
}

Was passiert in dieser Stage?

• Start des SonarScanners aus Jenkins
• Übertragung von Code und Metriken an SonarQube
• Analyse von:
  • Bugs und Sicherheitslücken
  • Code Smells
  • Testabdeckung (JaCoCo)
  • Checkstyle-Ergebnissen
• Ergebnisse werden in der SonarQube-Datenbank gespeichert

✅ Nach dieser Stage ist das Projekt in SonarQube sichtbar und bereit für die Quality-Gate-Prüfung.

Quality Gate stage (SonarQube)

stage("Quality Gate") {
  steps {
    timeout(time: 1, unit: 'HOURS') {
      waitForQualityGate abortPipeline: true
    }
  }
}

Diese Stage stellt sicher, dass der Build nur dann fortgesetzt wird, wenn die Code-Qualitätsregeln von SonarQube erfüllt sind.

Erklärung

• waitForQualityGate wartet auf das Ergebnis der SonarQube-Analyse
• timeout verhindert ein endloses Warten auf die Antwort von SonarQube
• abortPipeline: true stoppt die Pipeline sofort, wenn der Quality Gate Status FAILED ist

❌ Wenn der Quality Gate fehlschlägt, wird kein Artefakt veröffentlicht. Dadurch wird sichergestellt, dass nur qualitativ hochwertiger Code weitergegeben wird.

Zusammenfassung

• Test → Funktionale Validierung
• Checkstyle → Code-Qualität & Standards
• SonarQube → Zentrale Qualitätsbewertung

Ergebnis nach Hinzufügen der Stages: Test, Checkstyle & Sonar Analysis

Nach der Erweiterung der Jenkins-Pipeline um die Stages Test, Checkstyle Analysis und Sonar Analysis wurde der CI-Prozess deutlich qualitätsorientierter. Die folgenden Ergebnisse zeigen den erfolgreichen Ablauf dieser neuen Stages.

1) Jenkins Pipeline – Erfolgreicher Build

Die Jenkins-Konsole zeigt, dass alle neuen Stages ohne Fehler durchlaufen wurden. Insbesondere wurde der SonarQube-Analyseprozess erfolgreich abgeschlossen und das Quality Gate als OK bewertet.



2) SonarQube Quality Gate – Passed

Nach Abschluss der statischen Codeanalyse bestätigt SonarQube, dass alle definierten Quality-Gate-Bedingungen erfüllt wurden. Damit darf die Pipeline fortgesetzt werden (z. B. Artefakt-Upload).



3) SonarQube Projektübersicht – Code Quality Metriken

Die SonarQube-Dashboard-Ansicht zeigt detaillierte Qualitätsmetriken des Projekts: Bugs, Vulnerabilities, Code Smells, Test Coverage und technische Schulden. Obwohl Warnungen existieren, bleibt das Quality Gate insgesamt bestanden.

3.7) Artifact Upload in Nexus

Nach erfolgreichem Build, Tests und bestandener Code-Analyse wird das erzeugte Artefakt in das zentrale Artefakt-Repository Nexus Repository Manager hochgeladen.

Timestamp – Versionierung des Artefakts vor dem Upload

Bevor das Artefakt in das Nexus Repository hochgeladen wird, wird ein Timestamp verwendet, um jede Build-Version eindeutig zu kennzeichnen. Dadurch wird verhindert, dass sich Artefakte überschreiben, und jeder Build bleibt eindeutig nachvollziehbar.

Warum ein Timestamp?

• Vermeidet das Überschreiben von Artefakten im Nexus Repository
• Jeder Jenkins-Build erzeugt ein eindeutig versioniertes Artefakt
• Erleichtert Debugging, Rollbacks und Nachvollziehbarkeit

Was passiert technisch?

Das erzeugte WAR-File im target/-Verzeichnis wird logisch versioniert, z.B.:

profile-v2.war
→ profile-v2-${BUILD_ID}-${BUILD_TIMESTAMP}.war

Der Timestamp selbst wird nicht direkt im Dateinamen geändert, sondern als Version-Attribut beim Upload nach Nexus verwendet.

Konfiguration in Jenkins

• Installation des Jenkins Plugins Build Timestamp
• Aktivierung des Plugins in der Jenkins Pipeline (Manage jenkins -> system -> Build Timestamp)
• Nutzung der Jenkins-Variablen BUILD_ID und BUILD_TIMESTAMP im Upload-Stage

- Stage: Publish Artifact to Nexus

stage("UploadArtifact") {
  steps {
    nexusArtifactUploader(
      nexusVersion: 'nexus3',
      protocol: 'http',
      nexusUrl: "${NEXUSIP}:${NEXUSPORT}",
      groupId: 'QA',
      version: "${env.BUILD_ID}-${env.BUILD_TIMESTAMP}",
      repository: "${RELEASE_REPO}",
      credentialsId: "${NEXUS_LOGIN}",
      artifacts: [
        [artifactId: 'profileapp',
         classifier: '',
         file: 'target/vprofile-v2.war',
         type: 'war']
      ]
    )
  }
}

Erklärung

• Verwendet das Jenkins Plugin Nexus Artifact Uploader
• Lädt das erzeugte .war-Artefakt nach Nexus 3 hoch
• Die Version wird dynamisch erzeugt: BUILD_ID + BUILD_TIMESTAMP
• Upload erfolgt nur nach bestandenem Quality Gate
• Zugangsdaten werden sicher über Jenkins Credentials verwaltet

Repository-Auswahl in Nexus

Maven entscheidet automatisch, in welches Repository das Artefakt hochgeladen wird – abhängig von der Versionsnummer im pom.xml.

• Snapshot-Version (1.0-SNAPSHOT) → profile-snapshot
• Release-Version (1.0) → profile-release

ℹ️ Beide Repositories sind über das pro-maven-group-Repository zusammengefasst, das als zentraler Zugriffspunkt dient.

Sicherheit & Credentials

• Nexus-Zugangsdaten sind nicht im Code gespeichert
• Credentials werden in Jenkins als:
  • Username/Password Credentials
  • z. B. ID: nexuslogin
• Jenkins injiziert die Credentials als Umgebungsvariablen:
  • NEXUS_USER
  • NEXUS_PASS

Ergebnis nach der Stage „Publish Artifact to Nexus“

Nach erfolgreichem Durchlauf aller vorherigen Pipeline-Stages (Build, Test, Checkstyle, Sonar Analysis und Quality Gate) wurde das erzeugte Artefakt automatisch im Nexus Repository veröffentlicht.

Das WAR-Artefakt wurde im profile-release Repository abgelegt und eindeutig versioniert, basierend auf Build-ID und Timestamp. Dadurch ist jeder Build klar nachvollziehbar und reproduzierbar.

• Repository: profile-release (maven2 hosted)
• GroupId: QA
• ArtifactId: profileapp
• Version: 36-26-01-20_23:46
• Datei: profileapp-36-26-01-20_23:46.war

Zusätzlich wurden automatisch Prüfsummen-Dateien (.md5 und .sha1) generiert, um die Integrität des Artefakts sicherzustellen.



Ergebnis:
Das Artefakt steht nun zentral im Nexus Repository zur Verfügung und kann von weiteren CI/CD- oder Deployment-Prozessen (CD, Docker, Kubernetes, EC2, etc.) wiederverwendet werden.

3.8) Letzter Schritt: Slack Notification

In diesem finalen Schritt wird das Ergebnis der Jenkins-Pipeline automatisch an Slack gesendet. Dadurch wird das Team sofort informiert, ob der Build erfolgreich war oder fehlgeschlagen ist.

Benötigte Credentials / Jenkins Setup / Slack Konfiguration

• Slack – Workspace & Channel erstellen
  Im Slack-Browser einen neuen Workspace erstellen (profilecicd) und darin einen Channel anlegen (#jenkinscicd), der für CI-Benachrichtigungen genutzt wird.
• Slack App „Jenkins CI“ hinzufügen
  In Slack unter Apps hinzufügen nach Jenkins CI suchen, die App installieren, den Channel #jenkinscicd auswählen und anschließend den generierten Token kopieren.
• Slack in Jenkins konfigurieren
  In Jenkins: Manage Jenkins → Configure System → Slack
  • Workspace: profilecicd
  • Credentials: Slack Token als Secret Text in Jenkins speichern
  • Default Channel: #jenkinscicd
  • Test Connection: Verbindung testen und Konfiguration speichern

Benachrichtigungen über den post-Block

Diese Variante ist besonders empfehlenswert, da der post-Block immer ausgeführt wird – unabhängig davon, ob der Pipeline-Status SUCCESS, FAILURE oder ABORTED ist. Der post-Abschnitt wird am Ende der Pipeline, nach allen Stages, definiert.

post {
    always {
        echo 'Slack Notification wird gesendet'

        slackSend(
            channel: '#jenkinscicd',
            color: COLOR_MAP[currentBuild.currentResult],
            message: "*${currentBuild.currentResult}:* Job ${env.JOB_NAME} \
                       Build ${env.BUILD_NUMBER}\nWeitere Details: ${env.BUILD_URL}"
        )
    }
}

Die Funktion slackSend() stammt aus dem Jenkins Slack Notification Plugin und wird verwendet, um Nachrichten aus der Pipeline direkt an einen Slack-Channel zu senden.

• slackSend(
  Startet den Versand einer Slack-Nachricht aus der Jenkins-Pipeline.
• channel: '#jenkinscicd'
  Definiert den Slack-Channel, in den die Nachricht gesendet wird. In diesem Projekt wird der Channel #jenkinscicd verwendet, der speziell für CI/CD-Benachrichtigungen vorgesehen ist.
• color: COLOR_MAP[currentBuild.currentResult]
  Setzt die Farbe der Slack-Nachricht abhängig vom Build-Ergebnis:
  • SUCCESS → Grün
  • FAILURE → Rot
  • UNSTABLE / ABORTED → Gelb
  Dadurch ist der Status des Builds auf einen Blick erkennbar.
• message:
  Definiert den eigentlichen Text der Slack-Nachricht.
• *${currentBuild.currentResult}:*
  Zeigt das finale Ergebnis der Pipeline an (z.B. SUCCESS oder FAILURE). Die Sterne sorgen für eine fettgedruckte Darstellung in Slack.
• Job ${env.JOB_NAME}
  Gibt den Namen des Jenkins-Jobs aus, der die Pipeline ausgeführt hat.
• Build ${env.BUILD_NUMBER}
  Zeigt die eindeutige Build-Nummer an, sodass der Durchlauf eindeutig identifiziert werden kann.
• ${env.BUILD_URL}
  Fügt einen direkten Link zum Jenkins-Build hinzu. Über diesen Link kann sofort auf Logs, Stages und Artefakte zugegriffen werden.

Ergebnis: Der komplette CI-Prozess ist automatisiert – von GitHub Commit bis Artefakt-Upload inklusive Team-Notification.