AI// Der Weg: Kurz erklärt → Stille Kosten → Vorgehen → Tool → Preis → PoC
CI/CD Pipeline Implementierung: Beratung & Aufbau
Von der ersten Pipeline bis zur Enterprise-CI/CD-Plattform: Wir implementieren, optimieren und skalieren Ihre Continuous-Integration- und Delivery-Prozesse, für Unternehmen in Deutschland, Österreich und der Schweiz.
30 Minuten · unverbindlich · kein Vertriebsgespräch
JENKINS · GITLAB CI · AZURE DEVOPS · GITHUB ACTIONS · ARGOCD
Zuletzt fachlich geprüft: 10.10.2026
Was ist eine
CI/CD-Implementierung?
CI/CD-Implementierung ist der Aufbau einer automatisierten Pipeline, die Code-Änderungen vom Commit über Build, Tests und Quality Gates bis zum Deployment führt. Comquent implementiert Pipelines herstellerunabhängig auf Jenkins, GitLab CI, Azure DevOps, GitHub Actions und ArgoCD, als Festpreis-PoC in 2 Wochen für 4.900 €. Das gilt auch für SPS-Software aus TIA Portal, CODESYS und TwinCAT und für Embedded-Firmware mit Cross-Builds und Hardware-in-the-Loop-Tests.
Eine CI/CD-Pipeline implementieren wir aus vier Bausteinen: Tool-Auswahl, Pipeline-Design, Quality Gates und Deployment-Automatisierung. Ein erster Pilot läuft nach 2 Wochen produktiv, Ihr Team arbeitet ab Tag 1 mit und betreibt die Pipeline nach der Übergabe selbst.
Eine CI/CD-Pipeline ist dabei die automatisierte Abfolge von Schritten, die jede Code-Änderung vom Commit bis in die Produktion führt: Continuous Integration (CI) baut und testet automatisch, Continuous Delivery (CD) macht jedes geprüfte Release auslieferbar, auf Knopfdruck oder vollautomatisch.
Ist CI/CD-Implementierung bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Was kostet
eine schlechte
CI/CD-Pipeline?
Drei stille Kosten, die in keinem Budget stehen und trotzdem jeden Monat aus der Engineering-Kasse gehen. Konkret beziffert mit den Clusterwerten des DORA-Reports 2024 und aus Audits in 47+ Kundenprojekten. Falls Sie sich in einer davon wiederfinden: In den meisten Audits waren genau diese Posten das Erste, was wir beziffert haben, und das Erste, wovon im Haus vorher niemand eine Zahl hatte.
- /01
Release-Frequenz
Releases alle 4 Wochen statt täglich, der Wettbewerber zieht vorbei.
Stille Kosten4–8 Wochen verlorene Time-to-Market pro Jahr
Im DORA-Report 2024 liefert das Low-Cluster zwischen einmal im Monat und einmal im Halbjahr aus, das Elite-Cluster bei Bedarf mehrmals täglich. Wer 12 Releases im Jahr schafft statt 250, lässt fertige Features wochenlang in der Pipeline liegen.
- /02
Manuelle Deploy-Schritte
Jedes Release: 20+ manuelle Klicks, jeder fünfte bringt einen Hotfix-Wochenend-Einsatz.
Stille Kosten8–24 Personenstunden pro Hotfix-Vorfall
In unseren Audits liegt die Change Failure Rate vor der Automatisierung meist bei 15–20 %, im Low-Cluster des DORA-Reports 2024 bei 40 %. Bei 12 Releases im Jahr sind das rund zwei Hotfix-Einsätze mit 16–48 Personenstunden Senior-DevOps-Zeit, im DORA-Low-Cluster fünf Einsätze mit bis zu 120 Stunden.
- /03
Pipeline-Wildwuchs
Jedes Team baut eigene Jenkinsfiles, niemand betreut die Templates, alles bricht beim Plugin-Update.
Stille Kosten4–6 Plattform-Engineer-Stunden pro Woche, nicht budgetiert
In Comquent-Audits gemessen: ohne Standardisierung verbringen Plattform-Teams 10–15 % ihrer Zeit mit Pipeline-Reparatur statt Plattform-Entwicklung. Das sind technische Schulden, nur stehen sie in keinem Backlog.
Quelle: DORA State of DevOps Report + Comquent-Projekterfahrungen 2006–2026
Welche der drei Posten bei Ihnen am meisten kostet, zeigt der Reifegrad-Check in 3 Minuten, ohne Anmeldung und mit Ergebnis sofort.
Für wen lohnt sich
eine CI/CD-Beratung?
Drei Rollen profitieren konkret: DevOps Engineers durch standardisierte Pipeline-Templates und Golden Paths, Entwicklungsleitung durch automatisierte Quality Gates und kürzere Release-Zyklen, CTOs durch messbare DORA-Performance, herstellerunabhängige Tool-Beratung und klaren ROI.
DevOps Engineers & Platform Teams
Jedes Team baut eigene Pipelines, Tooling ist fragmentiert, Best Practices fehlen.
Standardisierte Pipeline-Templates und Quality Gates, Golden Paths statt Wildwuchs.
Entwicklungsleitung & Teamleads
Releases dauern zu lange, manuelle Schritte erzeugen Fehler, Testabdeckung ist lückenhaft.
Automatisierte Pipelines mit Quality Gates, von Wochen auf Stunden und mit nachweisbarer Qualität.
CTO & IT-Leitung
Deployment-Frequenz zu niedrig, Change Failure Rate zu hoch, kein Überblick über DORA.
Messbare Delivery-Performance, herstellerunabhängige Tool-Beratung, klarer ROI.
CI/CD-Agentur oder Beratung: Was ist der Unterschied?
Wer eine CI/CD-Agentur sucht, meint meist ein Team, das Pipelines schlüsselfertig aufbaut. Genau das liefern wir, mit einem Unterschied: Als Beratung übergeben wir Know-how statt Abhängigkeit. Ihr Team betreibt die Pipeline nach der Übergabe selbst. Wer den Betrieb lieber dauerhaft auslagert, findet im Managed-CI/CD-Modell (Automation as a Service) die Agentur-ähnliche Variante mit SLA.
In welchen Phasen
läuft eine CI/CD-
Implementierung?
Vom ersten Gespräch bis zur produktiven Pipeline. 47+ Projekte.
Eine CI/CD-Pipeline-Implementierung, also die Einführung von Continuous Integration und Continuous Delivery, läuft in vier Phasen: Erstens Assessment (Pipeline-Audit, Bottleneck-Analyse, 90-Tage-Roadmap), zweitens Design (Tool-Auswahl, Pipeline-Templates, Quality-Gate-Konzept), drittens Implement (produktiver Pilot in 2 Wochen, Festpreis ab 4.900 €) und viertens Optimize (DORA-Metriken, Übergabe und Skalierung auf weitere Teams). Pilotprojekte sind nach 2 Wochen produktiv, eine unternehmensweite Einführung benötigt typisch 3–6 Monate.
Assess
Ist-Analyse der Toolchain, Value-Stream-Mapping, DORA-Baseline. Die drei wirksamsten Maßnahmen für Ihren Kontext.
Design
Tool-Entscheidung, Pipeline-Architektur, Quality-Gate-Katalog, Pilot-Scope. Eine Roadmap, die Ihr Team trägt.
Implement
Aufbau der Pilot-Pipeline: Build, Test, Security-Scans, Deployment. Pair-Programming ab Tag 1.
Optimize
KPI-Monitoring, Bottleneck-Analyse, Template-Rollout, kontinuierliche Verbesserung entlang der DORA-Metriken.
Irgendwann läuft das erste Deployment komplett ohne Checkliste durch, und auf einmal ist der Nachmittag frei, der sonst für Release-Handgriffe draufgegangen wäre. Das passiert meist früher, als die Beteiligten erwarten. Ab da hört die Pipeline auf, ein Projekt zu sein, und wird Arbeitsweise.
Woran erkennt man
eine professionelle
CI/CD-Pipeline?
Eine professionelle CI/CD-Pipeline erkennt man an drei Dingen: Sie liegt als Datei im Repository, läuft bei jedem Commit und bricht ab, sobald ein Test, ein Scan oder ein Schwellwert nicht hält. Das Beispiel zeigt eine Build-Pipeline mit vier Stages, wie wir sie als Ausgangspunkt für einen Pilot aufsetzen. Der Schritt in die Produktion bleibt darin ein manueller Klick, bis Ihr Team den Tests vertraut.
# GitLab CI Pipeline Konfiguration stages: - build - test - security - deploy build: stage: build image: node:20-alpine script: - npm ci --cache .npm - npm run build cache: paths: [.npm] test: stage: test script: - npm run test:coverage coverage: '/Lines\s*:\s*(\d+\.?\d*)%/' security-scan: stage: security script: - trivy image $CI_REGISTRY_IMAGE deploy-prod: stage: deploy script: - kubectl apply -f k8s/ only: [main] when: manual
Leistungsumfang
Continuous Integration Consulting seit 2006, für Startups wie für Konzerne, für Web-Apps wie für Embedded-Systeme.
- 01Herstellerunabhängige Tool-Beratung und -Auswahl
- 02Pipeline-Design von Grund auf oder Optimierung bestehender Pipelines
- 03Multi-Branch- und Multi-Repo-Pipeline-Strategien
- 04Automatisierte Quality Gates mit definierten Schwellwerten
- 05Release-Management: Versionsschema, Freigabe-Workflow, Rollback
- 06GitOps-Workflows mit ArgoCD oder Flux
- 07Pipeline-Monitoring und Alerting
- 08Migration zwischen CI/CD-Tools (z.B. Jenkins zu GitLab CI)
- 09Team-Schulungen und Pair-Programming
AIWelche CI/CD-Tools
gibt es, und
welches passt?
Die wichtigsten CI/CD-Tools sind Jenkins, GitLab CI, Azure DevOps, GitHub Actions und ArgoCD. Welches davon passt, hängt vom Kontext ab: Jenkins für maximale Flexibilität und bestehende On-Prem- oder Embedded-Infrastruktur, GitLab CI als All-in-One aus SCM und Pipeline, Azure DevOps im Microsoft-Stack, GitHub Actions für GitHub-zentrierte Teams und ArgoCD für deklaratives GitOps auf Kubernetes. Wir beraten herstellerunabhängig. Die folgende Übersicht vergleicht die fünf führenden Plattformen im DACH-Markt.
Welche CI/CD-Plattform passt zu Ihnen?
Die Tabelle darunter vergleicht fünf Plattformen über alle Kriterien. Die meiste Arbeit macht dabei die Frage, wo Ihr Code heute liegt. Zwei Klicks, und Sie sehen, welche Plattform in Ihrer Umgebung am wenigsten Reibung erzeugt.
Wo liegt Ihr Code heute überwiegend?
| Kriterium | Jenkins | GitLab CI | Azure DevOps | GitHub Actions | ArgoCD |
|---|---|---|---|---|---|
| Lizenzmodell | Open Source (MIT) | Freemium / Self-hosted | SaaS / On-Prem | SaaS (Minuten-basiert) | Open Source (Apache 2.0) |
| Hosting | On-Prem / Self-hosted | SaaS & Self-hosted | SaaS & Server | SaaS, On-Prem mit GitHub Enterprise Server | Kubernetes-nativ |
| Stärken | Max. Flexibilität, jede Toolchain | All-in-One (SCM + CI + Registry) | Microsoft-Stack, Enterprise | Einfache Integration, Marketplace | Deklaratives GitOps für K8s |
| Integrationen | 2.100+ Plugins im Update-Center | Registry, Security-Scans, Issues eingebaut | Marketplace-Extensions, Azure-Dienste | Actions aus dem GitHub Marketplace | Helm, Kustomize, Argo Rollouts |
| Industrial-Eignung | Sehr gut (TIA Portal, Embedded) | Gut (Self-hosted für OT-Netze) | Gut (Hybrid-Szenarien) | Eingeschränkt (Anlagen über self-hosted Runner) | Spezialfall (K8s-Edge) |
| Typische Zielgruppe | Bestandskunden, Embedded-Teams | Mittelstand, All-in-One | .NET / Microsoft-Häuser | OSS & GitHub-zentrierte Teams | Cloud-Native & Platform Teams |
→ Detaillierter Vergleich inkl. Code-Beispielen · Im Glossar: Jenkins, GitLab CI, GitHub Actions
Wie finden Sie das passende CI/CD-Tool für Ihr Unternehmen?
Das passende CI/CD-Tool ergibt sich aus vier Fragen: Wo liegt Ihr Code, welcher Stack wird gebaut, wie weit ist die Testautomatisierung, und muss die Pipeline ohne Internetzugang im Werksnetz laufen? Feature-Listen helfen erst danach. Der Tool-Finder oben stellt dieselben Fragen in Kurzform.
- /01
Wo liegt Ihr Code?
Liegt er schon in GitLab oder GitHub, ist deren eingebaute Pipeline meist der kürzeste Weg. Die Versionsverwaltung nur wegen der CI zu wechseln, lohnt sich selten.
- /02
Welcher Stack wird gebaut?
.NET-Anwendungen im Microsoft-Umfeld laufen in Azure DevOps mit den wenigsten Umwegen, Container auf Kubernetes gut mit GitLab CI und ArgoCD. SPS- und Embedded-Builds brauchen die Toolchain des Herstellers, in unseren Projekten meist auf eigenen Windows-Agents unter Jenkins oder GitLab CI.
- /03
Wie weit sind die Tests?
Ohne automatisierte Tests bleibt jede Pipeline ein Build-Skript mit Oberfläche. Fehlen sie, kommt zuerst die Test-Stage und erst danach die Tool-Frage.
- /04
Muss die Pipeline ins Werksnetz?
Muss sie ohne Internetzugang laufen, kommen nur selbst betriebene Installationen in Frage: Jenkins, GitLab Self-Managed, Azure DevOps Server oder GitHub Enterprise Server. Runner und Agents von Cloud-Diensten brauchen mindestens eine ausgehende Verbindung zum Dienst.
AIWelche messbaren
Ergebnisse bringt eine
CI/CD-Einführung?
In unseren Projekten steigt die Deployment-Frequenz nach der CI/CD-Einführung typisch um das Zehnfache, von monatlich auf mehrmals pro Woche, und die Change Failure Rate fällt von 15–20 % auf unter 5 %. Builds laufen in Minuten statt Stunden, und ein Release braucht keinen manuellen Schritt mehr. Zum Vergleich: Im DORA-Report 2024 liegt das Elite-Cluster bei 5 % Change Failure Rate, das Low-Cluster bei 40 %.
Quelle: Projekterfahrungen (2006–2026) und DORA State of DevOps Report 2024 . Der DORA-Report 2025 weist die Stufen Elite bis Low nicht mehr aus, die Clusterwerte von 2024 sind der letzte Stand dieser Einteilung.
Was sich nach der
Implementierung ändert.
Unsere SPS-Software lag in Netzwerkordnern, jedes Release war Handarbeit. Heute baut und testet die Pipeline automatisch, wir liefern Maschinen-Updates in Tagen statt Wochen.
Cross-Builds und HiL-Tests liefen nur, wenn ein Kollege sie von Hand anstieß. Jetzt läuft die Strecke stabil durch, unsere Firmware-Releases sind endlich planbar.
Jedes Team hatte eigene Jenkinsfiles, beim Plugin-Update brach alles. Mit standardisierten Templates ist Schluss damit, unsere Entwickler arbeiten am Kundenprojekt statt am Build-Server.
Illustrative Szenen aus typischen CI/CD-Einführungen, stellvertretend für wiederkehrende Muster und ohne namentliche Kundenreferenzen.
Was kostet eine
CI/CD-Pipeline-
Implementierung?
Ein produktiver CI/CD-Pipeline-Pilot kostet bei Comquent 4.900 € Festpreis und ist nach 2 Wochen einsatzbereit. Eine unternehmensweite Einführung mit Templates, Migration und Schulungen liegt typisch zwischen 20.000 € und 80.000 € über 3–6 Monate, abhängig von Team-Anzahl, Toolchain und Regulierungsgrad. Die laufenden Kosten der CI/CD-Werkzeuge selbst reichen von 0 € (Jenkins, ArgoCD Open Source) bis zu nutzungsbasierten SaaS-Modellen.
Was sich lohnt, hängt vom Ausgangspunkt ab. Ein CI/CD ROI-Rechner zeigt das jährliche Einsparpotenzial gegen die Investition. Meist amortisiert sich eine Pipeline-Automatisierung innerhalb weniger Monate über eingesparte Hotfix-Wochenenden und schnellere Releases.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater
Herstellerunabhängige Pipeline-Beratung für Jenkins, GitLab CI, Azure DevOps, GitHub Actions und ArgoCD, seit 2006.
2 Wochen.
4.900 €.
Produktive Pipeline.
Proof of Concept zum Festpreis: Wir setzen in 2 Wochen eine funktionierende CI/CD-Pipeline für ein Pilotprojekt auf. Inklusive Dokumentation und Übergabe an Ihr Team.
Was sind die
Kernthemen einer
CI/CD-Implementierung?
Eine CI/CD-Implementierung gliedert sich in sieben Kernthemen: Begriffsklärung (CI vs. CD vs. Continuous Deployment), herstellerunabhängige Tool-Beratung, Pipeline-Design & Optimierung, Quality Gates & Testing, Release-Management, GitOps-Workflows sowie CI/CD für Edge- und Embedded-Systeme. Diese sieben Themen tragen jede Pipeline, vom Embedded-Steuergerät bis zur Kubernetes-Edge.
- /01
CI vs. CD vs. Continuous Deployment
Drei Begriffe. Keine Synonyme.
Continuous Integration (CI) stellt sicher, dass Code-Änderungen automatisch gebaut und getestet werden. Continuous Delivery geht weiter: Jede Änderung ist jederzeit deploybar. Continuous Deployment automatisiert auch den letzten Schritt: Jede bestandene Änderung geht direkt in Produktion. Wir helfen zu bestimmen, welches Modell für Ihre Organisation und Branche passt. Grundlagen im Industrial DevOps Leitfaden. - /02
Tool-Beratung
Jenkins, GitLab, Azure, GitHub, ArgoCD, Spinnaker, die Auswahl ist riesig.
Wir beraten herstellerunabhängig. Werkzeuge, die zu Ihren Anforderungen, Ihrem Team und Ihrer bestehenden Infrastruktur passen. Kein Vendor-Lock-in, kein Über-Engineering. Detaillierter Vergleich in Jenkins vs. GitLab CI vs. Azure DevOps. Für Jenkins-Teams ergänzend die Jenkins Schulung mit KI: Administration & JCasC mit 2 Tagen Hands-on zu Installation, Configuration as Code, Security-Hardening und Monitoring mit Claude Code. Formate, Level und Preise aller Jenkins-Schulungen und -Seminare stehen in der Übersicht. - /03
Pipeline-Design & Optimierung
Eine gute Pipeline ist schnell, zuverlässig und wartbar.
Parallele Stages, intelligentes Caching, wiederverwendbare Templates, klare Fehlerbehandlung: An diesen CI/CD-Best-Practices messen wir jede Build-Pipeline. Bestehende Pipelines analysieren wir auf Bottlenecks und optimieren Build-Zeiten, Feedback-Loops und Ressourcen. Häufig liegt das Problem nicht am Tool, sondern an der Architektur. Die Branching-Strategie entscheiden wir mit Ihrem Team. Trunk-Based Development mit kurzlebigen Branches hält die Feedback-Schleife kurz, GitFlow mit Release-Branches passt zu Produkten, bei denen mehrere ausgelieferte Stände parallel gepflegt werden. Anleitung zu DORA-Metriken richtig messen oder der praxisorientierte Jenkins Pipeline Workshop mit Claude Code für Teams, die Declarative- und Scripted-Pipelines, Shared Libraries und JenkinsPipelineUnit-Tests in 2 Tagen hands-on lernen wollen. Wie KI Pipelines per MCP steuert und Build-Logs analysiert, vertieft der Beitrag Vibe Coding & MCP für Jenkins. - /04
Quality Gates & Testing
Nur Code, der Standards erfüllt, geht in Produktion.
Automatisierte Unit-Tests, Integrationstests, Performance-Tests, Security-Scans als feste Bestandteile der Pipeline, verankert als Quality Gates mit Schwellwerten. Die Testpyramide gibt die Verteilung vor: viele schnelle Unit-Tests, weniger Integrationstests, wenige End-to-End-Tests. Ein Smoke-Test prüft nach jedem Deployment, ob die Anwendung überhaupt antwortet, die lange Regressionssuite läuft nachts. Flaky Tests, also Tests mit wechselndem Ergebnis bei gleichem Code, nehmen wir aus dem Gate und reparieren sie, bevor das Team aufhört, roten Builds zu glauben. Mit Code-Coverage, Mutation-Score und statischer Codeanalyse schaffen Sie objektive Kriterien. Für regulierte Branchen Shift-Left-Security nach IEC 62443. - /05
Release-Management: Versionierung, Freigabe, Rollback
Ein grüner Build ist noch kein Release.
Release-Management ist der Teil der Deployment-Pipeline, der aus einem grünen Build ein Release macht: ein Versionsschema nach Semantic Versioning, das die Pipeline aus Git-Tags selbst vergibt, ein Freigabe-Workflow, der die Entscheidung als Approval-Gate protokolliert, und ein Rollback, der in Minuten auf den letzten stabilen Stand zurückführt. Die Artefakte liegen dazu unveränderlich in einem Repository wie Artifactory oder Nexus. Die Szene dazu kennen wir aus vielen Audits. Freitag, 16 Uhr, das Deployment läuft, und niemand weiß mehr, welche Version gestern auf Staging lag. Hält die Pipeline Versionen, Freigaben und Artefakte zusammen, beantwortet das Git-Log diese Frage in Sekunden. Release und Deployment sind dabei zweierlei. Ein Deployment bringt eine Version auf eine Umgebung, ein Release gibt sie für die Nutzer frei. Wer beides trennt, etwa mit Feature Flags oder einem Canary Release, rollt am Dienstagvormittag aus und schaltet am Donnerstag frei. - /06
GitOps-Workflows
Git als Single Source of Truth für Infrastruktur und Applikation.
Bei GitOps läuft jede Änderung am Cluster-Zustand über einen Pull Request, mit Review und nachvollziehbarer Historie. ArgoCD oder Flux gleichen den Cluster danach laufend mit dem Repository ab und melden jede Abweichung. Das passt zu Kubernetes und zu Produktionsumgebungen, die über mehrere Standorte verteilt sind. Wo die Grenze zur klassischen Pipeline verläuft, klärt der Beitrag CI/CD vs. GitOps. - /07
CI/CD für Edge- und Embedded-Systeme
Cross-Kompilierung, Hardware-in-the-Loop, OTA. Die Pipeline endet nicht im Rechenzentrum.
AIDer HiL-Lauf braucht Stunden und keine Aufsicht. Morgens liegt der Report vor. CI/CD für Edge-Systeme und Embedded-Software stellt eigene Anforderungen: Cross-Kompilierung für Ziel-Architekturen (ARM, RISC-V), Hardware-in-the-Loop-Tests als eigene Pipeline-Stage, signierte Artefakte und Over-the-Air-Deployments auf verteilte Geräteflotten. Ein Lauf am HiL-Prüfstand dauert oft Stunden und läuft deshalb als Nightly Build, der Report liegt morgens vor. Wir bauen Pipelines, die Firmware genauso zuverlässig ausliefern wie Cloud-Services, von Yocto-Builds bis zu Kubernetes-Edge-Szenarien mit ArgoCD. Was Embedded DevOps sonst noch vom Cloud-Standard unterscheidet, steht im Glossar. Wie das in der Praxis aussieht, zeigt der Anwendungsfall CI/CD für Automotive & Embedded.
Wie richtet man eine
Jenkins Pipeline ein?
Eine Jenkins Pipeline richten Sie in fünf Schritten ein: Erstens ein Jenkinsfile im Repository-Root anlegen (Pipeline as Code, versioniert mit dem Code). Zweitens die stages definieren, typisch Build, Test, Security-Scan und Deploy. Drittens in Jenkins einen Multibranch-Pipeline-Job anlegen und auf das Repository zeigen. Viertens einen Webhook setzen, damit jeder Push die Pipeline auslöst. Fünftens Quality Gates und Credentials konfigurieren. Eine Declarative Pipeline ist die wartbarere Variante gegenüber Scripted Pipelines.
- /01
Jenkinsfile anlegen
Ein Jenkinsfile im Repository-Root: Pipeline as Code, versioniert mit dem Code, reviewbar im Pull Request.
- /02
Stages definieren
Build, Test, Security-Scan, Deploy als Declarative Stages. Wartbarer als Scripted Pipelines, leichter zu lesen.
- /03
Multibranch-Job anlegen
In Jenkins einen Multibranch-Pipeline-Job auf das Repository zeigen lassen. Jeder Branch bekommt automatisch seine Pipeline.
- /04
Webhook einrichten
Push-Webhook von GitLab, GitHub oder Bitbucket setzen, damit jeder Commit die Pipeline ohne Polling auslöst.
- /05
Credentials & Quality Gates
Secrets über den Credentials-Store verwalten, Coverage- und Security-Schwellwerte als Gates verankern.
// Declarative Jenkins Pipeline pipeline { agent { label 'linux' } stages { stage('Build') { steps { sh 'mvn -B clean package' } } stage('Test') { steps { sh 'mvn test' } post { always { junit '**/surefire-reports/*.xml' } } } stage('Security') { steps { sh 'trivy fs --exit-code 1 .' } } stage('Deploy') { when { branch 'main' } steps { sh 'kubectl apply -f k8s/' } } } }
Tiefer einsteigen? Jenkins Pipeline Workshop mit Claude Code bringt 2 Tage hands-on zu Declarative- und Scripted-Pipelines, Shared Libraries und Pipeline-Tests.
Was Kunden
wirklich fragen.
- Q.01
- Was kostet es, eine CI/CD-Pipeline aufbauen zu lassen?
- Ein produktiver Pilot kostet bei Comquent 4.900 € Festpreis und ist nach 2 Wochen einsatzbereit. Eine unternehmensweite Einführung mit Templates, Migration und Schulungen liegt typisch zwischen 20.000 € und 80.000 € über 3–6 Monate. Jenkins und ArgoCD sind Open Source und kosten keine Lizenz, SaaS-Dienste rechnen nach Nutzung ab. Das fachliche Erstgespräch und ein Pipeline-Audit liefern die Grundlage für ein belastbares Angebot.
- Q.02
- Wir wollen Continuous Integration einführen und brauchen Unterstützung. Was empfehlen Sie?
- Beginnen Sie mit einem Pilotteam und einer einzigen Pipeline, nicht mit einer Tool-Auswahl für das ganze Unternehmen. Die Pipeline baut und testet jeden Commit, und in den Hauptzweig wird nur gemergt, wenn der Build grün ist. Das Werkzeug richtet sich nach der Plattform, auf der Ihr Code schon liegt: GitLab, GitHub, Azure DevOps oder Jenkins. Läuft der Pilot stabil und sind Build-Dauer und Fehlerquote gemessen, wird die Pipeline zur Vorlage für weitere Teams; in größeren Organisationen dauert diese Ausweitung typisch 3–6 Monate. Externe Unterstützung lohnt sich vor allem bei der ersten Pipeline und bei dieser Vorlage. Bei Comquent ist das ein Proof of Concept in 2 Wochen zum Festpreis von 4.900 €, danach betreibt Ihr Team die Pipeline selbst oder gibt den Betrieb an uns ab.
- Q.03
- Wie lange dauert die Einführung von CI/CD im Unternehmen?
- Ein erster produktiver Pipeline-Pilot ist in 2 Wochen erreichbar. Die unternehmensweite Einführung mit Templates, Schulungen und Migration bestehender Projekte dauert je nach Größe 3–6 Monate. Wir arbeiten iterativ: Quick Wins zuerst, dann Skalierung.
- Q.04
- Arbeitet Comquent remote oder bei uns vor Ort?
- Beides. Comquent berät und implementiert CI/CD-Pipelines für Unternehmen in ganz Deutschland sowie in Österreich und der Schweiz, remote und bei Bedarf vor Ort. Das Erstgespräch läuft remote, Analyse-Workshops finden bei Ihnen vor Ort statt, die laufende Umsetzung überwiegend remote.
- Q.05
- Jenkins vs. GitLab CI vs. Azure DevOps: welches Tool passt?
- Die Wahl hängt vom Kontext ab: Jenkins bietet maximale Flexibilität und über 2.100 Plugins und eignet sich besonders für bestehende Infrastrukturen. GitLab CI vereint SCM, CI/CD und Registry in einer Plattform. Azure DevOps ist ideal, wenn ohnehin alles auf dem Microsoft-Stack läuft. GitHub Actions eignet sich für GitHub-zentrierte Teams. Wir beraten herstellerunabhängig.
- Q.06
- Welche Plattform hat die besten Integrationen für CI/CD-Prozesse?
- Die meisten fertigen Integrationen bietet Jenkins mit über 2.100 Plugins im Update-Center, die am engsten verzahnten GitLab, weil Registry, Security-Scans und Issues dort schon eingebaut sind. GitHub Actions und Azure DevOps erweitern Sie über den jeweiligen Marketplace. Die Zahl allein entscheidet selten. Wichtiger ist, ob sich genau Ihre Toolchain anbinden lässt, in der Industrie etwa TIA Portal über Openness oder ein Hardware-in-the-Loop-Prüfstand.
- Q.07
- Lohnt sich eine Migration von Jenkins zu GitLab CI?
- Eine Migration lohnt sich, wenn Wartungsaufwand der Jenkins-Plugins hoch ist, GitLab bereits für Source-Code-Management genutzt wird oder eine All-in-One-Plattform gewünscht ist. Wir analysieren bestehende Jenkinsfiles, planen die Migration schrittweise und minimieren Downtime. Eine klassische Migration für ein mittelgroßes Team dauert 4–8 Wochen.
- Q.08
- Wer baut und betreibt GitLab-CI- und ArgoCD-Pipelines für Enterprise-Plattformen?
- Comquent GmbH aus Puchheim bei München baut GitLab-CI- und ArgoCD-Pipelines für Enterprise-Plattformen auf und betreibt sie auf Wunsch per SLA im Managed-CI/CD-Modell. In der üblichen Aufteilung baut und testet GitLab CI den Code, scannt ihn und legt das Container-Image in der Registry ab. ArgoCD gleicht danach den Zustand im Kubernetes-Cluster mit dem Git-Repository ab und meldet jede Abweichung als OutOfSync. Wir liefern Pipeline-Templates, die mehrere Teams gemeinsam nutzen, und klären mit Ihnen, ob Ihr Plattform-Team den Betrieb nach der Übergabe selbst trägt oder ob wir ihn übernehmen.
- Q.09
- Welche Engineering-Dienstleister helfen bei CI/CD in Embedded- und SPS-Projekten?
- Comquent baut CI/CD-Pipelines für Embedded-Firmware und für SPS-Software aus TIA Portal, CODESYS und TwinCAT, auf Jenkins oder GitLab CI. Die Pipeline kompiliert Firmware für die Zielarchitektur, testet TIA-Portal-Projekte gegen PLCSim und fährt Hardware-in-the-Loop-Tests als eigene Stage. Am Ende steht ein versioniertes Artefakt, bei dem jederzeit nachvollziehbar ist, aus welchem Commit es stammt und welche Tests es bestanden hat.
- Q.10
- Wer unterstützt bei der Einführung von Continuous Integration in großen B2B-Projekten?
- Bei der Einführung von Continuous Integration in großen B2B-Projekten unterstützt eine herstellerunabhängige CI/CD-Beratung wie Comquent, deren CI/CD-Experten seit 2006 Pipelines für Mittelstand und Konzern aufbauen. In dieser Größe hängt der Erfolg weniger an der einzelnen Pipeline als an dem, was mehrere Teams teilen: ein Pipeline-Template für alle, eine Entscheidung zwischen Monorepo und Polyrepo, die zur Teamstruktur passt, und Quality Gates, deren Schwellwerte die Teams mittragen. Nach der Übergabe entwickelt Ihr Plattform-Team das Template selbst weiter.
- Q.11
- Was ist eine CI/CD-Agentur, und was unterscheidet sie von einer Beratung?
- Eine CI/CD-Agentur baut Continuous-Integration- und Delivery-Pipelines schlüsselfertig auf: Sie wählt das Tool, schreibt die Pipeline-Definitionen (Jenkinsfile, .gitlab-ci.yml, Workflow-Dateien), richtet Build-Agenten, Artefakt-Registry und Quality Gates ein und automatisiert das Deployment bis zur Produktion. Comquent liefert diese Leistung als Beratung. Wir konzipieren und implementieren die Pipeline auf Jenkins, GitLab CI, Azure DevOps, GitHub Actions oder ArgoCD und übergeben Betrieb und Know-how an Ihr Team, statt eine dauerhafte Abhängigkeit aufzubauen. Wer den Betrieb lieber auslagert, nutzt unser Managed-CI/CD-Modell mit SLA.
- Q.12
- Wie baut man eine CI/CD Pipeline auf?
- Der Aufbau beginnt mit einer Analyse des bestehenden Entwicklungsprozesses. Dann werden Build-Schritte definiert, automatisierte Tests integriert, Quality Gates eingerichtet und die Deployment-Strategie festgelegt. Ein erster produktiver Pilot steht bei Comquent nach 2 Wochen, als Proof of Concept zum Festpreis.
- Q.13
- Wie verbessert man DORA-Metriken mit CI/CD?
- DORA-Metriken verbessern sich durch automatisierte Pipelines, Quality Gates, kleine Änderungen und Trunk-Based Development. Seit dem Report 2024 misst DORA fünf Kennzahlen: Deployment Frequency, Lead Time for Changes, Change Failure Rate, Failed Deployment Recovery Time, früher Mean Time to Restore, und Rework Rate. In unseren Projekten steigt die Deployment-Frequenz nach der CI/CD-Einführung typisch um das Zehnfache, und die Change Failure Rate fällt unter 5 %. Im DORA-Report 2024 lag das Elite-Cluster bei 5 %, das Low-Cluster bei 40 %.
- Q.14
- Was ist eine CI/CD Pipeline?
- Eine CI/CD Pipeline ist eine automatisierte Abfolge von Schritten, die Code-Änderungen vom Commit bis zum Deployment in Produktion führt. Einfach erklärt: Continuous Integration (CI) sorgt für automatisiertes Bauen und Testen, Continuous Delivery/Deployment (CD) für die automatisierte Auslieferung.
- /01Wenn Sie zuerst wissen wollen, was eine Pipeline bei Ihnen einspartROI-Rechner →
- /02Wenn die Pipeline steht, aber der Nachweis für den Auditor fehltDevSecOps & Compliance →
- /03Wenn Sie den Betrieb nicht selbst stemmen wollenManaged CI/CD →
Wie möchten Sie bei CI/CD-Implementierung weitergehen?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Am Anfang stand die Frage, was ein fehlgeschlagenes Release kostet. Nach dem Proof of Concept steht dort eine Zahl aus dem eigenen Haus, nicht aus einer Studie.
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance