Projekt anfragen
Nahaufnahme eines Monitors mit farbig hervorgehobenem Programmcode in einem abgedunkelten Arbeitsplatz mit blauem und rotem Umgebungslicht

CI/CD · Build, Prüfung, Auslieferung

CI/CD-Pipelines planen und implementieren

Eine Pipeline, die Build, Test, Artefaktablage und Auslieferung automatisiert, Rückrollen und Freigaben sauber abbildet und ohne langlebige Cloud-Zugangsdaten auskommt. Wir arbeiten mit Ihrem System, meist GitLab CI/CD oder GitHub Actions.

Projekt anfragen Zu den zehn Prüfpunkten
  • GitLab CI/CD und GitHub Actions
  • Artefakte per Digest adressiert
  • Rückrollen getestet

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

01Ausgangslage

Woran Release-Verfahren heute scheitern

SKAFFON plant und implementiert CI/CD-Pipelines für Entwicklungsteams. Meist beginnt es mit einem dieser Muster.

  • YAML-Kopien

    Pipelines wachsen als Kopien in jedem Repository; Änderungen müssen vielfach nachgezogen werden.

  • Build nur bei einer Person

    Der Build läuft nur „bei einer Person“ oder auf einem einzelnen Runner.

  • Langlebige Secrets

    Zugangsdaten für Cloud und Registry liegen als langlebige Secrets in der CI-Konfiguration.

  • Rückrollen von Hand

    Rückrollen heißt: alten Build suchen und manuell deployen.

  • Prüfung zu spät

    Sicherheitsprüfungen sind optional oder laufen erst nach dem Release.

02

Zehn Kontrollpunkte entlang einer Pipeline

Von Commit über Build, Prüfung und Artefakt bis zur Auslieferung: Jeder Punkt sitzt an der Stelle, an der er wirkt.

Zehn Kontrollpunkte entlang einer CI/CD-Pipeline von Commit bis Auslieferung Commit Build Prüfung Artefakt Auslieferung 1 Reproduzierbarer Build 2 Pipeline als Code 3 Geschützter Hauptzweig 4 Keine langlebigen Zugangsdaten 5 Secrets maskiert 7 Prüfstufen mit Schwellwerten 6 Digest-Adressierung 8 Rückrollen getestet 9 Runner getrennt, gehärtet 10 Nachvollziehbarkeit Prüfen Rechte Nachweis
Zehn Kontrollpunkte entlang einer CI/CD-Pipeline von Commit bis Auslieferung Commit 1 Reproduzierbarer Build 2 Pipeline als Code Build 3 Geschützter Hauptzweig 4 Keine langlebigenZugangsdaten Prüfung 5 Secrets maskiert 7 Prüfstufen mit Schwellwerten Artefakt 6 Digest-Adressierung 10 Nachvollziehbarkeit Auslieferung 8 Rückrollen getestet 9 Runner getrennt, gehärtet Prüfen Rechte Nachweis

03Prüfliste

Produktionsreife Pipeline: zehn Punkte, zehn Prüfmethoden

Wir prüfen Ihre Pipeline, vorhanden oder neu gebaut, gegen diese zehn Punkte. Jeder Punkt hat eine Prüfmethode, keine Selbstauskunft.

Zehn Kontrollpunkte einer produktionsreifen Pipeline mit der jeweiligen Prüfmethode
Nr.KontrollpunktPrüfmethode
1Reproduzierbarer BuildGleicher Commit ergibt gleiches Ergebnis in sauberer Umgebung.
2Pipeline als Code im Repository, mit ReviewKeine Konfiguration nur in der Oberfläche.
3Geschützter HauptzweigMerge ohne erfolgreichen Lauf technisch unmöglich.
4Keine langlebigen Cloud-Zugangsdaten in der CIAnbindung per OIDC. GitHub beschreibt, wie ein Workflow-Lauf ein signiertes Token erhält, das der Cloud-Anbieter gegen konfigurierte Vertrauensbedingungen prüft: OpenID Connect in GitHub Actions. Vertrauensbedingungen (Repository, Branch, Umgebung) sind so eng wie möglich zu setzen.
5Secrets maskiert und eingegrenztIn GitLab lassen sich Variablen laut Dokumentation auf geschützte Branches und Tags beschränken (protected) und in Logs verbergen (masked). Prüfung: kein Geheimnis im Klartext im Log oder Repository.
6Artefakt-Adressierung per Digest und Ablage in einer kontrollierten RegistryAuslieferung referenziert Digest.
7Prüfstufen mit vereinbarten Schwellwerten (Abhängigkeiten, Geheimnisse, Image)Schwellwert-Verstoß stoppt die Pipeline wie vereinbart.
8Rückrollen getestetDokumentierte Rücknahme wurde in einer Nicht-Produktivumgebung durchgespielt.
9Runner gehärtet und getrenntRunner für Produktionsauslieferung getrennt von Runnern für ungeprüften Code; minimale Netzrechte.
10NachvollziehbarkeitZu jedem Produktionsstand lassen sich Commit, Pipeline-Lauf und Freigabe zeigen.

04Vorgehen im Projekt

Vom Wildwuchs zur Vorlage in sechs Schritten

  1. 01

    Ist-Aufnahme

    Ergebnis: Zielbild

    Welche Pipelines gibt es, was ist Wildwuchs, was wird zur Vorlage?

  2. 02

    Pipeline-Design

    Ergebnis: Vorlagen

    Stufen für Build, Test, Prüfung, Artefakt, Auslieferung; wiederverwendbare Vorlagen. In GitLab bieten Komponenten laut Dokumentation wiederverwendbare Pipeline-Konfiguration, die in einen CI/CD-Katalog veröffentlicht werden kann.

  3. 03

    Artefakte und Versionierung

    Ergebnis: Registry

    Images und Pakete in einer Registry mit Retention-Regeln, eindeutig adressiert über Digest statt veränderlicher Tags.

  4. 04

    Auslieferung und Rückrollen

    Ergebnis: Verfahren

    Definiertes Verfahren für Freigabe, Auslieferung und Rücknahme je Umgebung.

  5. 05

    Sichere Pipelines

    Ergebnis: Rechte und Stufen

    Zugangsdaten, Berechtigungen und Prüfstufen; Vertiefung in DevSecOps und Supply Chain.

  6. 06

    Einweisung

    Ergebnis: Betriebswissen im Team

    Dokumentation, Runbooks und Einweisung Ihres Teams.

05Werkzeugwahl

GitLab CI, GitHub Actions, Jenkins oder Argo Workflows?

Wir ersetzen Ihre Toolchain nicht, nur weil sie nicht unsere Wahl wäre. Das Raster hilft, wenn eine Entscheidung offen ist.

Entscheidungsraster für CI/CD-Werkzeuge nach Anwendungsfall, Konfiguration, Ausführung und Wechselgrund
KriteriumGitLab CI/CDGitHub ActionsJenkinsArgo Workflows
Typischer AnwendungsfallQuellcode und CI in einem SystemQuellcode und CI in einem SystemBestehende, gewachsene InstallationContainer-native Abläufe auf Kubernetes
Konfiguration.gitlab-ci.yml mit Stufen, Jobs und KomponentenWorkflows im RepositoryEigenes Betriebsmodell der InstallationKubernetes-Ressourcen (Workflow als Custom Resource)
AusführungRunner, vom Anbieter oder selbst betriebenVom Anbieter oder selbst betriebene RunnerSelbst betriebene KnotenContainer-Schritte auf Ihrem Cluster
Wann prüfen wir einen Wechsel?Selten nötigSelten nötigWenn Wartung, Rechte oder Plugin-Pflege zur Last werdenWenn Pipeline-Schritte ohnehin als Cluster-Jobs laufen sollen

Details der Anbieter prüfen Sie vor der Entscheidung in deren Dokumentation: GitLab CI/CD, GitHub Actions, Jenkins, Argo Workflows. Argo Workflows beschreibt sich als Container-native Workflow-Engine für parallele Jobs auf Kubernetes; CI/CD ist ein dokumentierter Anwendungsfall. Bei Kubernetes-nativen Abläufen setzen wir Argo Workflows und eine Container-Registry wie Harbor ein; bestehende Jenkins-Installationen bewerten wir.

06Eingaben

Repositories, Zielumgebungen und Runner: der Startpunkt

Wir brauchen Zugriff auf Repositories und bestehende Pipeline-Konfigurationen (lesend zum Start), die Zielumgebungen (virtuelle Maschinen, Kubernetes, Managed Services), Freigabe- und Nachweisvorgaben (Vier-Augen-Prinzip, Änderungsdokumentation), vorhandene Werkzeuge für Artefakte und Geheimnisse sowie Ansprechpartner aus Entwicklung und Betrieb.

Ob Runner selbst betrieben werden müssen, hängt an Ihrer Netzwerk- und Compliance-Lage und wird früh geklärt.

Vier Entwickler besprechen in einem Büro gemeinsam Programmcode auf einem Monitor

Zugriff auf Zeit, Rechte nur je Pipeline-Stufe

Wir arbeiten in Ihren Repositories, zeitlich und rollenbasiert begrenzt. Pipelines erhalten nur die Rechte der jeweiligen Stufe. Die Pipeline liefert technische Nachweise (Protokolle, Freigaben); eine Compliance-Bewertung ist nicht Teil des Umfangs.

NIS2-Beratung für den Rahmen

07

Wann ein Pipeline-Projekt den größten Hebel hat

Hier lohnt sich der Aufwand

  • Sie wollen Build, Test, Artefaktablage und Auslieferung automatisieren und Rückrollen, Freigaben und Sicherheitsprüfungen sauber abbilden.
  • Sie arbeiten mit GitLab CI/CD oder GitHub Actions, oder eine bestehende Jenkins-Installation soll bewertet werden.

Hier ist ein anderer Einstieg besser

  • Sie suchen ein einzelnes Werkzeug zum Kauf ohne Prozess.
  • Es gibt keine automatisierten Tests: Wir helfen beim Einstieg, die Pipeline ersetzt aber keine Testkultur.
  • Sie brauchen eine interne Entwicklerplattform für viele Teams: Platform Engineering.
  • Sie wollen nur den laufenden Betrieb der Pipelines abgeben: Managed DevOps.

08

Angebot nach Umfang, ohne Listenpreis

Beschreiben Sie Ihr heutiges Release-Verfahren und die größte Reibung; daraus ergibt sich der Rahmen.

09

Pipeline im größeren Zusammenhang

Welche Reibung kostet Sie im Release am meisten?

Schicken Sie uns den Ablauf von Commit bis Produktion, wie er heute ist. Wir sagen Ihnen, wo die Pipeline am meisten gewinnt.

Projekt anfragen