Die Lösung: eine Pipeline Toolbox – containerisiert, modular, über eine Shared CI wiederverwendbar.

Ausgangsproblem

Ein typisches Beispiel:

• Trivy-Scan: prüft Docker-Images auf CVEs

• Slack-Nachricht: verschickt Ergebnisse

• Jira-Tickets: sollen automatisch aktualisiert werden

Der alte Ansatz sah (vereinfacht) so aus:

audit-image-app-1:
stage: audit
variables:
CI_IMAGE: $REGISTRY/$IMAGE_NAME:$IMAGE_TAG
script:
- docker pull $CI_IMAGE
- trivy image --no-progress --exit-code 1 $CI_IMAGE
- …

Problem: Jede Pipeline enthielt individuellen YAML-Code. Änderungen (z. B. Anpassungen an Trivy) bedeuteten, dass gleich 20+ Repositories angepasst und getestet werden mussten.

Idee & Ziel: Toolbox + Shared CI

Die Kernidee:

• Toolbox (Docker-Image) → enthält Tasks wie JiraUpdateComponent, JiraAuditReportTrivy, SlackSend

• Shared CI → bindet die Toolbox in allen Projekten ein indem es das Docker-Image der Toolbox mit Konfigurationsparametern aufruft.

• Pipeline → importiert die geteilte Logik vom SHARED-CI

So entsteht eine klare Trennung:

• Business-Logik im Docker-Container

• CI/CD-Pipeline im geteilten Layer und im Projekt bleiben minimal

Beispiel (Shared CI):

include:
- project: group/subgroup/shared-ci
file: .gitlab-ci.yml
ref: master

update_jira_ticket:
stage: deploy
image: docker:24.0.5
services:
- docker:24.0.5-dind
script:
- echo "TASK=JiraUpdateComponent" > saved.env
- docker run --env-file saved.env gitlab-registry.dev/.../toolbox:motel-one

Umsetzung der Toolbox

Die Toolbox ist in Deno/TypeScript geschrieben und folgt einer Task-basierten Architektur:

switch (TASK) {
case Tasks.SlackSend:
await sendSlack(SLACK_SEND_MESSAGE, SLACK_SEND_CHANNEL);
break;
case Tasks.JiraUpdateComponent:
await addComponentToTicket();
break;
case Tasks.JiraAuditReportTrivy:
await runAuditReportTask();
break;
}

Branch-Struktur

• main: Basis-Tasks

• motel-one: inkl. Projektspezifischer Anpassungen (z. B. JiraUpdateComponent)

• Feature-Branches: Teams können eigene Tasks hinzufügen

Beispiel-Tasks

1. JiraUpdateComponent

   • Liest Commit- oder MR-Namen

   • Extrahiert Jira-Issue-Key aus dem Commit oder dem Merge Request-Namen (ABC-123)

   • Aktualisiert Metadaten des Tickets automatisiert

2. JiraAuditReportTrivy

   • Scheduled Pipeline (cron: Montag, Dienstag und Donnerstag 9 Uhr)

   • Führt Trivy-Scan für eine App durch

   • Erstellt automatisch Jira-Tickets für jeder gefunden CVE statt nur Slack-Messages

3. SlackSend

   • Leichte Integration für Notifications an einen Slack Channel

Das Setting in der Praxis bei Motel One

Der Workflow heute:

1. Build & Push → Toolbox wird im GitLab Container Registry als Docker Image gespeichert

2. Shared CI → Nutzt dieses Docker Image and Runtime um die Businesslogik in der Pipeline auszuführen

3. Projekt-Pipeline → Importiert die Pipeline mit der Businesslogik aus dem Shared CI und übergibt Parameter

Vergleich:

• Früher: Slack-Message → direkt in Pipeline per Bash

• Heute: Slack-Message → geteilte Pipelines → Toolbox-Task SlackSend

  → Das gleiche gilt für Jira-Updates und CVE-Reports.

Herausforderungen der Umsetzung

• Testing: Änderungen an Shared CI können alle Pipelines brechen → Lösung: Feature-Branch im Shared CI + projektweises Testen

• Artefakte: Übergabe von JSON-Dateien zwischen Toolbox und Pipeline → Lösung via GitLab-API und Artefakt-Handling

Ausblick

Die Toolbox ist aktuell ein Proof of Concept. Die nächsten Schritte sehen wie folgt aus:

• Refactoring der Code-Struktur

• Beteiligung weiterer Entwickler:innen

• Neue Tasks für die Toolbox

Fazit

Die Pipeline Toolbox bei Motel One zeigt, wie DevOps-Teams Komplexität reduzieren können:

• Modularität durch Docker-Tasks

• Wiederverwendbarkeit durch Shared CI

• Automatisierung statt Copy & Paste

Das Ergebnis: Weniger Fehler. Schnellere Anpassungen. Eine zentrale Stelle für Weiterentwicklung und Optmierung in CI/CD Bereich. Mehr Fokus auf das Wesentliche. Das spart im Gesamten Zeit und Ressource, die an anderen Stellen im Projekt viel besser eingesetzt werden können.