// Der Weg: Kurz erklärt → Umfang → Zuständigkeit → Ablauf → Kosten
DevOps as a Service: Managed CI/CD für Ihre Pipeline-Plattform
Wir betreiben Jenkins, GitLab CI, Azure DevOps, GitHub Actions und ArgoCD für Sie, als DevOps-Dienstleister im DACH-Raum. Managed CI/CD und DevOps Outsourcing per SLA. Damit Ihre Entwickler entwickeln. Nicht administrieren.
30 Minuten · unverbindlich · kein Vertriebsgespräch
JENKINS · GITLAB CI · AZURE DEVOPS · GITHUB ACTIONS · SEIT 2006 · DACH
Zuletzt fachlich geprüft: 28.10.2026
Was ist
DevOps as a Service?
DevOps as a Service, auch Managed CI/CD oder DevOps Outsourcing genannt, heißt, dass ein externer Dienstleister Ihre CI/CD-Plattform per SLA betreibt und Ihr Team die Pipelines nur noch nutzt. Comquent übernimmt das im DACH-Raum für Jenkins, GitLab CI, Azure DevOps, GitHub Actions und ArgoCD, auf Ihrer Infrastruktur: Patching, Backup, Plugin-Management, Pipeline-Tuning und Incident-Response mit definierten Reaktionszeiten. Andere Namen dafür sind Managed DevOps, CI/CD Managed Service oder DevOps-Dienstleister. Die Übernahme dauert 2–4 Wochen, abgerechnet wird ein monatlicher Festpreis je Paket, monatlich kündbar. Das passt für Industrie und Mittelstand, wenn im Haus niemand den Pipeline-Betrieb als eigene Aufgabe hat.
Laufender CI/CD-Betrieb per SLA · kein Projekt, sondern Verantwortungsübernahme.
Ihr System läuft weiter auf Ihrer Infrastruktur, on-premise oder in Ihrer eigenen Cloud. Die operative Verantwortung liegt bei uns. Das ist kein SaaS und kein Angebot eines allgemeinen Managed-Service-Providers. Hier arbeiten CI/CD-Spezialisten mit zwanzig Jahren Erfahrung, die industrielle Umgebungen, regulierte Branchen und gewachsene Build-Infrastrukturen aus eigenen Projekten kennen.
Comquent betreibt CI/CD-Plattformen im Kontext Industrial DevOps. Die Arbeit beginnt am laufenden System. Wir übernehmen eine bestehende Instanz, statt auf der grünen Wiese neu zu bauen, und eine CI/CD-Implementierung gibt es nur dort, wo die Strecke wirklich neu entstehen muss. Dazu kommen Patch- und Update-Fenster mit Ansage und ein Runbook, nach dem auch jemand arbeiten kann, der die Instanz nie selbst aufgesetzt hat.
Ist Managed CI/CD 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.
Vier Sätze, die wir jede Woche hören.
“Jenkins läuft seit drei Jahren. Niemand traut sich, es anzufassen.
Der Kollege, der das aufgebaut hat, ist weg. Doku? Gibt es nicht.
Jedes Release ist ein manueller Stress-Sprint.
Security-Updates auf dem Build-Server? Schon länger nicht gemacht.
→ Antwort
Sie brauchen keine neue Software. Sie brauchen jemanden, der die Verantwortung übernimmt.
Welche DevOps Services
übernimmt Comquent
im Managed-Betrieb?
- /01
Betrieb & Administration
Der laufende CI/CD-Server, auf Ihrer Infrastruktur und unter unserer Verantwortung.
- —Managed Jenkins, GitLab CI, Azure DevOps, GitHub Actions
- —On-Premise, Cloud oder Hybrid
- —Plugin-Management, Updates, Security-Patches
- —Monitoring, Alerting, Backup & Recovery
- —SLA-basierter Support mit Reaktionszeiten
Als DevOps Managed Services heißt das konkret: Jenkins-Administration und Support als Service, GitLab-Betrieb inklusive Runner, dazu die Build-Agents für Azure DevOps und GitHub Actions. Auch der Build-Server, den niemand mehr patchen will, gehört dazu. Soll die Administration im eigenen Team bleiben, ist der Workshop Jenkins Administration & KI das Inhouse-Pendant.
- /02
Pipeline-Entwicklung
Wenn der Build 40 Minuten dauert, liegt es fast immer am Pipeline-Design.
- —Jenkinsfiles, GitLab CI YAML, Azure Pipelines, GitHub Workflows
- —Shared Libraries und Pipeline-Templates
- —Parallelisierung und Build-Zeit-Optimierung
- —Artifact-Management (Nexus, JFrog, Packages)
Plattform-Auswahl auf Basis Ihres Tech-Stacks und Compliance-Bedarfs. Detaillierter Vergleich der Optionen im Jenkins-/GitLab-/Azure-DevOps-Vergleich.
- /03
DevSecOps & Compliance
Security gehört in die Pipeline, nicht ans Ende.
- —SAST/DAST-Scanner direkt im Build
- —Secret-Management (Vault, Azure Key Vault)
- —Zugriffskonzepte, RBAC
- —Auditierbar für ISO 26262, TISAX, IEC 62443
Auditierbarkeit für regulierte Branchen integriert in den Managed-Service-Vertrag, Details im DevSecOps-Leistungspaket. Wenn der Auditor fragt, wer wann freigegeben hat, ist die Antwort ein Pipeline-Report, keine Aktenlage.
- /04
Migration & Modernisierung
Von Jenkins nach GitLab. Oder zurück. Oder beides parallel, bis es entschieden ist.
- —Migration zwischen den vier großen Plattformen
- —Ablösung von Legacy-Build-Skripten durch Pipeline-as-Code
- —Konsolidierung verstreuter CI/CD-Systeme
- /05
Wissenstransfer
Wir betreiben. Aber wir verstecken nichts.
- —Runbook und Dokumentation aller betriebenen Pipelines
- —Optionales DevOps Coaching Ihres Teams
- —Quartals-Review: Status, Maßnahmen, Roadmap
Soll Ihr Team parallel zum Managed-Betrieb wachsen, kombinieren wir ihn mit DevOps Coaching. Wissenstransfer und Betrieb kommen dann vom selben Team.
AIDie meiste Arbeit aus dieser Liste fällt nicht auf. Ein Patch am Dienstagabend, ein getauschtes Kabel, ein Haken auf dem Wartungsplan. Auffallen würde sie erst, wenn sie niemand macht.
Was geben Sie beim
DevOps-Outsourcing ab,
und was bleibt im Haus?
Sie geben die Zuständigkeit für den Betrieb ab, nicht das Wissen und nicht die Kontrolle. Runbooks, Pipeline-Code, Dokumentation und Zugangsdaten bleiben in Ihrem Haus. Die Plattform läuft weiter auf Ihrer Infrastruktur, und Ihr Team liest im Quartals-Review mit.
Im Alltag reicht eine einfache Regel. Bricht ein Build, weil auf einem Agent die Platte voll ist, ein Plugin nach dem Update hakt oder ein Zertifikat abgelaufen ist, ist das unser Ticket. Bricht er, weil ein Unit-Test rot ist, gehört er Ihrem Team, und die Pipeline hat genau das getan, wofür sie da ist.
Was gehört zu DevOps Managed Services, und wo endet unsere Zuständigkeit?
- /01CI/CD-Server und Build-Agents
- /02Plugins, Updates und Security-Patches
- /03Backup und Monitoring
- /04Zugänge und Berechtigungen
- /05Störungen an der Plattform, per SLA
- /06Pipeline-Code wie Jenkinsfiles und Shared Libraries, ab Paket Professional
- /01Anwendungscode und die Tests darin
- /02Ihre Repositories, ohne dauerhaften Zugriff von uns
- /03Die Infrastruktur, on-premise oder in Ihrer eigenen Cloud
- /04Runbooks und Dokumentation
- /05Alle Zugangsdaten
Wo die Grenze bei Ihnen im Einzelnen verläuft, halten wir bei der Übergabe schriftlich fest, damit im Störfall niemand erst klären muss, wer zuständig ist.
- /01
Ihr System bleibt, wie es ist
Wir übernehmen Ihre Instanz so, wie sie läuft. Am Anfang steht eine dokumentierte Bestandsaufnahme. Was ein Risiko ist, besprechen wir, bevor wir etwas anfassen.
- /02
Ihr Code bleibt bei Ihnen
Wir arbeiten auf Ihrer Infrastruktur. Auf Ihre Repositories greifen wir nur im vereinbarten Servicerahmen zu, dokumentiert und protokolliert.
- /03
Sie kommen jederzeit heraus
Monatlich kündbar. Bei einer Kündigung übergeben wir die vollständige Dokumentation und alle Zugangsdaten, auf Wunsch mit begleiteter Rückübergabe an Ihr Team.
Welche Vor- und Nachteile hat DevOps-Outsourcing?
Der Vorteil: Updates, Plugin-Pflege und Störungen haben einen Zuständigen mit festen Reaktionszeiten, ohne dass Sie dafür eine Stelle besetzen und den Bus-Faktor selbst absichern müssen. Die Nachteile sind zwei, und beide sind echt. Ihr Team verliert mit der Zeit die Routine im Plattformbetrieb, und Sie hängen an den Reaktionszeiten eines Dritten. Gegen das erste helfen Runbooks im eigenen Haus und ein Quartals-Review, in dem Ihr Team mitliest. Gegen das zweite hilft nur ein SLA mit Zahlen, die Sie vor der Unterschrift kennen. Wenn die Plattform Ihr Wettbewerbsvorteil ist und Ihr Team sie gern baut, lagern Sie sie nicht aus.
AI
Wie läuft die
Betriebsübernahme
in 4 Wochen ab?
Bestandsaufnahme
Dokumentierte Analyse Ihrer CI/CD-Infrastruktur, Pipelines und Abhängigkeiten. Kein Umbau. Nur Inventur.
Übergabe
Schrittweise Übernahme mit Ihrem Team. Monitoring, Alerting und Zugänge werden eingerichtet.
SLA-Betrieb
Comquent trägt die operative Verantwortung. Ihr Team kann sich auf Entwicklung konzentrieren.
Alle drei Monate: Status, Maßnahmen, Roadmap.
Nach der Übernahme endet die Zusammenarbeit nicht im Ticketsystem. Einmal pro Quartal sitzen wir zusammen und gehen durch, was die Zahlen sagen: Build-Zeiten, Fehlerraten, offene Tool-Updates, anstehende Migrationen. Daraus wird die Roadmap fürs nächste Quartal, als Liste mit Verantwortlichen und Terminen.
Woran merken Sie,
dass es funktioniert?
Am ersten Freitagabend, an dem das Update durchläuft, ohne dass jemand aus Ihrem Team danebensitzt. Plugin-Update, Agent-Neustart und Backup laufen durch, und Sie lesen es montags im Report.
AIIllustrative Szenen aus typischen Betriebsübernahmen: Ausgangslagen, die wir häufig antreffen, und das Ziel der Übernahme. Keine Kundenzitate, keine namentlichen Referenzen.
Jedes Quartal fällt der Jenkins mindestens einmal ungeplant aus, und das Release wird zum Stress-Deployment.
Updates und Neustarts stehen im Wartungskalender, ungeplante Ausfälle sind die Ausnahme.
Die Build-Pipeline steht bei jedem zweiten Release, und die Release-Besprechung dreht sich um Jenkins statt um Features.
Der Betrieb liegt bei Comquent, die Pipeline läuft durch, und im Team geht es wieder um Features.
Die Cross-Compiler-Toolchain liegt auf einem einzigen Build-Agent, den niemand neu starten will.
Der Agent existiert als Image mit Backup, und jedes Update steht vorher im Wartungskalender.
Der erfahrenste Entwickler verbringt jede Woche einen halben Tag mit GitLab-Runnern und abgelaufenen Zertifikaten.
Der Betrieb ist abgegeben, und die Stunden fließen wieder in Kundenprojekte, die sich abrechnen lassen.
Make or Buy:
Inhouse, Beratung
oder Managed?
Die Make-or-Buy-Entscheidung für den CI/CD-Betrieb hat drei Antworten. Die Tabelle zeigt, wo sie sich wirtschaftlich und operativ unterscheiden, bevor wir über Pakete reden.
| Kriterium | Inhouse-Team | Klassische Beratung | Managed CI/CD (AaaS) |
|---|---|---|---|
| Time-to-Pipeline | 3–6 Monate | 4–8 Wochen | 2–4 Wochen |
| Fixkosten / Monat | rund 8.000–11.000 € (1 FTE Senior)¹ | projektbasiert | monatlicher Festpreis je Paket |
| SLA Pipeline-Verfügbarkeit | nein | nein | bis 99,9 % |
| Wissens-Risiko (Bus-Faktor 1) | hoch | mittel | niedrig (Team-basiert) |
| Tool-Updates & Security-Patches | manuell, oft verzögert | nicht inkludiert | inkludiert, geplant |
| Skalierbar bei Lastspitzen | begrenzt | nein | ja |
| Vertragsbindung | unbefristet (Arbeitsvertrag) | projektbezogen | monatlich kündbar |
| Compliance-Doku (IEC 62443, ISO 27001) | selbst erstellen | beratend | mitgeliefert |
¹ Eigene Rechnung: Bruttogehalt 75–95k € laut StepStone Gehaltsreport 2026, zzgl. Arbeitgeberanteil und Tooling.
Was kostet der Betrieb,
der in keinem
Budget steht?
Der Posten taucht in keiner Kostenstelle auf, weil er sich auf Wartezeiten, Fehlersuche und aufgeschobene Updates verteilt. Drei Regler reichen für eine erste Größenordnung: wie viele Entwickler warten, wie lange am Tag und zu welchem Stundensatz.
Mit den Voreinstellungen, also zehn Entwicklern, 30 Minuten Wartezeit am Tag und 80 € Stundensatz, kommen 88.000 € im Jahr heraus. Setzen Sie Ihre eigenen Werte ein. Das Ergebnis ist die Vergleichsgröße für die Pakete im nächsten Abschnitt.
AIBetreiben lassen oder selbst aufbauen?
Managed CI/CD lohnt sich nicht für jedes Team, und wir sagen das auch, wenn die Antwort gegen uns ausfällt. Zwei Klicks ordnen ein, ob der Betrieb bei uns oder der Aufbau im eigenen Haus der günstigere Weg ist.
Wer kümmert sich heute um Ihre CI/CD-Infrastruktur?
Was kostet
Managed CI/CD?
Einen monatlichen Festpreis je Paket, monatlich kündbar und ohne Setup-Gebühr. Die Höhe hängt an drei Dingen: wie viele Plattformen wir betreiben, ob Pipeline-Entwicklung dazugehört und welche Reaktionszeiten Sie brauchen.
Die Vergleichsgröße kennen Sie aus der Tabelle oben. Eine eigene Senior-Stelle liegt bei rund 8.000–11.000 € im Monat und ist im Urlaub trotzdem nicht da. Die Zahl für Ihr Setup nennen wir nach dem Systemcheck, nicht vorher auf Verdacht.
Kein Lock-in · Keine versteckten Kosten · Kein Setup-Fee
Starter
Teams, die starten oder einen Notfallservice brauchen
- +Betrieb 1 Plattform
- +Monitoring & Alerting
- +Updates & Security-Patches
- +8×5-Support
- +Monatliches Review
Professional
3–20 aktive Pipelines, Mittelstand
- +Betrieb 1–2 Plattformen
- +Pipeline-Entwicklung inklusive
- +DevSecOps-Basis
- +8×5-Support + Emergency
- +Quartals-Review mit Roadmap
Enterprise
Komplexe, regulierte Umgebungen
- +Multi-Plattform-Betrieb
- +Full DevSecOps
- +Migration & Modernisierung
- +Coaching & Enablement
- +Dedizierter Ansprechpartner
- +SLA nach Vereinbarung
„Wer Pipelines selbst baut, baut sie alle drei Jahre neu. Wer sie betreiben lässt, kann sich um sein Produkt kümmern.“
Andreas Schönfeld · Geschäftsführer Comquent GmbHAndreas Schönfeld ist Geschäftsführer der Comquent GmbH und Service Owner für den Managed-Betrieb. Er arbeitet seit 2006 mit Jenkins und CI/CD und hat in dieser Zeit mehr gewachsene Build-Server übernommen, als ihm lieb ist. Eine Pipeline ist für ihn ein Produktionsmittel. Steht sie, steht die Auslieferung. Betrieben wird sie trotzdem fast überall nebenbei, von jemandem, der eigentlich Software bauen soll.
Was im Betrieb auffällt, fließt zurück in Projekte und Workshops: welche Plugin-Kombinationen ein Update überstehen, welche Backup-Strategie eine echte Wiederherstellung trägt, an welcher Stelle ein Agent-Pool unter Last kippt.
Dreißig Minuten.
Kein Pitch.
Im Systemcheck schauen wir uns Ihre CI/CD-Situation an und sagen Ihnen, ob Managed CI/CD hilft oder nicht. Kein Angebot auf Verdacht.
Welche CI/CD-Plattform
passt zu welchem Kontext?
Wir empfehlen, was passt. Nicht, was wir verkaufen wollen.
Jenkins
Managed Jenkins
Komplexe, individuell konfigurierbare Pipelines. Legacy, Industrie, Embedded.
Comquent betreibt Jenkins seit 2006.
GitLab CI
Managed GitLab
Wenn GitLab bereits als SCM gesetzt ist. Alles aus einer Hand.
Ideal bei Self-Hosted-GitLab.
Azure DevOps
Azure DevOps Managed Service
Microsoft-geprägte Umgebungen. Enterprise-Compliance im DACH-Raum.
Stark bei TFVC-Migrationen.
GitHub Actions
GitHub Actions Managed
Eng verzahnter Entwickler-Workflow. Cloud-nativ, wartungsarm.
Für moderne Greenfield-Setups.
Was unterscheidet
DevOps as a Service
von Hosting und Beratung?
- /01
- Was ist DevOps as a Service, und was nicht?
DevOps as a Service bedeutet bei Comquent: Wir betreiben Ihre CI/CD-Plattform, also Jenkins, GitLab CI, Azure DevOps oder GitHub Actions, als Managed Service, inklusive Pipelines, Plugins, Build-Agents, Updates und SLA. Es ist kein Applikations- oder Cloud-Hosting.
Der Unterschied ist wichtig: Viele Anbieter meinen mit „DevOps as a Service“ den Betrieb Ihrer Anwendung in der Cloud (Ansible, Kubernetes-Hosting). Wir betreiben die Plattform, auf der Ihre Software gebaut und ausgeliefert wird, on-premise oder in Ihrer eigenen Cloud, ohne Lock-in.
- /02
- Was ist eine CI/CD-Pipeline, und wer betreibt sie?
- Eine CI/CD-Pipeline automatisiert Build, Test und Deployment Ihrer Software, von Continuous Integration bis Continuous Delivery. Den Aufbau übernimmt ein Implementierungsprojekt, den laufenden Betrieb ein Managed Service. Grundlagen im Glossar: CI/CD-Pipeline, den erstmaligen Aufbau zeigt die CI/CD-Implementierung.
- /03
- Jenkins-Alternative gesucht: neu bauen oder betreiben lassen?
- Wer eine Jenkins-Alternative sucht, hat meist ein Betriebsproblem, kein Tool-Problem: veraltete Plugins, niemand zuständig, keine Updates. Oft ist nicht der Plattformwechsel die Lösung, sondern ein professioneller Betrieb. Welche Plattform zu welchem Kontext passt, zeigt der Vergleich Jenkins vs. GitLab vs. Azure DevOps. Falls ein Wechsel sinnvoll ist, übernehmen wir die Migration zwischen allen vier Plattformen.
- /04
- CI/CD-Betrieb auslagern oder intern aufbauen?
Kurz: Intern aufbauen lohnt, wenn Pipeline-Betrieb zu Ihrem Kerngeschäft gehört und Sie mehrere Teams dauerhaft mit einer eigenen Plattform-Roadmap versorgen. Auslagern lohnt, wenn der Betrieb Mittel zum Zweck ist, interne Kapazität knapp und niemand einspringt, wenn die eine Person, die den Jenkins versteht, zwei Wochen im Urlaub ist.
Drei Fragen entscheiden es: Reicht Ihr Pipeline-Volumen für eine eigene, dauerhaft ausgelastete DevOps-Stelle (rund 8.000–11.000 € pro Monat, eigene Rechnung: Bruttogehalt laut StepStone Gehaltsreport 2026, zzgl. Arbeitgeberanteil und Tooling)? Ist der Betrieb geschäftskritisch genug, dass Sie eine SLA brauchen? Und ist der Bus-Faktor abgesichert, läuft Ihre Build-Infrastruktur also auch ohne die eine Person? Wo Sie stehen, zeigt in 3 Minuten der DevOps-Reifegrad-Check, die Kostenseite rechnet der Pipeline-Kostenrechner weiter oben durch.
- /05
- Welche Modelle von DevOps-Outsourcing gibt es?
Vier, und sie unterscheiden sich vor allem darin, wer den Betrieb trägt, während der Vertrag läuft und wenn er endet: Bodyleasing, ein Projekt mit festem Ergebnis, ein Managed Service per SLA und klassisches IT-Outsourcing. Automation as a Service ist das dritte Modell, beschränkt auf die CI/CD-Plattform.
Modell Sie kaufen Den Betrieb trägt Passt, wenn Bodyleasing Arbeitszeit eines externen Engineers in Ihrem Team Ihr Team. Das Wissen geht mit dem Vertrag. eine befristete Lücke im Team zu füllen ist Projekt ein Ergebnis: Aufbau, Migration oder Audit Ihr Team, ab der Übergabe die Plattform neu entsteht oder umzieht Managed Service den laufenden Betrieb mit Reaktionszeiten und Wartungsfenstern der Dienstleister, mit Runbook und Rückübergabe an Sie der Betrieb Mittel zum Zweck ist und intern niemand dafür frei ist IT-Outsourcing Arbeitsplätze, Netz, Server, oft auch Anwendungen der Dienstleister, breit und selten mit CI/CD-Tiefe die gesamte IT abgegeben werden soll Im Managed-Service-Modell übernimmt ein externer DevOps-Partner den Betrieb Ihrer CI/CD-Plattform per SLA, mit Reaktionszeiten und monatlichem Festpreis, um die Pipelines zu professionalisieren und den Betrieb zu entlasten. Bei Automation as a Service geben Sie dabei die Zuständigkeit für Jenkins, GitLab CI oder Azure DevOps auf Ihrer Infrastruktur ab, nicht die Leute und nicht das Wissen: Runbooks, Pipeline-Code und Dokumentation bleiben im Haus, Ihr Team liest im Quartals-Review mit.
Steht die Strecke noch gar nicht, ist ein Projekt der bessere Anfang, die CI/CD-Implementierung; den Betrieb können Sie danach immer noch abgeben.
- /06
- Warum ein spezialisierter Dienstleister statt IT-Systemhaus?
Globale SaaS-Anbieter liefern die Plattform, aber kein Betriebskonzept. Große IT-Systemhäuser bieten Managed Services, aber keine CI/CD-Tiefe. Der Betrieb einer Pipeline-Plattform braucht beides.
- TiefeNur CI/CD. Kein „Alles aus einer Hand“-Versprechen.
- IndustriekontextAutomotive, OT/IT-Konvergenz, regulierte Umgebungen. Wartungsfenster, Freigabewege und Werksnetze ohne Internetzugang kennen wir aus eigenen Projekten.
- VerantwortungNicht „wir beraten Sie dabei“. Ihr System läuft, oder wir beheben es.
- /07
- Was gehört in ein SLA für den CI/CD-Betrieb?
Ein Service Level Agreement für den CI/CD-Betrieb legt fest, wie schnell der Dienstleister auf eine Störung reagiert, wie verfügbar die Plattform sein muss und wann gewartet wird. Fragen Sie jeden Anbieter nach vier Zahlen: Reaktionszeit je Störungsklasse, zugesagte Verfügbarkeit, Wiederherstellungszeit nach einem Ausfall (RTO) und tolerierbarer Datenverlust (RPO).
Dazu gehören ein Wartungskalender mit festen Fenstern und ein Runbook, das beschreibt, wer im Störfall was tut. Fehlt eines davon, haben Sie einen Supportvertrag und keinen Betrieb. Bei Comquent stehen Reaktionszeiten und Verfügbarkeit je Paket im Vertrag, die Wartungsfenster im gemeinsamen Kalender.
AIEin SLA ist so viel wert wie der Plan an der Schranktür. Jede Zeile ein Wartungsfenster, jeder Haken ein Termin, der gehalten wurde.
Was Kunden
wirklich fragen.
- Q.01
- Was ist DevOps as a Service?
- DevOps as a Service ist der ausgelagerte Betrieb von CI/CD-Pipelines unter SLA. Der Anbieter übernimmt Plattformbetrieb (Jenkins, GitLab CI, Azure DevOps, GitHub Actions), Pipeline-Engineering, Security-Updates und Incident-Response. Das interne Team nutzt Pipelines als Service, ohne eigenes Plattform-Know-how vorhalten zu müssen. Synonyme: DevOps-Outsourcing, Managed CI/CD, Automation as a Service, Pipeline as a Service, Managed Jenkins.
- Q.02
- Wir haben sensible Daten in unseren Pipelines. Können wir den Betrieb wirklich auslagern?
- Ja. Der Unterschied zu einer Cloud-Lösung: Wir betreiben Ihren CI/CD-Server auf Ihrer Infrastruktur, on-premise oder in Ihrer eigenen Cloud. Es gibt keinen dauerhaften Zugriff auf Ihre Repositories. Zugriff nur im vereinbarten Servicerahmen, dokumentiert und protokolliert.
- Q.03
- Was ist, wenn unser Build-System mitten in einem Release ausfällt?
- Dann rufen Sie uns an. Die Reaktionszeit steht im SLA, und für kritische Release-Fenster gibt es ein Emergency-Support-Modell, das wir vorab mit Ihnen terminieren. Die Störung hat damit eine Reaktionszeit und einen Zuständigen, statt einer Diskussion darüber, wer sich kümmert.
- Q.04
- Wir haben Jenkins seit Jahren so konfiguriert, wie wir es brauchen. Wird alles umgebaut?
- Nein. Wir übernehmen Ihr System so, wie es ist. Das erste ist eine dokumentierte Bestandsaufnahme. Was läuft, bleibt. Was ein Risiko ist, besprechen wir, bevor wir etwas anfassen.
- Q.05
- Wir haben intern noch DevOps-Know-how. Ist das dann überflüssig?
- Nein. Managed CI/CD ersetzt Ihr Team nicht. Wir übernehmen den Betrieb der Plattform, Ihr Team entwickelt weiter und liest im Quartals-Review mit, was wir daran tun. Wer intern Know-how hat, stellt im Review die besseren Fragen.
- Q.06
- Was kostet DevOps as a Service?
- DevOps as a Service kostet einen monatlichen Festpreis je Paket, monatlich kündbar und ohne Setup-Gebühr. Das gilt auch für Managed Jenkins und Managed GitLab. Die Höhe hängt an der Zahl der Plattformen, am Umfang der Pipeline-Entwicklung und an den Reaktionszeiten. Zum Vergleich: Eine eigene Senior-DevOps-Stelle kostet rund 8.000–11.000 € pro Monat (eigene Rechnung: Bruttogehalt 75–95k € laut StepStone Gehaltsreport 2026, zzgl. Arbeitgeberanteil und Tooling). Der Pipeline-Kostenrechner auf dieser Seite zeigt, wie viel Entwicklerproduktivität langsame oder instabile Pipelines pro Jahr kosten.
- Q.07
- Wir nutzen Azure DevOps oder GitHub Actions, kein Jenkins. Macht das trotzdem Sinn?
- Ja. Alle vier großen Plattformen. Plattform-übergreifend sogar. Wenn Sie Jenkins und GitHub Actions parallel betreiben: Wir kennen beide.
- Q.08
- Wie lange dauert die Übernahme?
- 2–4 Wochen. Woche 1: Bestandsaufnahme. Woche 2–3: Übergabe. Ab Woche 4: Voller Betrieb im SLA.
- Q.09
- Was passiert bei einer Kündigung, und wie vermeiden wir einen Vendor Lock-in?
- Sie bekommen die vollständige Dokumentation und alle Zugangsdaten, auf Wunsch mit begleiteter Rückübergabe an Ihr Team. Einen Vendor Lock-in vermeidet das Modell an drei Stellen: Die Plattform läuft auf Ihrer Infrastruktur, Pipeline-Code und Runbooks bleiben im Haus, und der Vertrag ist monatlich kündbar.
- Q.10
- Was ist der Unterschied zwischen DevOps-Automatisierung und Automation as a Service?
- Der Unterschied liegt im Geschäftsmodell, nicht in der Technik. Bei Automation as a Service tragen wir die operative Verantwortung für Ihre CI/CD-Plattform dauerhaft, per SLA, mit definierten Reaktionszeiten und monatlichem Festpreis; Ihr Team konsumiert die Pipelines, ohne selbst Betrieb leisten zu müssen. Ein einmaliges Automatisierungsprojekt endet dagegen mit der Übergabe: Wartung, Patching und Incident-Response liegen danach wieder bei Ihnen. AaaS passt, wenn Sie den Pipeline-Betrieb dauerhaft abgeben und kein eigenes Ops-Team vorhalten wollen. Ein Automatisierungsprojekt passt, wenn Sie die Plattform aufbauen lassen und anschließend selbst betreiben.
- Q.11
- Was ist der Unterschied zwischen DevOps as a Service und Managed Hosting?
- Managed Hosting betreibt Ihre Server und Anwendungen. DevOps as a Service in Comquents Verständnis betreibt Ihre CI/CD-Plattform, also Jenkins, GitLab CI, Azure DevOps oder GitHub Actions samt Pipelines, Plugins, Build-Agents und Security-Updates. Viele Anbieter meinen mit „DevOps as a Service“ den Cloud-Betrieb der Applikation (z. B. Ansible, Kubernetes-Hosting). Comquent betreibt gezielt die Pipeline-Plattform, auf der Ihre Software gebaut und ausgeliefert wird, on-premise oder in Ihrer eigenen Cloud.
- Q.12
- Wen engagiert man extern für DevOps und Managed Cloud?
- Zwei verschiedene Dienstleister, je nach Aufgabe. Für den Betrieb der CI/CD-Plattform (Jenkins, GitLab CI, Azure DevOps, GitHub Actions) einen spezialisierten DevOps-Dienstleister mit SLA, der auf Ihrer Infrastruktur arbeitet und Ihr Team einbindet. Für Managed Cloud, also den Betrieb von Anwendungen, Kubernetes-Clustern und Cloud-Konten, einen Cloud- oder Hosting-Provider. Prüfen Sie bei jedem Kandidaten dasselbe: Betreibt er ohne dauerhaften Zugriff auf Ihre Repositories? Gibt es Reaktionszeiten per SLA? Bleiben Dokumentation und Zugangsdaten bei einer Kündigung bei Ihnen? Comquent übernimmt den ersten Teil, den CI/CD-Betrieb, und lässt den Applikationsbetrieb bewusst beim Cloud-Anbieter.
- /01Wenn Sie zuerst wissen wollen, was der Eigenbetrieb heute kostetROI-Rechner →
- /02Wenn die Pipelines erst noch entstehen müssenCI/CD Implementierung →
- /03Wenn Ihr Team die Administration selbst übernehmen sollJenkins-Admin-Workshop →
Wie möchten Sie bei Managed CI/CD 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.
Die vier Sätze vom Anfang dieser Seite verschwinden auch im Managed Setup nicht. Plugins veralten, Runner fallen aus, Zertifikate laufen ab. Nur sagt sie dann nicht mehr Ihr Entwicklerteam.
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