--- title: "CI/CD-Pipelines planen und implementieren | SKAFFON" description: "CI/CD-Beratung: Pipelines mit GitLab CI oder GitHub Actions bauen, mit Artefaktablage, Rückrollen und ohne langlebige Cloud-Zugangsdaten." url: https://skaffon.de/leistungen/ci-cd-pipelines/ --- ![Nahaufnahme eines Monitors mit farbig hervorgehobenem Programmcode in einem abgedunkelten Arbeitsplatz mit blauem und rotem Umgebungslicht](/_astro/quellcode-auf-monitor-neonlicht.BT7KDJ5f_27Ov3C.jpg) 1. [Startseite](/) 2. [Leistungen](/leistungen/) 3. CI/CD-Pipelines planen und implementieren 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](/projekt-anfragen/) [Zu den zehn Prüfpunkten](/leistungen/ci-cd-pipelines/#zehn-pruefpunkte) - GitLab CI/CD und GitHub Actions - Artefakte per Digest adressiert - Rückrollen getestet Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## 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. ## 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. Prü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. | Kontrollpunkt | Prüfmethode | | --- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 1 | **Reproduzierbarer Build** | Gleicher Commit ergibt gleiches Ergebnis in sauberer Umgebung. | | 2 | **Pipeline als Code im Repository,** mit Review | Keine Konfiguration nur in der Oberfläche. | | 3 | **Geschützter Hauptzweig** | Merge ohne erfolgreichen Lauf technisch unmöglich. | | 4 | **Keine langlebigen Cloud-Zugangsdaten in der CI** | Anbindung 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](https://docs.github.com/en/actions/concepts/security/openid-connect). Vertrauensbedingungen (Repository, Branch, Umgebung) sind so eng wie möglich zu setzen. | | 5 | **Secrets maskiert und eingegrenzt** | In 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. | | 6 | **Artefakt-Adressierung per Digest** und Ablage in einer kontrollierten Registry | Auslieferung referenziert Digest. | | 7 | **Prüfstufen mit vereinbarten Schwellwerten** (Abhängigkeiten, Geheimnisse, Image) | Schwellwert-Verstoß stoppt die Pipeline wie vereinbart. | | 8 | **Rückrollen getestet** | Dokumentierte Rücknahme wurde in einer Nicht-Produktivumgebung durchgespielt. | | 9 | **Runner gehärtet und getrennt** | Runner für Produktionsauslieferung getrennt von Runnern für ungeprüften Code; minimale Netzrechte. | | 10 | **Nachvollziehbarkeit** | Zu jedem Produktionsstand lassen sich Commit, Pipeline-Lauf und Freigabe zeigen. | Vorgehen 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](https://docs.gitlab.com/ci/) 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](/cybersecurity/devsecops-supply-chain/). 6. 06 ### Einweisung Ergebnis: Betriebswissen im Team Dokumentation, Runbooks und Einweisung Ihres Teams. Werkzeugwahl ## 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__ | Kriterium | GitLab CI/CD | GitHub Actions | Jenkins | Argo Workflows | | ------------------------------ | ----------------------------------------------- | ------------------------------------------ | ------------------------------------------------------- | ------------------------------------------------------------- | | Typischer Anwendungsfall | Quellcode und CI in einem System | Quellcode und CI in einem System | Bestehende, gewachsene Installation | Container-native Abläufe auf Kubernetes | | Konfiguration | .gitlab-ci.yml mit Stufen, Jobs und Komponenten | Workflows im Repository | Eigenes Betriebsmodell der Installation | Kubernetes-Ressourcen (Workflow als Custom Resource) | | Ausführung | Runner, vom Anbieter oder selbst betrieben | Vom Anbieter oder selbst betriebene Runner | Selbst betriebene Knoten | Container-Schritte auf Ihrem Cluster | | Wann prüfen wir einen Wechsel? | Selten nötig | Selten nötig | Wenn Wartung, Rechte oder Plugin-Pflege zur Last werden | Wenn Pipeline-Schritte ohnehin als Cluster-Jobs laufen sollen | Details der Anbieter prüfen Sie vor der Entscheidung in deren Dokumentation: [GitLab CI/CD](https://docs.gitlab.com/ci/), [GitHub Actions](https://docs.github.com/actions), [Jenkins](https://www.jenkins.io/doc/book/getting-started/), [Argo Workflows](https://argo-workflows.readthedocs.io/en/latest/). 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. Eingaben ## 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](/_astro/vier-entwickler-besprechen-buero.CGj37mOM_uWWU4.jpg) ## 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](/cybersecurity/nis2-beratung/) ## 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](/leistungen/platform-engineering/). - Sie wollen nur den laufenden Betrieb der Pipelines abgeben: [Managed DevOps](/managed-services/managed-devops/). ## Angebot nach Umfang, ohne Listenpreis Beschreiben Sie Ihr heutiges Release-Verfahren und die größte Reibung; daraus ergibt sich der Rahmen. Was den Aufwand bestimmt Zahl der Anwendungen und Repositories, Zahl der Umgebungen, vorhandener Automatisierungsgrad, Sicherheits- und Freigabeanforderungen und die Frage, ob Runner selbst betrieben werden. ## Pipeline im größeren Zusammenhang - ### [DevOps-Beratung](/leistungen/devops-automatisierung/) Das Gesamtbild aus Infrastruktur, GitOps und Release. Weiter - ### [GitOps mit Argo CD](/leistungen/gitops-argocd/) Die Auslieferung in Kubernetes. Weiter - ### [DevSecOps und Supply Chain](/cybersecurity/devsecops-supply-chain/) Zugangsdaten, Berechtigungen und Prüfstufen vertieft. Weiter - ### [Leistungen](/leistungen/) Die Übersicht aller Leistungen. Weiter ## 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](/projekt-anfragen/)