Projekt anfragen
Schräge Nahaufnahme eines Bildschirms mit Entwicklungsumgebung, Debug-Ansicht und Thread-Liste im warmen Licht

DevOps · CI/CD · GitOps · Infrastructure as Code

DevOps-Beratung und IT-Automatisierung

Wir bauen mit Ihnen eine Auslieferung, bei der jede Änderung geprüft, nachvollziehbar und umkehrbar in Produktion kommt, statt von Skript, Zuruf oder Einzelwissen abzuhängen.

Projekt anfragen Referenz-Pipeline ansehen
  • GitLab CI oder GitHub Actions
  • GitOps mit Argo CD
  • OpenTofu und Ansible

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

01Ausgangspunkt

Releases, die nicht an einer Person hängen

SKAFFON berät und baut für Entwicklungs- und Betriebsteams, die Releases verlässlich und nachvollziehbar automatisieren wollen: CI/CD-Pipelines, Infrastructure as Code, GitOps-Auslieferung und ein Releaseprozess, der Tests, Sicherheitsprüfungen und Freigaben enthält.

Wir arbeiten mit der Toolchain, die Sie haben, meist GitLab CI oder GitHub Actions, und ergänzen sie dort, wo Lücken sind, etwa mit Argo CD, OpenTofu und Ansible.

02Symptome

Woran Auslieferung heute meist hakt

Nicht jeder dieser Punkte ist für Sie ein Problem. Im Assessment priorisieren wir nach dem, was Ihre Auslieferung heute tatsächlich bremst oder riskant macht.

  • Deployment per Skript

    Deployments laufen per Skript oder von Hand, und nur eine Person kennt den Ablauf.

  • Unerklärte Unterschiede

    Test und Produktion unterscheiden sich in der Konfiguration, und niemand kann sagen, warum.

  • Angeklickte Infrastruktur

    Infrastruktur ist über Konsolen angeklickt und nicht reproduzierbar.

  • Späte Sicherheitsprüfung

    Sicherheitsprüfungen passieren spät oder gar nicht in der Pipeline.

  • Pipelines im Eigenbau je Team

    Jedes Team baut eigene Pipelines; Wissen und Pflegeaufwand sind verteilt.

03Referenzmuster

Von der Änderung zum Cluster: unsere Referenz-Pipeline

Die Pipeline ist unser Referenzmuster, in der Referenzimplementierung mit GitHub Actions, GHCR, Trivy, Syft, Cosign, GitHub Artifact Attestations, Argo CD und Kyverno umgesetzt. Das Repository ist noch nicht veröffentlicht, und die Workflows sind noch nicht in GitHub Actions gelaufen; Details und den Prüfstand beschreibt DevSecOps und Software-Lieferketten.

Referenz-Pipeline: Build, Scan, Signatur, Deploy mit Argo CD Sechs Stufen von Commit bis Argo CD, getrennt in Anwendungscode und Manifest-Repository, mit Admission-Prüfung am Cluster. Anwendungscode-Repository Manifeste / Overlays (oft eigenes Repository) 1 Commit /Merge Request 2 Buildund Test 3 Scanund SBOM 4 Signierenund Ablegen 5 Manifest-Repo(Freigabe per PR) 6 Argo CDsynchronisiert Image-Digest im Manifest Entwicklung Entwicklung /Plattform Security /Plattform Plattform Plattform /Freigeber Plattform Abgleich Soll/Ist Admission-Prüfung Richtlinie, z. B. Signatur Prüf- und Freigabe-Stufen Referenz-Pipeline: von der Änderung bis in den Cluster
Anwendungscode (Stufen 1 bis 4) und Manifeste (Stufen 5 bis 6) liegen in Projekten oft in getrennten Repositories. In Kundenumgebungen setzen wir dasselbe Muster mit der dort vorhandenen Werkzeugkette um, etwa mit GitLab CI und Harbor oder einer anderen Registry. Die Stufen und Verantwortlichkeiten bleiben gleich.
Referenz-Pipeline: Build, Scan, Signatur, Deploy mit Argo CD Sechs Stufen von Commit bis Argo CD, getrennt in Anwendungscode und Manifest-Repository, mit Admission-Prüfung am Cluster. Referenz-Pipeline: von der Änderungbis in den Cluster Anwendungscode-Repository 1 Commit / Merge RequestEntwicklung 2 Build und TestEntwicklung / Plattform 3 Scan und SBOMSecurity / Plattform 4 Signieren und AblegenPlattform Image-Digest im Manifest Manifeste / Overlays(oft eigenes Repository) 5 Manifest-Repo(Freigabe per PR)Plattform / Freigeber 6 Argo CD synchronisiertPlattform Abgleich Soll/Ist Admission-Prüfung Richtlinie, z. B. Signatur Prüf- und Freigabe-Stufen
Anwendungscode (Stufen 1 bis 4) und Manifeste (Stufen 5 bis 6) liegen in Projekten oft in getrennten Repositories. In Kundenumgebungen setzen wir dasselbe Muster mit der dort vorhandenen Werkzeugkette um, etwa mit GitLab CI und Harbor oder einer anderen Registry. Die Stufen und Verantwortlichkeiten bleiben gleich.

04Stufen im Detail

Sechs Stufen, jede mit klarem Verantwortlichen

  1. 01

    Commit und Merge Request

    Entwicklung

    Änderung wird geprüft (Review, geschützter Hauptzweig). Nichts erreicht den Hauptzweig ohne Pipeline-Lauf.

  2. 02

    Build und Test

    Entwicklung, Plattform-Vorlage

    Reproduzierbarer Build in einer sauberen Umgebung, Unit- und Integrationstests. Schlägt ein Test fehl, endet die Pipeline.

  3. 03

    Scan und SBOM

    Security-Vorgaben, Plattform

    Prüfung von Manifesten, Dockerfile und Container-Image auf bekannte Schwachstellen, Fehlkonfigurationen und eingecheckte Geheimnisse mit Trivy. In der Referenzimplementierung bricht jeder Befund HIGH oder CRITICAL den Lauf ab, Ausnahmen nur mit Begründung, Ablaufdatum und Freigabe durch eine zweite Person. Dazu erzeugt Syft je eine Software-Stückliste (SBOM) in SPDX und CycloneDX. In Projekten legen wir Schwellwerte mit Ihnen fest; nicht jeder Befund blockiert.

  4. 04

    Signieren und Ablegen

    Plattform

    Das Image wird erst nach bestandenen Prüfungen in die Registry (GHCR) geschrieben und per Digest adressiert, mit Sigstore Cosign keyless signiert und mit SBOM-Attestierungen und einer Build-Provenance (GitHub Artifact Attestations) versehen. Der Cluster lässt per Kyverno-Richtlinie nur Images mit gültiger Signatur zu, wenn Sie das wünschen.

  5. 05

    Manifest-Repository

    Plattform, Freigabe je Umgebung

    Der gewünschte Zustand der Umgebung liegt als Code in Git: in der Referenzimplementierung im selben Repository (Kustomize-Overlays je Umgebung), in Projekten meist in einem eigenen Manifest-Repository. Ein Skript trägt den geprüften Image-Digest ein; die Änderung geht als Pull Request durch Review, und der Merge ist die Freigabe. Jede Änderung ist nachvollziehbar und umkehrbar.

  6. 06

    Auslieferung durch Argo CD

    Plattform

    Argo CD gleicht den Cluster-Zustand mit dem Repository ab und stellt ihn her; in der Referenzimplementierung synchronisiert die Staging-Umgebung automatisch, die Produktionsumgebung nur durch eine Person. Ein manuelles Rückrollen entspricht einem Revert im Repository. Abweichungen im Cluster fallen auf.

Designprinzip

Der Cluster zieht seinen Zustand, die Pipeline schiebt nichts hinein

Der Cluster braucht keine Zugangsdaten der Pipeline, sondern zieht den Zustand selbst, und Entwicklung und Freigabe sind sauber getrennt. Das ist Konzept, kein Qualitätsurteil über Alternativen: Wer keine Kubernetes-Umgebung hat, liefert mit derselben Stufenlogik per Pipeline oder Ansible aus.

05Ergebnisse

Was Sie am Ende des Projekts in der Hand haben

  • Zielbild und Prioritätenliste

    Bewertung Ihrer Toolchain: Was ist vorhanden, was passt, wo sind Lücken. Bewährtes ersetzen wir nicht, nur weil es nicht unsere Wahl gewesen wäre.

  • Wiederverwendbare Pipeline-Vorlagen

    Build, Test, Sicherheitsprüfung, Artefaktablage und Auslieferung als Vorlagen, damit neue Projekte nicht bei Null beginnen.

  • Umgebungen als Code

    Mit OpenTofu oder Terraform: Modulstruktur, Remote-State mit Sperre, Trennung der Umgebungen, Review-Prozess für Änderungen und Erkennung von Konfigurationsabweichungen (Drift). Serverkonfiguration, wo nötig, mit Ansible.

  • Ein belastbarer Releaseprozess

    Branching- und Versionsmodell, Freigaben, Rückrollen, Umgang mit Hotfixes und Dokumentation von Änderungen für Audits.

  • Geprüfte Betriebsautomatisierung

    Bereitstellen von Umgebungen, Zertifikate, Backups und Benutzerverwaltung als Automatisierung statt Einzelhandarbeit.

  • Übergabe an Ihr Team

    Dokumentation, Runbooks, Einweisung. Ihr Team soll die Pipelines danach selbst weiterentwickeln können.

06Grenzen

Rechte, Geheimnisse, Nachweise: wo die Pipeline Grenzen hat

Eine Pipeline bekommt nur so viel Zugriff, wie die vereinbarte Auslieferungsstufe braucht.

  • Geheimnisse liegen in einem Secret-Store, nicht in Repositories oder Pipeline-Variablen im Klartext.
  • Pipelines laufen mit minimalen Rechten; Zugriff auf Produktion nur über die vereinbarte Auslieferungsstufe.
  • Wir arbeiten in Ihren Repositories und Konten. Zugriffe sind zeitlich und rollenmäßig begrenzt.
  • Die Pipeline erfüllt Ihre Nachweispflichten technisch (Protokolle, Freigaben). Eine Compliance-Bewertung ist nicht Teil des Umfangs.

Für NIS2-Anforderungen: NIS2-Beratung

Netzwerk-Switch mit leuchtenden Ports und gebündelten schwarzen Patchkabeln vor einem beschrifteten Patchfeld

07Startbedingungen

Was wir von Ihnen zum Start brauchen

Lesender Zugriff genügt zum Einstieg.

  • Zugriff auf Repositories und bestehende Pipelines (lesend zum Start)
  • Beschreibung der Zielumgebungen: virtuelle Maschinen, Kubernetes, Managed Services
  • Ihre Freigabe- und Compliance-Vorgaben, zum Beispiel Vier-Augen-Prinzip und Änderungsdokumentation
  • Die vorhandenen Werkzeuge für Quellcode, Artefakte und Geheimnisse
  • Ein Ansprechpartner aus der Entwicklung
  • Ein Ansprechpartner aus dem Betrieb

08Abgrenzung

Wann DevOps-Beratung von uns das Richtige ist, und wann nicht

Das passt

  • Sie haben Repositories und Pipelines und wollen sie verlässlich, wiederverwendbar und prüfbar machen.
  • Ihr Team soll die Pipelines danach selbst weiterentwickeln.

Das passt nicht

  • Sie suchen ein einzelnes Werkzeug zum Kauf. Wir beraten werkzeugunabhängig und bauen die Pipelines mit Ihnen.
  • Es gibt keine Tests. Wir helfen beim Einstieg, eine Pipeline ersetzt aber keine Testkultur.
  • Die Organisation will keine Verantwortung für die Pipelines übernehmen. Dann bieten wir den Betrieb an, siehe Managed Services.
  • Sie brauchen eine interne Entwicklerplattform für viele Teams; das ist ein eigenes Thema: Platform Engineering.

Beschreiben Sie Ihre Auslieferung und die größte Reibung

Aus Ihrer Beschreibung entsteht ein Angebot mit klar umrissenen Ergebnissen. Weitere Themen finden Sie in der Leistungsübersicht.

Projekt anfragen