Projekt anfragen
Zwei Entwickler arbeiten in einem hellen Büro an Monitoren und einem Laptop mit Quellcode

Managed DevOps · CI/CD, GitOps, Registry

DevOps as a Service: Pipelines und Plattform im Betrieb

SKAFFON betreibt die Plattform, auf der Ihre Teams bauen und ausliefern: Pipelines, Runner, Argo CD, Harbor und Renovate samt Upgrades. Ihre Entwickler liefern, statt Pipelines zu reparieren.

Projekt anfragen Zum Upgrade-Ablauf
  • GitLab CI oder GitHub Actions
  • GitOps mit Argo CD
  • Container-Registry Harbor
  • Renovate für Abhängigkeits-Updates

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangslage

Wenn die CI morgens rot ist und niemand zuständig ist

Veraltete Runner, eine Pipeline, die seit Wochen langsamer wird, ein Argo CD, dessen Upgrade keinem gehört: Das ist die Lücke, die dieser Service schließt. Er richtet sich an IT-Leitung und Engineering-Verantwortliche, deren Entwicklungsteams liefern sollen. Betrieb und Support laufen 24/7; Reaktionszeiten und Kennzahlen werden vertraglich festgelegt.

„Managed DevOps“ meint bei uns keinen Produktnamen eines Cloud-Anbieters, sondern den Betrieb Ihrer Delivery-Plattform. Soll die Plattform erst entstehen, beginnt der Weg bei DevOps und Automatisierung, CI/CD-Pipelines oder Platform Engineering; danach übernimmt dieser Service. Die Einordnung im Bereich steht unter Managed Services.

02Plattform

Vom Commit bis zum Cluster: eine Lieferkette, ein Betreiber

Argo CD läuft auf einem Kubernetes-Cluster. Wir betreiben die Stationen der Kette und halten sie aktuell; den Anwendungscode und dessen Tests verantworten Ihre Teams.

Delivery-Plattform im Betrieb Ablauf von Git-Repository über Pipeline und Registry zu GitOps und Cluster, mit Renovate, Runnern und Monitoring. BETRIEB DER DELIVERY-PLATTFORM Git-RepositoryCode und Manifeste CI-PipelineBuild, Test, Scan RegistryContainer-Images GitOpsAbgleich Git/Cluster ClusterIhre Apps RunnerPatching, Skalierung Abhängigkeits-Updates Monitoring, Backup, Upgrades und MonatsberichtPipeline-Laufzeiten, Sync-Status, Registry-Füllstand, Wiederherstellungstests Von SKAFFON betrieben: Plattform und gemeinsame Vorlagen Beim Kunden: Anwendungscode, Tests, fachliche Freigaben
Die Delivery-Plattform als Kette: Git, Pipeline, Registry, GitOps, Cluster.
Delivery-Plattform im Betrieb Ablauf von Git-Repository über Pipeline und Registry zu GitOps und Cluster, mit Renovate, Runnern und Monitoring. BETRIEB DER DELIVERY-PLATTFORM Git-RepositoryCode und Manifeste CI-PipelineBuild, Test, Scan RegistryContainer-Images GitOpsAbgleich Git/Cluster ClusterIhre Apps Abhängigkeits-Updates RunnerPatching,Skalierung Von SKAFFON betrieben: Plattform undgemeinsame Vorlagen Beim Kunden: Anwendungscode, Tests,fachliche Freigaben Monitoring, Backup, Upgradesund Monatsbericht Pipeline-Laufzeiten, Sync-Status,Registry-Füllstand,Wiederherstellungstests
Die Delivery-Plattform als Kette: Git, Pipeline, Registry, GitOps, Cluster.

03Betriebsumfang

Neun Aufgaben, die wir an Ihrer Delivery-Plattform übernehmen

  • Pipeline-Wartung

    Pflege der gemeinsamen Pipeline-Vorlagen und Runner (GitLab CI oder GitHub Actions): Fehlerbehebung, Anpassungen bei Plattform-Änderungen, Aufräumen langsamer oder instabiler Jobs, Cache- und Artefaktverwaltung.

  • Runner-Betrieb

    Bei selbst betriebenen Runnern Betriebssystem, Software, Skalierung und Härtung. Bei GitHub Actions muss laut Dokumentation aktuell halten, wer Self-Hosted-Runner einsetzt (GitHub: Self-hosted Runners); bei GitLab lassen sich eigene Runner auf physischen oder virtuellen Maschinen registrieren (GitLab: CI/CD).

  • Release-Sicherheit

    Freigabeprozess, Schutz von Geheimnissen in Pipelines, Zugriffsrechte auf Repositories und Registry, Prüfschritte (Scans, Signaturen), soweit mit Ihnen vereinbart.

  • GitOps-Betrieb

    Argo CD: Struktur der Repositories, Synchronisationsrichtlinien, Zugriff, Benachrichtigungen, Wiederherstellung. Pipelines brauchen laut Dokumentation keinen direkten Zugriff auf die Argo-CD-API, sie schreiben nur in Git (Argo CD: Automated Sync Policy). Vertiefung: GitOps mit Argo CD.

  • Registry-Betrieb

    Harbor als Container-Registry: Projekte und Berechtigungen, Robot-Konten, Replikation, Proxy-Cache, Schwachstellen-Scans, Speicherbereinigung.

  • Abhängigkeits-Updates

    Renovate öffnet Pull Requests nach Zeitplan und Regeln; es unterstützt unter anderem GitHub, GitLab und Gitea und lässt sich selbst betreiben (Renovate: Docs). Wir betreiben es und pflegen die Regeln; die Freigabe fachlicher Updates bleibt bei Ihren Teams.

  • Upgrades der Plattform

    Runner, Argo CD, Harbor, Renovate und Pipeline-Bausteine nach festem Ablauf, siehe unten.

  • Beobachtbarkeit der Delivery

    Pipeline-Dauer, Fehlerquote, Warteschlangen, Synchronisationsstatus, Registry-Füllstand: eigene Dashboards und Alarme.

  • Monatsbericht

    Störungen, Änderungen, Upgrades, Auffälligkeiten und Empfehlungen.

04Registry

Harbor: Speicher, Berechtigungen und Replikation unter Kontrolle

Die Container-Registry ist der Ort, an dem Pipeline und GitOps zusammentreffen: Was die CI baut, zieht der Cluster von hier. Wir pflegen Projekte, Robot-Konten und Aufbewahrungsregeln, räumen Speicher nach Regeln auf und sichern die Registry-Daten vor jedem Upgrade.

Bei mehreren Registries kommt eine Besonderheit hinzu: Harbor-Replikation zwischen verschiedenen Harbor-Versionen wird laut Dokumentation nicht unterstützt (Harbor: Replication). Deshalb koordinieren wir die Upgrades beider Seiten.

  • Projekte, Berechtigungen und Robot-Konten
  • Replikation und Proxy-Cache
  • Schwachstellen-Scans
  • Speicherbereinigung nach Aufbewahrungsregeln
Blaue Platine einer Festplatte mit SATA-Anschluss vor weißem Hintergrund

05Upgrades

Upgrade-Reihenfolge: der Teil, der sonst liegen bleibt

Upgrades bleiben in vielen Organisationen liegen. Unser Ablauf für Runner, Argo CD, Harbor und Renovate:

  1. 01

    Vorbereiten und sichern

    Vorbereitung

    Versionshinweise und Kompatibilität prüfen, Zustand sichern. Für Argo CD beschreibt die Dokumentation Export und Import des Konfigurationszustands per argocd admin export und import (Argo CD: Disaster Recovery).

  2. 02

    Auf einer Testinstanz erproben

    Test

    Auf einer nicht produktiven Instanz oder einem Testcluster; Pipelines und Synchronisationen probehalber ausführen.

  3. 03

    Registries aufeinander abstimmen

    Harbor

    Bei mehreren Registries die Upgrades beider Seiten koordinieren, weil Replikation zwischen verschiedenen Harbor-Versionen nicht unterstützt wird.

  4. 04

    Produktiv im Wartungsfenster

    Mit Rückfallplan

    Upgrade mit Rückfallplan und anschließendem Funktionstest.

  5. 05

    Runner in Wellen

    Kein Totalstillstand

    Runner nacheinander aktualisieren, damit Pipelines nicht vollständig stillstehen.

  6. 06

    Abschließen

    Ergebnis: dokumentiert

    Pipelines und Deployments laufen lassen, Ergebnis dokumentieren, Wartungsplan anpassen.

06Zuständigkeiten

Wer führt aus, wer verantwortet: die Aufteilung bei Pipeline und Plattform

R = führt aus, A = trägt die Ergebnisverantwortung, C = wird konsultiert, I = wird informiert. Standardaufteilung, vertraglich anpassbar.

Verantwortungsmatrix (RACI) für Managed DevOps
TätigkeitSKAFFONKunde
Gemeinsame Pipeline-Vorlagen pflegenR/AC
Anwendungsspezifische Pipeline-Schritte (Build, Tests)CR/A
Pipeline-Störung durch Plattform (Runner, Cache, Registry, Netz)R/AI
Pipeline-Störung durch Anwendungscode oder TestsCR/A
Runner betreiben und patchenR/AI
Argo CD und GitOps-Plattform betreibenR/AC
Anwendungs-Manifeste und Helm-ChartsCR/A
Registry (Harbor) betreiben, Speicher bereinigenR/AC
Freigabe fachlicher Abhängigkeits-UpdatesCR/A
Renovate betreiben, Regeln pflegenRA
Upgrades der Plattformkomponenten durchführenRA (Freigabe Fenster)
Zugriffsrechte technisch umsetzenRA
Wer bekommt welche Rechte (fachliche Entscheidung)CR/A
Geheimnisse in Pipelines verwalten (Technik)RA
Sicherheitsrichtlinien festlegen (Was wird geblockt)CR/A
Kapazitäts- und KostenberichteRA

Ihre Anwendungen und deren Qualität bleiben in Ihrer Verantwortung. Wir verantworten den Betrieb der Plattform, auf der sie gebaut und ausgeliefert werden.

07Wartungsplan

Was regelmäßig passiert, was es auslöst und was danach vorliegt

Zeitliche Rhythmen vereinbaren wir je Umgebung; wir geben hier keine Standardintervalle vor.

Wartungsplan: Aufgabe, Auslöser, Ergebnis
AufgabeAuslöserErgebnis
Pipeline-GesundheitsprüfungRegelmäßig und bei AuffälligkeitenListe langsamer, instabiler oder ungenutzter Jobs, Maßnahmenvorschläge
Runner-PatchingHerstellermeldung, RegelzyklusAktualisierte Runner-Images, dokumentierte Änderung
Abhängigkeits-UpdatesRenovate-ZeitplanPull Requests nach Regeln; automatisch zusammengeführt oder zur Prüfung
Argo-CD-UpgradeNeue Version, SicherheitsmeldungAktualisierte Installation mit Test und Rückfallplan
Harbor-UpgradeNeue Version, SicherheitsmeldungAktualisierte Registry, Datensicherung vorher
Zugriffs-ReviewRegelmäßig, bei PersonalwechselBereinigte Konten, Tokens und Robot-Konten
Registry-BereinigungFüllstand, RegelzyklusFreigegebener Speicher nach Aufbewahrungsregeln
Sicherung der Plattform-KonfigurationRegelmäßigGesicherter Argo-CD-Zustand, Registry-Daten, Pipeline-Konfiguration
Wiederherstellungs-TestRegelmäßigTestprotokoll

Grenze

Fachliche Updates gehen nie ohne Ihre Freigabe in Produktion

Wir betreiben Renovate und pflegen die Regeln, die Sie freigeben. Was automatisch zusammengeführt werden darf und was Review braucht, entscheiden Sie.

08Störungen und Änderungen

Incident, Change, Patch: so läuft es, wenn etwas passiert oder sich ändert

Störungen werden nach Priorität eingestuft, zum Beispiel: Pipelines stehen still, Deployment nicht möglich, Registry nicht erreichbar. Die Stufen P1 bis P4 und die Bedeutung der Reaktionszeit stehen im Servicelevel-Rahmen; Reaktionszeiten und Eskalationskette legt der Vertrag fest. Kontaktwege testen wir im Onboarding mit Ihnen.

  • Incident

    Alarm oder Meldung, Priorisierung, Eingrenzung (Plattform oder Anwendung?), Behebung oder Workaround, Statusinformation, Abschluss mit Ihrer Bestätigung, bei schwerwiegenden Störungen Ursachenanalyse.

  • Change

    Änderungen an Pipeline-Vorlagen, Regeln und Plattform-Konfiguration als Code mit Review; Freigabe durch Sie, Umsetzung durch SKAFFON, Verifikation, vorher ein Rückfallplan.

  • Patch

    Sicherheitsmeldungen zu den Plattformkomponenten werden bewertet; dringende Updates stimmen wir außerhalb des Regelzyklus mit Ihnen ab.

09Transparenz

Was wir an der Delivery messen und Ihnen zeigen

Alarmiert wird auf Plattformebene; der Monatsbericht fasst Störungen, Änderungen, Upgrades und Empfehlungen zusammen.

  • Pipeline-Laufzeiten
  • Fehlerraten der Pipelines
  • Warteschlangen der Runner
  • Synchronisationsstatus und Gesundheit in Argo CD
  • Füllstand der Registry
  • Gesundheit der Registry

10Sicherung und Zusagen

Sicherung, Wiederherstellung und warum wir keine pauschale Verfügbarkeit nennen

Gesichert werden der Zustand von Argo CD, die Daten der Registry und die Konfiguration von Pipelines und Runnern. Der Soll-Zustand Ihrer Anwendungen liegt in Git; Quellrepositories sichern Sie in Ihrem Git-System, wir stimmen die Sicherung mit Ihnen ab. Wiederherstellung wird getestet, siehe auch Backup und Disaster Recovery.

Verfügbarkeitsziele vereinbaren wir je Plattform; sie hängen von Architektur, Zahl der Runner, Hochverfügbarkeit der Komponenten und Wartungsfenstern ab. Kennzahlen, Messmethode und Folgen bei Abweichung werden vertraglich vereinbart; die Systematik beschreibt der Servicelevel-Rahmen.

11Einstieg

Vom Bestand in den Regelbetrieb

Wir starten mit einer Bestandsaufnahme und legen daraus Umfang, RACI und Berichtsrhythmus fest.

  1. 01

    Bestandsaufnahme

    Ergebnis: Ist-Stand

    Repositories, Pipelines, Runner, Registry, GitOps-Struktur, Zugriffe und bekannte Schwächen.

  2. 02

    Zielbild und RACI

    Ergebnis: Zuständigkeiten

    Umfang und Verantwortungsmatrix auf Ihre Umgebung zuschneiden.

  3. 03

    Monitoring und Backup

    Aufnahme

    Die Plattform in Überwachung und Sicherung aufnehmen.

  4. 04

    Erste Gesundheitsprüfung

    Ergebnis: Maßnahmenliste

    Pipeline-Gesundheitsprüfung als Startpunkt; größere Umbauten laufen als Projekt über CI/CD-Pipelines.

  5. 05

    Regelbetrieb

    Übergang

    Übergang in den laufenden Betrieb nach Wartungsplan.

12Passung

Delivery-Betrieb abgeben: wann es sich anbietet, wann ein anderer Weg besser ist

Es bietet sich an, wenn Sie …

  • eigene Runner, GitOps oder eine eigene Registry nutzen und deren Betrieb abgeben wollen.
  • Zugriff auf Repositories und Pipelines gewähren können.
  • fachliche Abhängigkeits-Updates selbst freigeben.

Ein anderer Weg ist besser, wenn Sie …

  • Entwickler für Ihre Anwendung suchen; dafür gibt es Individualsoftware.
  • ausschließlich einen vollständig verwalteten Pipeline-Dienst eines Anbieters ohne eigene Runner oder Plattform nutzen und damit zufrieden sind.
  • keinen Zugriff auf Repositories und Pipelines gewähren wollen.
  • erwarten, dass fachliche Updates ohne Ihre Freigabe in Produktion gehen.

13

Häufige Fragen

Betreiben Sie GitLab oder GitHub selbst?

Wir betreiben die Plattform um Ihr Git-System herum: Runner, Pipelines, GitOps, Registry. Ob das Git-System selbst (GitLab Self-Managed oder ein anderes) zum Umfang gehört, legen wir je Umgebung fest.

Wer entscheidet, was Renovate automatisch zusammenführt?

Sie. Wir schlagen Regeln vor und setzen die von Ihnen freigegebenen um.

Können Sie unsere vorhandene Pipeline erst aufräumen?

Ja, als Teil des Onboardings; größere Umbauten laufen als Projekt über CI/CD-Pipelines.

Beschreiben Sie Repositories, Pipelines und Teams

Aus Ihrer Beschreibung entsteht die Bestandsaufnahme, aus ihr Umfang, RACI und Berichtsrhythmus.

Projekt anfragen Kontakt