[{"data":1,"prerenderedAt":814},["ShallowReactive",2],{"/de-de/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment":3,"navigation-de-de":43,"banner-de-de":455,"footer-de-de":465,"blog-post-authors-de-de-Itzik Gan Baruch":697,"blog-related-posts-de-de-jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment":711,"blog-promotions-de-de":751,"next-steps-de-de":804},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":28,"externalUrl":29,"featured":14,"heroImage":19,"isFeatured":14,"meta":30,"navigation":31,"path":32,"publishedDate":20,"rawbody":33,"seo":34,"slug":13,"stem":37,"tagSlugs":38,"tags":41,"template":15,"updatedDate":29,"__hash__":42},"blogPosts/de-de/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment.yml","Von Jenkins zu GitLab: Der vollständige Migrationsleitfaden",[7],"itzik-gan-baruch",[9],"Itzik Gan Baruch","Jenkins hat sich über mehr als ein Jahrzehnt als Standard-CI-Werkzeug in deutschen Unternehmen etabliert. Viele Organisationen betreiben heute dezentral gewachsene Installationen: mehrere Jenkins-Instanzen mit teambezogenen Konfigurationen, umfangreichen Plugin-Ökosystemen und eigenen Update- und Sicherheitspflegezyklen. Diese Infrastruktur ist produktiv – und entsprechend schwer zu verändern.\n\nGleichzeitig verschieben sich die Anforderungen: Cloud-Kompatibilität, Container-Orchestrierung, integrierte Sicherheitsscans und KI-gestützte Entwicklungswerkzeuge werden zur Grundvoraussetzung moderner CI/CD-Umgebungen. Jenkins liefert diese Fähigkeiten nicht nativ – sie entstehen durch das Zusammensetzen, Warten und Absichern von Plugins. Dabei ist der Aufwand nicht gering: Sicherheitsrelevante Plugin-Aktualisierungen fallen regelmäßig an und binden Entwicklungskapazität, die anderweitig produktiver eingesetzt werden könnte.\n\nDieser Leitfaden beschreibt drei bewährte Migrationsstrategien und einen empfohlenen Schritt-für-Schritt-Prozess – ergänzt durch ein deutsches Praxisbeispiel – für Organisationen, die eine Migration von Jenkins zu GitLab CI evaluieren oder planen.\n\n\n## Warum zu GitLab CI migrieren?\n\nGitLab CI ist integraler Bestandteil der GitLab DevSecOps-Plattform. Die zentralen Unterschiede gegenüber Jenkins:\n\n- **Integrierte Plattform:** Quellcodeverwaltung, Projektmanagement, Sicherheitsscans und Analytics sind ohne zusätzliche Plugins verfügbar – als ein zusammenhängendes System.\n- **Container und Orchestrierung:** Native Unterstützung für Docker und Kubernetes, ohne Plugin-Abhängigkeiten.\n- **Sicherheit im Entwicklungsprozess:** Statische Codeanalyse und Schwachstellen-Scanning sind direkt in die Pipeline integriert – nicht nachgelagert konfiguriert.\n- **GitOps-Prinzipien:** Versionskontrollierte, deklarative Konfigurationen für Infrastruktur und Deployments erhöhen die Reproduzierbarkeit und Nachvollziehbarkeit.\n\nEine Einführung in GitLab CI ist im englischen Originalbeitrag als Video-Tutorial verfügbar.\n\n\n## Die drei Migrationsstrategien\n\nJe nach Ausgangssituation, verfügbaren Ressourcen und Risikobereitschaft bieten sich drei Strategien an.\n\n### Strategie 1: GitLab CI für neue Projekte\n\nBestehende Jenkins-Installationen bleiben unverändert in Betrieb. Neue Projekte starten von Beginn an auf GitLab CI. Teams bauen schrittweise Erfahrung auf, ohne laufende Workflows zu beeinträchtigen.\n\n**Vorteile:** Minimales Migrationsrisiko. Kein Druck zur sofortigen Umstellung. Expertise entsteht organisch.\n\n**Herausforderungen:** Zwei CI/CD-Plattformen parallel zu betreiben erhöht die Koordinationskomplexität – insbesondere bei Integration und plattformübergreifender Zusammenarbeit. Prozess- und Sicherheitskonsistenz erfordert zusätzliche Abstimmung.\n\n### Strategie 2: Strategische Projekte migrieren\n\nProjekte, die am meisten von GitLab CIs Fähigkeiten profitieren, werden zuerst identifiziert und migriert. Statt einer vollständigen Umstellung konzentrieren sich die Ressourcen gezielt auf diese Projekte.\n\n**Vorteile:** Konkrete Verbesserungen in strategisch relevanten Bereichen bei überschaubarem Aufwand. Erfahrungen mit GitLab CI können gesammelt werden, bevor weitere Migrationen folgen.\n\n**Herausforderungen:** Auch die Migration einzelner Projekte erfordert sorgfältige Planung. Die Zusammenarbeit zwischen Projekten auf unterschiedlichen Plattformen bedarf zusätzlicher Koordination.\n\n### Strategie 3: Vollständige Migration\n\nAlle CI/CD-Prozesse, Projekte und Workflows werden auf GitLab CI migriert. Dieser Ansatz strebt Einheitlichkeit und vereinfachte Administration über alle Projekte hinweg an. Empfohlen wird dabei ein iteratives Vorgehen: zunächst neue Projekte, dann strategische Projekte, schließlich die verbleibenden – mit wachsender Erfahrung und Sicherheit in jedem Schritt.\n\n**Vorteile:** Einheitliche CI/CD-Prozesse vereinfachen langfristig Wartung und Administration. Alle Fähigkeiten der GitLab-Plattform – von Infrastructure as Code bis zu integrierten Sicherheitsfunktionen – stehen vollständig zur Verfügung. Skalierbarkeit für wachsende Projektportfolios.\n\n**Herausforderungen:** Eine vollständige Migration erfordert detaillierte Planung und kann laufende Projekte vorübergehend beeinflussen. Budget für Schulungen und Migrationsaufwand ist realistisch einzuplanen.\n\nDie Wahl der Strategie sollte auf den spezifischen Anforderungen, der Ausgangssituation und den verfügbaren Ressourcen der Organisation basieren.\n\n\n## Praxisbeispiel: Deutsche Bahn\n\nDie Deutsche Bahn betreibt eines der größten Hochgeschwindigkeitsbahnnetzwerke Europas und entwickelt mit GitLab die DB-Navigator-App – die wichtigste digitale Schnittstelle für täglich Millionen von Reisenden in Deutschland.\n\nVor der Konsolidierung auf GitLab betrieb die Deutsche Bahn mehrere verteilte Jenkins-Instanzen mit jeweils eigenen Konfigurationen und Plugin-Setups. Das Unternehmen ist dabei, Jenkins vollständig durch GitLab zu ersetzen. „All diese Jenkins-Plugins mussten oft aufgrund von Sicherheitsproblemen aktualisiert werden, und wir mussten jeden Monat Plugin-Upgrades durchführen. Es war sehr zeitaufwendig\", sagt Heiko Maaß, System Engineer bei der Deutschen Bahn. „Diese Aufgaben sind jetzt weg, sodass wir diese Zeit nutzen können, um neue Features zu erstellen, anstatt Jenkins zu warten.\" Der Wartungsaufwand war beträchtlich: Sicherheitsrelevante Plugin-Aktualisierungen fielen monatlich an und banden Kapazität, die in die Entwicklung neuer Funktionen hätte fließen können. Mit der Migration zu GitLab CI entfiel dieser Aufwand. Gleichzeitig vereinfachte GitLabs integrierte Plattform die bis dahin weitgehend manuelle Compliance-Koordination durch automatisierte Prüfprozesse erheblich.\n\nErgebnis: **80 % weniger Zeitaufwand für Pipeline-Wartung**, 10–20 % Infrastrukturkosteneinsparungen, 1 Million Pipeline-Builds pro Monat auf einer konsolidierten Plattform.\n\nDen vollständigen Kundenbericht gibt es hier: [Deutsche Bahn AG – GitLab Kundenstory](https://about.gitlab.com/de-de/customers/deutsche-bahn-ag/)\n\n[GitLab CI kostenlos testen](https://gitlab.com/-/trials/new)\n\n\n---\n\n\n## Technische Umsetzung: Migrationsschritte und Konfiguration\n\n*Dieser Abschnitt richtet sich an Implementierungsteams. Vollständige Video-Tutorials und alle Konfigurationsdetails sind im [englischen Originalbeitrag](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/) verfügbar.*\n\n\n### Empfohlener 6-Schritte-Migrationsprozess\n\nFür eine strukturierte Migration empfiehlt sich folgendes Vorgehen:\n\n1. **Pipeline-Bestandsaufnahme:** Alle bestehenden Jenkins-Pipelines inventarisieren. Umfang und Komplexität der Migration werden damit transparent.\n2. **Parallele Migration:** Einzelne Pipelines schrittweise auf GitLab CI übertragen, während Jenkins für laufende Arbeiten weiter genutzt wird.\n3. **Code-Verifikation:** Beide Pipelines parallel betreiben und die Ergebnisse direkt vergleichen. In dieser Phase ist der GitLab-Workflow optional, Jenkins bleibt verbindlich.\n4. **Kontinuierliche Validierung:** Nach einer vollständigen Iteration die Ergebnisse beider Pipelines auswerten – Statuscodes, Logs, Performance.\n5. **Umstellung auf GitLab CI:** Sobald Vertrauen in GitLab CI aufgebaut ist, wird der GitLab-Workflow zum verbindlichen Standard. Jenkins läuft im Hintergrund weiter.\n6. **Jenkins-Abschaltung:** Nach einer zweiten Iteration, bei nachgewiesener Stabilität von GitLab CI, wird Jenkins schrittweise aus dem Pipeline-Prozess entfernt.\n\nDieser Ansatz stellt sicher, dass Probleme identifiziert und behoben werden, bevor die vollständige Umstellung erfolgt.\n\n\n### Vorbereitung: Schulung und Kommunikation\n\nEine erfolgreiche Migration erfordert Vorbereitung auf organisatorischer Ebene:\n\n- **Stakeholder-Kommunikation:** Migrationspläne und Zeitplan frühzeitig an alle Beteiligten kommunizieren – DevOps-Teams, Entwicklungsteams und QA. Transparenz über Ziele und Erwartungen ist entscheidend.\n- **Schulungen:** Wissensaufbau zu GitLab CI, YAML-Syntax und grundlegender Pipeline-Erstellung. Teams benötigen die Grundlagen, bevor sie eigenständig arbeiten können.\n- **Praxisorientiertes Lernen:** Entwicklungsteams paarweise arbeiten lassen. Gegenseitiges Lernen während der Migration beschleunigt den Kompetenzaufbau.\n\n\n### Konfigurationsvergleich: Jenkinsfile vs. .gitlab-ci.yml\n\nBeide Dateien definieren Stages, Jobs und Schritte des CI/CD-Prozesses. Build-, Test- und Deployment-Schritte sowie Umgebungsvariablen lassen sich in beiden konfigurieren.\n\nDie wesentlichen Unterschiede: Jenkinsfile verwendet Groovy für Scripting, .gitlab-ci.yml verwendet YAML – eine menschenlesbarere und strukturiertere Syntax. GitLab CI stellt zudem eine breite Palette von integrierten Templates und vordefinierten Jobs bereit, was den Konfigurationsaufwand gegenüber eigenem Groovy-Scripting deutlich reduziert.\n\nDie Migration bestehender Jenkinsfile-Konfigurationen erfordert eine sorgfältige Analyse der vorhandenen Pipelines und eine Übertragung der Logik in die YAML-Syntax von GitLab CI. Unterschiede in Syntax und Plattformfähigkeiten sind dabei zu berücksichtigen.\n\n\n### Dokumentation und Professional Services\n\nGitLab bietet Dokumentation zur Jenkins-Migration: [Migrationsleitfaden in der GitLab-Dokumentation](https://docs.gitlab.com/ci/migration/jenkins/).\n\nDarüber hinaus unterstützt das Professional-Services-Team von GitLab Organisationen bei der Migration – von der Konvertierung von Jenkinsfile zu .gitlab-ci.yml bis zur Optimierung bestehender CI/CD-Workflows.\n\nDen vollständigen Leitfaden mit Video-Tutorials, weiteren Konfigurationsbeispielen und dem Lockheed-Martin-Fallbeispiel gibt es im englischen Originalbeitrag:\n\n[Jenkins to GitLab: The ultimate guide to modernizing your CI/CD environment](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n","devsecops",{"slug":13,"featured":14,"template":15},"jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment",false,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21},"Schwachstellen in Jenkins-Umgebungen systematisch adressieren – mit GitLab CI als integrierter DevSecOps-Plattform.",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","2026-03-15",[22,23,24,25,26,27],"tutorial","events","AI/ML","integrations","DevSecOps","DevOps","yml",null,{},true,"/de-de/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment","seo:\n  title: 'Jenkins zu GitLab migrieren: Der vollständige Leitfaden'\n  description: 'Wie Sie von Jenkins zu GitLab CI migrieren – drei Strategien und ein bewährter 6-Schritte-Prozess.'\ncontent:\n  title: 'Von Jenkins zu GitLab: Der vollständige Migrationsleitfaden'\n  description: 'Schwachstellen in Jenkins-Umgebungen systematisch adressieren – mit GitLab CI als integrierter DevSecOps-Plattform.'\n  authors:\n    - Itzik Gan Baruch\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png\n  date: '2026-03-15'\n  body: |\n    Jenkins hat sich über mehr als ein Jahrzehnt als Standard-CI-Werkzeug in deutschen Unternehmen etabliert. Viele Organisationen betreiben heute dezentral gewachsene Installationen: mehrere Jenkins-Instanzen mit teambezogenen Konfigurationen, umfangreichen Plugin-Ökosystemen und eigenen Update- und Sicherheitspflegezyklen. Diese Infrastruktur ist produktiv – und entsprechend schwer zu verändern.\n\n    Gleichzeitig verschieben sich die Anforderungen: Cloud-Kompatibilität, Container-Orchestrierung, integrierte Sicherheitsscans und KI-gestützte Entwicklungswerkzeuge werden zur Grundvoraussetzung moderner CI/CD-Umgebungen. Jenkins liefert diese Fähigkeiten nicht nativ – sie entstehen durch das Zusammensetzen, Warten und Absichern von Plugins. Dabei ist der Aufwand nicht gering: Sicherheitsrelevante Plugin-Aktualisierungen fallen regelmäßig an und binden Entwicklungskapazität, die anderweitig produktiver eingesetzt werden könnte.\n\n    Dieser Leitfaden beschreibt drei bewährte Migrationsstrategien und einen empfohlenen Schritt-für-Schritt-Prozess – ergänzt durch ein deutsches Praxisbeispiel – für Organisationen, die eine Migration von Jenkins zu GitLab CI evaluieren oder planen.\n\n\n    ## Warum zu GitLab CI migrieren?\n\n    GitLab CI ist integraler Bestandteil der GitLab DevSecOps-Plattform. Die zentralen Unterschiede gegenüber Jenkins:\n\n    - **Integrierte Plattform:** Quellcodeverwaltung, Projektmanagement, Sicherheitsscans und Analytics sind ohne zusätzliche Plugins verfügbar – als ein zusammenhängendes System.\n    - **Container und Orchestrierung:** Native Unterstützung für Docker und Kubernetes, ohne Plugin-Abhängigkeiten.\n    - **Sicherheit im Entwicklungsprozess:** Statische Codeanalyse und Schwachstellen-Scanning sind direkt in die Pipeline integriert – nicht nachgelagert konfiguriert.\n    - **GitOps-Prinzipien:** Versionskontrollierte, deklarative Konfigurationen für Infrastruktur und Deployments erhöhen die Reproduzierbarkeit und Nachvollziehbarkeit.\n\n    Eine Einführung in GitLab CI ist im englischen Originalbeitrag als Video-Tutorial verfügbar.\n\n\n    ## Die drei Migrationsstrategien\n\n    Je nach Ausgangssituation, verfügbaren Ressourcen und Risikobereitschaft bieten sich drei Strategien an.\n\n    ### Strategie 1: GitLab CI für neue Projekte\n\n    Bestehende Jenkins-Installationen bleiben unverändert in Betrieb. Neue Projekte starten von Beginn an auf GitLab CI. Teams bauen schrittweise Erfahrung auf, ohne laufende Workflows zu beeinträchtigen.\n\n    **Vorteile:** Minimales Migrationsrisiko. Kein Druck zur sofortigen Umstellung. Expertise entsteht organisch.\n\n    **Herausforderungen:** Zwei CI/CD-Plattformen parallel zu betreiben erhöht die Koordinationskomplexität – insbesondere bei Integration und plattformübergreifender Zusammenarbeit. Prozess- und Sicherheitskonsistenz erfordert zusätzliche Abstimmung.\n\n    ### Strategie 2: Strategische Projekte migrieren\n\n    Projekte, die am meisten von GitLab CIs Fähigkeiten profitieren, werden zuerst identifiziert und migriert. Statt einer vollständigen Umstellung konzentrieren sich die Ressourcen gezielt auf diese Projekte.\n\n    **Vorteile:** Konkrete Verbesserungen in strategisch relevanten Bereichen bei überschaubarem Aufwand. Erfahrungen mit GitLab CI können gesammelt werden, bevor weitere Migrationen folgen.\n\n    **Herausforderungen:** Auch die Migration einzelner Projekte erfordert sorgfältige Planung. Die Zusammenarbeit zwischen Projekten auf unterschiedlichen Plattformen bedarf zusätzlicher Koordination.\n\n    ### Strategie 3: Vollständige Migration\n\n    Alle CI/CD-Prozesse, Projekte und Workflows werden auf GitLab CI migriert. Dieser Ansatz strebt Einheitlichkeit und vereinfachte Administration über alle Projekte hinweg an. Empfohlen wird dabei ein iteratives Vorgehen: zunächst neue Projekte, dann strategische Projekte, schließlich die verbleibenden – mit wachsender Erfahrung und Sicherheit in jedem Schritt.\n\n    **Vorteile:** Einheitliche CI/CD-Prozesse vereinfachen langfristig Wartung und Administration. Alle Fähigkeiten der GitLab-Plattform – von Infrastructure as Code bis zu integrierten Sicherheitsfunktionen – stehen vollständig zur Verfügung. Skalierbarkeit für wachsende Projektportfolios.\n\n    **Herausforderungen:** Eine vollständige Migration erfordert detaillierte Planung und kann laufende Projekte vorübergehend beeinflussen. Budget für Schulungen und Migrationsaufwand ist realistisch einzuplanen.\n\n    Die Wahl der Strategie sollte auf den spezifischen Anforderungen, der Ausgangssituation und den verfügbaren Ressourcen der Organisation basieren.\n\n\n    ## Praxisbeispiel: Deutsche Bahn\n\n    Die Deutsche Bahn betreibt eines der größten Hochgeschwindigkeitsbahnnetzwerke Europas und entwickelt mit GitLab die DB-Navigator-App – die wichtigste digitale Schnittstelle für täglich Millionen von Reisenden in Deutschland.\n\n    Vor der Konsolidierung auf GitLab betrieb die Deutsche Bahn mehrere verteilte Jenkins-Instanzen mit jeweils eigenen Konfigurationen und Plugin-Setups. Das Unternehmen ist dabei, Jenkins vollständig durch GitLab zu ersetzen. „All diese Jenkins-Plugins mussten oft aufgrund von Sicherheitsproblemen aktualisiert werden, und wir mussten jeden Monat Plugin-Upgrades durchführen. Es war sehr zeitaufwendig\", sagt Heiko Maaß, System Engineer bei der Deutschen Bahn. „Diese Aufgaben sind jetzt weg, sodass wir diese Zeit nutzen können, um neue Features zu erstellen, anstatt Jenkins zu warten.\" Der Wartungsaufwand war beträchtlich: Sicherheitsrelevante Plugin-Aktualisierungen fielen monatlich an und banden Kapazität, die in die Entwicklung neuer Funktionen hätte fließen können. Mit der Migration zu GitLab CI entfiel dieser Aufwand. Gleichzeitig vereinfachte GitLabs integrierte Plattform die bis dahin weitgehend manuelle Compliance-Koordination durch automatisierte Prüfprozesse erheblich.\n\n    Ergebnis: **80 % weniger Zeitaufwand für Pipeline-Wartung**, 10–20 % Infrastrukturkosteneinsparungen, 1 Million Pipeline-Builds pro Monat auf einer konsolidierten Plattform.\n\n    Den vollständigen Kundenbericht gibt es hier: [Deutsche Bahn AG – GitLab Kundenstory](https://about.gitlab.com/de-de/customers/deutsche-bahn-ag/)\n\n    [GitLab CI kostenlos testen](https://gitlab.com/-/trials/new)\n\n\n    ---\n\n\n    ## Technische Umsetzung: Migrationsschritte und Konfiguration\n\n    *Dieser Abschnitt richtet sich an Implementierungsteams. Vollständige Video-Tutorials und alle Konfigurationsdetails sind im [englischen Originalbeitrag](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/) verfügbar.*\n\n\n    ### Empfohlener 6-Schritte-Migrationsprozess\n\n    Für eine strukturierte Migration empfiehlt sich folgendes Vorgehen:\n\n    1. **Pipeline-Bestandsaufnahme:** Alle bestehenden Jenkins-Pipelines inventarisieren. Umfang und Komplexität der Migration werden damit transparent.\n    2. **Parallele Migration:** Einzelne Pipelines schrittweise auf GitLab CI übertragen, während Jenkins für laufende Arbeiten weiter genutzt wird.\n    3. **Code-Verifikation:** Beide Pipelines parallel betreiben und die Ergebnisse direkt vergleichen. In dieser Phase ist der GitLab-Workflow optional, Jenkins bleibt verbindlich.\n    4. **Kontinuierliche Validierung:** Nach einer vollständigen Iteration die Ergebnisse beider Pipelines auswerten – Statuscodes, Logs, Performance.\n    5. **Umstellung auf GitLab CI:** Sobald Vertrauen in GitLab CI aufgebaut ist, wird der GitLab-Workflow zum verbindlichen Standard. Jenkins läuft im Hintergrund weiter.\n    6. **Jenkins-Abschaltung:** Nach einer zweiten Iteration, bei nachgewiesener Stabilität von GitLab CI, wird Jenkins schrittweise aus dem Pipeline-Prozess entfernt.\n\n    Dieser Ansatz stellt sicher, dass Probleme identifiziert und behoben werden, bevor die vollständige Umstellung erfolgt.\n\n\n    ### Vorbereitung: Schulung und Kommunikation\n\n    Eine erfolgreiche Migration erfordert Vorbereitung auf organisatorischer Ebene:\n\n    - **Stakeholder-Kommunikation:** Migrationspläne und Zeitplan frühzeitig an alle Beteiligten kommunizieren – DevOps-Teams, Entwicklungsteams und QA. Transparenz über Ziele und Erwartungen ist entscheidend.\n    - **Schulungen:** Wissensaufbau zu GitLab CI, YAML-Syntax und grundlegender Pipeline-Erstellung. Teams benötigen die Grundlagen, bevor sie eigenständig arbeiten können.\n    - **Praxisorientiertes Lernen:** Entwicklungsteams paarweise arbeiten lassen. Gegenseitiges Lernen während der Migration beschleunigt den Kompetenzaufbau.\n\n\n    ### Konfigurationsvergleich: Jenkinsfile vs. .gitlab-ci.yml\n\n    Beide Dateien definieren Stages, Jobs und Schritte des CI/CD-Prozesses. Build-, Test- und Deployment-Schritte sowie Umgebungsvariablen lassen sich in beiden konfigurieren.\n\n    Die wesentlichen Unterschiede: Jenkinsfile verwendet Groovy für Scripting, .gitlab-ci.yml verwendet YAML – eine menschenlesbarere und strukturiertere Syntax. GitLab CI stellt zudem eine breite Palette von integrierten Templates und vordefinierten Jobs bereit, was den Konfigurationsaufwand gegenüber eigenem Groovy-Scripting deutlich reduziert.\n\n    Die Migration bestehender Jenkinsfile-Konfigurationen erfordert eine sorgfältige Analyse der vorhandenen Pipelines und eine Übertragung der Logik in die YAML-Syntax von GitLab CI. Unterschiede in Syntax und Plattformfähigkeiten sind dabei zu berücksichtigen.\n\n\n    ### Dokumentation und Professional Services\n\n    GitLab bietet Dokumentation zur Jenkins-Migration: [Migrationsleitfaden in der GitLab-Dokumentation](https://docs.gitlab.com/ci/migration/jenkins/).\n\n    Darüber hinaus unterstützt das Professional-Services-Team von GitLab Organisationen bei der Migration – von der Konvertierung von Jenkinsfile zu .gitlab-ci.yml bis zur Optimierung bestehender CI/CD-Workflows.\n\n    Den vollständigen Leitfaden mit Video-Tutorials, weiteren Konfigurationsbeispielen und dem Lockheed-Martin-Fallbeispiel gibt es im englischen Originalbeitrag:\n\n    [Jenkins to GitLab: The ultimate guide to modernizing your CI/CD environment](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n  category: devsecops\n  tags:\n    - tutorial\n    - events\n    - AI/ML\n    - integrations\n    - DevSecOps\n    - DevOps\nconfig:\n  slug: jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment\n  featured: false\n  template: BlogPost\n",{"title":35,"description":36},"Jenkins zu GitLab migrieren: Der vollständige Leitfaden","Wie Sie von Jenkins zu GitLab CI migrieren – drei Strategien und ein bewährter 6-Schritte-Prozess.","de-de/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment",[22,23,39,25,11,40],"aiml","devops",[22,23,24,25,26,27],"I40PJsTKUQV76mJW99hMTzZ7uk5zjeSVtpifELBtYRs",{"data":44},{"logo":45,"freeTrial":50,"sales":55,"login":60,"items":65,"search":373,"minimal":407,"duo":425,"switchNav":434,"pricingDeployment":445},{"config":46},{"href":47,"dataGaName":48,"dataGaLocation":49},"/de-de/","gitlab logo","header",{"text":51,"config":52},"Kostenlose Testversion anfordern",{"href":53,"dataGaName":54,"dataGaLocation":49},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":56,"config":57},"Vertrieb kontaktieren",{"href":58,"dataGaName":59,"dataGaLocation":49},"/de-de/sales/","sales",{"text":61,"config":62},"Anmelden",{"href":63,"dataGaName":64,"dataGaLocation":49},"https://gitlab.com/users/sign_in/","sign in",[66,93,190,195,294,354],{"text":67,"config":68,"cards":70},"Plattform",{"dataNavLevelOne":69},"platform",[71,77,85],{"title":67,"description":72,"link":73},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":74,"config":75},"Die Plattform erkunden",{"href":76,"dataGaName":69,"dataGaLocation":49},"/de-de/platform/",{"title":78,"description":79,"link":80},"GitLab Duo Agent Platform","Agentische KI für den gesamten Software-Lebenszyklus",{"text":81,"config":82},"Lerne GitLab Duo kennen",{"href":83,"dataGaName":84,"dataGaLocation":49},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":86,"description":87,"link":88},"Warum GitLab?","Erfahre, warum sich Unternehmen für GitLab entscheiden",{"text":89,"config":90},"Mehr erfahren",{"href":91,"dataGaName":92,"dataGaLocation":49},"/de-de/why-gitlab/","why gitlab",{"text":94,"left":31,"config":95,"link":97,"lists":101,"footer":172},"Produkt",{"dataNavLevelOne":96},"solutions",{"text":98,"config":99},"Alle Lösungen anzeigen",{"href":100,"dataGaName":96,"dataGaLocation":49},"/de-de/solutions/",[102,127,150],{"title":103,"description":104,"link":105,"items":110},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":106},{"icon":107,"href":108,"dataGaName":109,"dataGaLocation":49},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[111,115,118,123],{"text":112,"config":113},"CI/CD",{"href":114,"dataGaLocation":49,"dataGaName":112},"/de-de/solutions/continuous-integration/",{"text":78,"config":116},{"href":83,"dataGaLocation":49,"dataGaName":117},"gitlab duo agent platform - product menu",{"text":119,"config":120},"Quellcodeverwaltung",{"href":121,"dataGaLocation":49,"dataGaName":122},"/de-de/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Automatische Softwarebereitstellung",{"href":108,"dataGaLocation":49,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Sicherheit","Entwickle Code schneller ohne Abstriche bei der Sicherheit",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":49,"icon":134},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"Anwendungssicherheitstests",{"href":132,"dataGaName":139,"dataGaLocation":49},"Application security testing",{"text":141,"config":142},"Schutz der Software-Lieferkette",{"href":143,"dataGaLocation":49,"dataGaName":144},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software-Compliance",{"href":148,"dataGaName":149,"dataGaLocation":49},"/de-de/solutions/software-compliance/","software compliance",{"title":151,"link":152,"items":157},"Auswertung",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":49},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[158,162,167],{"text":159,"config":160},"Sichtbarkeit und Auswertung",{"href":155,"dataGaLocation":49,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"Wertstrommanagement",{"href":165,"dataGaLocation":49,"dataGaName":166},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":168,"config":169},"Analysen und Einblicke",{"href":170,"dataGaLocation":49,"dataGaName":171},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":173,"items":174},"GitLab für",[175,180,185],{"text":176,"config":177},"Enterprise",{"href":178,"dataGaLocation":49,"dataGaName":179},"/de-de/enterprise/","enterprise",{"text":181,"config":182},"Kleinunternehmen",{"href":183,"dataGaLocation":49,"dataGaName":184},"/de-de/small-business/","small business",{"text":186,"config":187},"Öffentlicher Sektor",{"href":188,"dataGaLocation":49,"dataGaName":189},"/de-de/solutions/public-sector/","public sector",{"text":191,"config":192},"Preise",{"href":193,"dataGaName":194,"dataGaLocation":49,"dataNavLevelOne":194},"/de-de/pricing/","pricing",{"text":196,"config":197,"link":199,"lists":203,"feature":281},"Ressourcen",{"dataNavLevelOne":198},"resources",{"text":200,"config":201},"Alle Ressourcen anzeigen",{"href":202,"dataGaName":198,"dataGaLocation":49},"/de-de/resources/",[204,236,254],{"title":205,"items":206},"Erste Schritte",[207,212,217,222,227,232],{"text":208,"config":209},"Installieren",{"href":210,"dataGaName":211,"dataGaLocation":49},"/de-de/install/","install",{"text":213,"config":214},"Kurzanleitungen",{"href":215,"dataGaName":216,"dataGaLocation":49},"/de-de/get-started/","quick setup checklists",{"text":218,"config":219},"Lernen",{"href":220,"dataGaLocation":49,"dataGaName":221},"https://university.gitlab.com/","learn",{"text":223,"config":224},"Produktdokumentation",{"href":225,"dataGaName":226,"dataGaLocation":49},"https://docs.gitlab.com/","product documentation",{"text":228,"config":229},"Best-Practice-Videos",{"href":230,"dataGaName":231,"dataGaLocation":49},"/de-de/getting-started-videos/","best practice videos",{"text":233,"config":234},"Integrationen",{"href":235,"dataGaName":25,"dataGaLocation":49},"/de-de/integrations/",{"title":237,"items":238},"Entdecken",[239,244,249],{"text":240,"config":241},"Kundenerfolge",{"href":242,"dataGaName":243,"dataGaLocation":49},"/de-de/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":248,"dataGaLocation":49},"/de-de/blog/","blog",{"text":250,"config":251},"Remote",{"href":252,"dataGaName":253,"dataGaLocation":49},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":255,"items":256},"Vernetzen",[257,262,267,272,276],{"text":258,"config":259},"GitLab Services",{"href":260,"dataGaName":261,"dataGaLocation":49},"/de-de/services/","services",{"text":263,"config":264},"Community",{"href":265,"dataGaName":266,"dataGaLocation":49},"/community/","community",{"text":268,"config":269},"Forum",{"href":270,"dataGaName":271,"dataGaLocation":49},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"Veranstaltungen",{"href":275,"dataGaName":23,"dataGaLocation":49},"/events/",{"text":277,"config":278},"Partner",{"href":279,"dataGaName":280,"dataGaLocation":49},"/de-de/partners/","partners",{"background":282,"textColor":283,"text":284,"image":285,"link":289},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":286,"config":287},"The Source Promo-Karte",{"src":288},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":290,"config":291},"Aktuelles",{"href":292,"dataGaName":293,"dataGaLocation":49},"/de-de/the-source/","the source",{"text":295,"config":296,"lists":298},"Unternehmen",{"dataNavLevelOne":297},"company",[299],{"items":300},[301,306,312,314,319,324,329,334,339,344,349],{"text":302,"config":303},"Über",{"href":304,"dataGaName":305,"dataGaLocation":49},"/de-de/company/","about",{"text":307,"config":308,"footerGa":311},"Karriere",{"href":309,"dataGaName":310,"dataGaLocation":49},"/jobs/","jobs",{"dataGaName":310},{"text":273,"config":313},{"href":275,"dataGaName":23,"dataGaLocation":49},{"text":315,"config":316},"Geschäftsführung",{"href":317,"dataGaName":318,"dataGaLocation":49},"/company/team/e-group/","leadership",{"text":320,"config":321},"Team",{"href":322,"dataGaName":323,"dataGaLocation":49},"/company/team/","team",{"text":325,"config":326},"Handbuch",{"href":327,"dataGaName":328,"dataGaLocation":49},"https://handbook.gitlab.com/","handbook",{"text":330,"config":331},"Investor Relations",{"href":332,"dataGaName":333,"dataGaLocation":49},"https://ir.gitlab.com/","investor relations",{"text":335,"config":336},"Trust Center",{"href":337,"dataGaName":338,"dataGaLocation":49},"/de-de/security/","trust center",{"text":340,"config":341},"AI Transparency Center",{"href":342,"dataGaName":343,"dataGaLocation":49},"/de-de/ai-transparency-center/","ai transparency center",{"text":345,"config":346},"Newsletter",{"href":347,"dataGaName":348,"dataGaLocation":49},"/company/contact/#contact-forms","newsletter",{"text":350,"config":351},"Presse",{"href":352,"dataGaName":353,"dataGaLocation":49},"/press/","press",{"text":355,"config":356,"lists":357},"Kontakt",{"dataNavLevelOne":297},[358],{"items":359},[360,363,368],{"text":56,"config":361},{"href":58,"dataGaName":362,"dataGaLocation":49},"talk to sales",{"text":364,"config":365},"Support-Portal",{"href":366,"dataGaName":367,"dataGaLocation":49},"https://support.gitlab.com","support portal",{"text":369,"config":370},"Kundenportal",{"href":371,"dataGaName":372,"dataGaLocation":49},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":374,"login":375,"suggestions":382},"Schließen",{"text":376,"link":377},"Um Repositorys und Projekte zu durchsuchen, melde dich an bei",{"text":378,"config":379},"gitlab.com",{"href":63,"dataGaName":380,"dataGaLocation":381},"search login","search",{"text":383,"default":384},"Vorschläge",[385,387,392,394,399,404],{"text":78,"config":386},{"href":83,"dataGaName":78,"dataGaLocation":381},{"text":388,"config":389},"Codevorschläge (KI)",{"href":390,"dataGaName":391,"dataGaLocation":381},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":112,"config":393},{"href":114,"dataGaName":112,"dataGaLocation":381},{"text":395,"config":396},"GitLab auf AWS",{"href":397,"dataGaName":398,"dataGaLocation":381},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":400,"config":401},"GitLab auf Google Cloud",{"href":402,"dataGaName":403,"dataGaLocation":381},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":86,"config":405},{"href":91,"dataGaName":406,"dataGaLocation":381},"Why GitLab?",{"freeTrial":408,"mobileIcon":413,"desktopIcon":418,"secondaryButton":421},{"text":409,"config":410},"Kostenlos testen",{"href":411,"dataGaName":54,"dataGaLocation":412},"https://gitlab.com/-/trials/new/","nav",{"altText":414,"config":415},"GitLab-Symbol",{"src":416,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":414,"config":419},{"src":420,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":205,"config":422},{"href":423,"dataGaName":424,"dataGaLocation":412},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":426,"mobileIcon":430,"desktopIcon":432},{"text":427,"config":428},"Mehr über GitLab Duo erfahren",{"href":83,"dataGaName":429,"dataGaLocation":412},"gitlab duo",{"altText":414,"config":431},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":433},{"src":420,"dataGaName":417,"dataGaLocation":412},{"button":435,"mobileIcon":440,"desktopIcon":442},{"text":436,"config":437},"/Option",{"href":438,"dataGaName":439,"dataGaLocation":412},"#contact","switch",{"altText":414,"config":441},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":443},{"src":444,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":446,"mobileIcon":451,"desktopIcon":453},{"text":447,"config":448},"Zurück zur Preisübersicht",{"href":193,"dataGaName":449,"dataGaLocation":412,"icon":450},"back to pricing","GoBack",{"altText":414,"config":452},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":454},{"src":420,"dataGaName":417,"dataGaLocation":412},{"title":456,"button":457,"config":462},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":458,"config":459},"GitLab Transcend jetzt ansehen",{"href":460,"dataGaName":461,"dataGaLocation":49},"/de-de/events/transcend/virtual/","transcend event",{"layout":463,"icon":464,"disabled":31},"release","AiStar",{"data":466},{"text":467,"source":468,"edit":474,"contribute":479,"config":484,"items":489,"minimal":688},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":469,"config":470},"Quelltext der Seite anzeigen",{"href":471,"dataGaName":472,"dataGaLocation":473},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":475,"config":476},"Diese Seite bearbeiten",{"href":477,"dataGaName":478,"dataGaLocation":473},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":480,"config":481},"Beteilige dich",{"href":482,"dataGaName":483,"dataGaLocation":473},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":485,"facebook":486,"youtube":487,"linkedin":488},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[490,535,584,626,653],{"title":191,"links":491,"subMenu":506},[492,496,501],{"text":493,"config":494},"Tarife anzeigen",{"href":193,"dataGaName":495,"dataGaLocation":473},"view plans",{"text":497,"config":498},"Vorteile von Premium",{"href":499,"dataGaName":500,"dataGaLocation":473},"/de-de/pricing/premium/","why premium",{"text":502,"config":503},"Vorteile von Ultimate",{"href":504,"dataGaName":505,"dataGaLocation":473},"/de-de/pricing/ultimate/","why ultimate",[507],{"title":355,"links":508},[509,511,513,515,520,525,530],{"text":56,"config":510},{"href":58,"dataGaName":59,"dataGaLocation":473},{"text":364,"config":512},{"href":366,"dataGaName":367,"dataGaLocation":473},{"text":369,"config":514},{"href":371,"dataGaName":372,"dataGaLocation":473},{"text":516,"config":517},"Status",{"href":518,"dataGaName":519,"dataGaLocation":473},"https://status.gitlab.com/","status",{"text":521,"config":522},"Nutzungsbedingungen",{"href":523,"dataGaName":524,"dataGaLocation":473},"/terms/","terms of use",{"text":526,"config":527},"Datenschutzerklärung",{"href":528,"dataGaName":529,"dataGaLocation":473},"/de-de/privacy/","privacy statement",{"text":531,"config":532},"Cookie-Einstellungen",{"dataGaName":533,"dataGaLocation":473,"id":534,"isOneTrustButton":31},"cookie preferences","ot-sdk-btn",{"title":94,"links":536,"subMenu":545},[537,541],{"text":538,"config":539},"DevSecOps-Plattform",{"href":76,"dataGaName":540,"dataGaLocation":473},"devsecops platform",{"text":542,"config":543},"KI-unterstützte Entwicklung",{"href":83,"dataGaName":544,"dataGaLocation":473},"ai-assisted development",[546],{"title":547,"links":548},"Themen",[549,553,558,561,566,569,574,579],{"text":112,"config":550},{"href":551,"dataGaName":552,"dataGaLocation":473},"/de-de/topics/ci-cd/","cicd",{"text":554,"config":555},"GitOps",{"href":556,"dataGaName":557,"dataGaLocation":473},"/de-de/topics/gitops/","gitops",{"text":27,"config":559},{"href":560,"dataGaName":40,"dataGaLocation":473},"/de-de/topics/devops/",{"text":562,"config":563},"Versionskontrolle",{"href":564,"dataGaName":565,"dataGaLocation":473},"/de-de/topics/version-control/","version control",{"text":26,"config":567},{"href":568,"dataGaName":11,"dataGaLocation":473},"/de-de/topics/devsecops/",{"text":570,"config":571},"Cloud-nativ",{"href":572,"dataGaName":573,"dataGaLocation":473},"/de-de/topics/cloud-native/","cloud native",{"text":575,"config":576},"KI für das Programmieren",{"href":577,"dataGaName":578,"dataGaLocation":473},"/de-de/topics/devops/ai-for-coding/","ai for coding",{"text":580,"config":581},"Agentische KI",{"href":582,"dataGaName":583,"dataGaLocation":473},"/de-de/topics/agentic-ai/","agentic ai",{"title":585,"links":586},"Lösungen",[587,590,592,597,601,604,607,610,612,614,616,621],{"text":137,"config":588},{"href":132,"dataGaName":589,"dataGaLocation":473},"Application Security Testing",{"text":124,"config":591},{"href":108,"dataGaName":109,"dataGaLocation":473},{"text":593,"config":594},"Agile Entwicklung",{"href":595,"dataGaName":596,"dataGaLocation":473},"/de-de/solutions/agile-delivery/","agile delivery",{"text":598,"config":599},"SCM",{"href":121,"dataGaName":600,"dataGaLocation":473},"source code management",{"text":112,"config":602},{"href":114,"dataGaName":603,"dataGaLocation":473},"continuous integration & delivery",{"text":163,"config":605},{"href":165,"dataGaName":606,"dataGaLocation":473},"value stream management",{"text":554,"config":608},{"href":609,"dataGaName":557,"dataGaLocation":473},"/de-de/solutions/gitops/",{"text":176,"config":611},{"href":178,"dataGaName":179,"dataGaLocation":473},{"text":181,"config":613},{"href":183,"dataGaName":184,"dataGaLocation":473},{"text":186,"config":615},{"href":188,"dataGaName":189,"dataGaLocation":473},{"text":617,"config":618},"Bildungswesen",{"href":619,"dataGaName":620,"dataGaLocation":473},"/de-de/solutions/education/","education",{"text":622,"config":623},"Finanzdienstleistungen",{"href":624,"dataGaName":625,"dataGaLocation":473},"/de-de/solutions/finance/","financial services",{"title":196,"links":627},[628,630,632,634,637,639,641,643,645,647,649,651],{"text":208,"config":629},{"href":210,"dataGaName":211,"dataGaLocation":473},{"text":213,"config":631},{"href":215,"dataGaName":216,"dataGaLocation":473},{"text":218,"config":633},{"href":220,"dataGaName":221,"dataGaLocation":473},{"text":223,"config":635},{"href":225,"dataGaName":636,"dataGaLocation":473},"docs",{"text":245,"config":638},{"href":247,"dataGaName":248,"dataGaLocation":473},{"text":240,"config":640},{"href":242,"dataGaName":243,"dataGaLocation":473},{"text":250,"config":642},{"href":252,"dataGaName":253,"dataGaLocation":473},{"text":258,"config":644},{"href":260,"dataGaName":261,"dataGaLocation":473},{"text":263,"config":646},{"href":265,"dataGaName":266,"dataGaLocation":473},{"text":268,"config":648},{"href":270,"dataGaName":271,"dataGaLocation":473},{"text":273,"config":650},{"href":275,"dataGaName":23,"dataGaLocation":473},{"text":277,"config":652},{"href":279,"dataGaName":280,"dataGaLocation":473},{"title":295,"links":654},[655,657,659,661,663,665,667,672,677,679,681,683],{"text":302,"config":656},{"href":304,"dataGaName":297,"dataGaLocation":473},{"text":307,"config":658},{"href":309,"dataGaName":310,"dataGaLocation":473},{"text":315,"config":660},{"href":317,"dataGaName":318,"dataGaLocation":473},{"text":320,"config":662},{"href":322,"dataGaName":323,"dataGaLocation":473},{"text":325,"config":664},{"href":327,"dataGaName":328,"dataGaLocation":473},{"text":330,"config":666},{"href":332,"dataGaName":333,"dataGaLocation":473},{"text":668,"config":669},"Nachhaltigkeit",{"href":670,"dataGaName":671,"dataGaLocation":473},"/sustainability/","Sustainability",{"text":673,"config":674},"Vielfalt, Inklusion und Zugehörigkeit",{"href":675,"dataGaName":676,"dataGaLocation":473},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":335,"config":678},{"href":337,"dataGaName":338,"dataGaLocation":473},{"text":345,"config":680},{"href":347,"dataGaName":348,"dataGaLocation":473},{"text":350,"config":682},{"href":352,"dataGaName":353,"dataGaLocation":473},{"text":684,"config":685},"Transparenzerklärung zu moderner Sklaverei",{"href":686,"dataGaName":687,"dataGaLocation":473},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":689},[690,692,695],{"text":521,"config":691},{"href":523,"dataGaName":524,"dataGaLocation":473},{"text":693,"config":694},"Cookies",{"dataGaName":533,"dataGaLocation":473,"id":534,"isOneTrustButton":31},{"text":526,"config":696},{"href":528,"dataGaName":529,"dataGaLocation":473},[698],{"id":699,"title":9,"body":29,"config":700,"content":702,"description":29,"extension":28,"meta":706,"navigation":31,"path":707,"seo":708,"stem":709,"__hash__":710},"blogAuthors/en-us/blog/authors/itzik-gan-baruch.yml",{"template":701},"BlogAuthor",{"name":9,"config":703},{"headshot":704,"ctfId":705},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658921/Blog/Author%20Headshots/iganbaruch-headshot.jpg","iganbaruch",{},"/en-us/blog/authors/itzik-gan-baruch",{},"en-us/blog/authors/itzik-gan-baruch","bz9VMiTQ1ixvnoxUFk0jiUcnLG3oQsymgXNCqyRqfsk",[712,725,739],{"content":713,"config":723},{"title":714,"description":715,"authors":716,"heroImage":718,"date":719,"body":720,"category":11,"tags":721},"Softwareentwicklung lehren mit GitLab: ein Praxisbericht","Wie Lehrbeauftragter Stephen G. Dame GitLab for Education für Kursverwaltung, Assignment-Verteilung und direktes Code-Feedback im Hochschulalltag einsetzt.",[717],"Rod Burns","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659537/Blog/Hero%20Images/display-article-image-0679-1800x945-fy26.png","2026-04-29","Für Lehrende in der Softwareentwicklung ist die Verwaltung von Assignments\nund Feedback im großen Maßstab eine der größten logistischen Herausforderungen.\nWie gibt man vielen Studierenden Zugang zu Kursmaterialien, hält Musterlösungen\nprivat und liefert trotzdem kontextbezogenes, aussagekräftiges Feedback – ohne\nübermäßigen Verwaltungsaufwand?\n\nDas **[GitLab for Education-Programm](https://about.gitlab.com/de-de/solutions/education/)**\nstellt qualifizierten Bildungseinrichtungen kostenlosen Zugang zu\n**GitLab Ultimate** bereit. Damit können Lehrende professionelle Workflows\naufbauen, die reale Softwareentwicklungsumgebungen abbilden. Stephen G. Dame,\nLehrbeauftragter an der University of Washington mit langjähriger Erfahrung\nals leitender Softwareingenieur bei Boeing Commercial Airplanes, nutzt\ngenau diese Workflows – vom Kursmaterial bis zum Studierendenfeedback, über\nmehrere Lehrveranstaltungen hinweg.\n\n\n## Von der Luft- und Raumfahrt in den Hörsaal\n\nDame brachte aus seiner Zeit bei Boeing umfangreiche GitLab-Erfahrung mit\nin die Hochschullehre. Als früher Fürsprecher von GitLab an seiner Universität\ntrat er dem GitLab for Education-Programm bei, um Zugang zum vollständigen\nFeature-Set für strukturierte, skalierbare Kurs-Workflows zu erhalten.\n\n> **„GitLab bietet die beste Möglichkeit, mehrere Kurse, studentische\n> Assignments, Vorlesungen und Code-Beispiele über Groups und Subgroups\n> zu organisieren – eine Funktion, die ich in dieser Form bei anderen\n> Repository-Plattformen nicht gefunden habe.\"**\n>\n> – Stephen G. Dame, University of Washington, Bothell\n\n\n## Groups aufsetzen: Die richtige Struktur vor der ersten Codezeile\n\nDie Grundlage eines effektiven GitLab-basierten Kurses ist eine\ndurchdachte Group-Hierarchie. GitLabs\n**[Groups und Subgroups](https://docs.gitlab.com/tutorials/manage_user/#create-the-organization-parent-group-and-subgroups)**\nermöglichen es Lehrenden, die natürliche Struktur einer Hochschule –\nInstitution, Kurs und Rolle – mit präzisen, vererbbaren Berechtigungen\nauf jeder Ebene abzubilden.\n\nDames Struktur platziert die Universität als Wurzel (`UWTeaching`), jeder\nKurs erhält eine eigene Subgroup (z. B. `css430`). Innerhalb jedes Kurses\nbefinden sich Repositories für `lecture-materials` und `code` sowie\ndedizierte Subgroups für `students` und `graders`. Unterrichtsmaterialien\nbleiben privat; Studierenden- und Grader-Subgroups sind mit kontrollierten\nBerechtigungen konfiguriert, sodass Aufgabenstellungen und Musterlösungen\nnur den richtigen Personen zugänglich sind.\n\n![Screenshot der GitLab-Group-Hierarchie – Institution, Kurs-Subgroup und studierende-spezifische Subgroups](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777463673/dpxfnitv76pdmvcqtgag.png)\n\nBerechtigungen werden über **Manage > Members** durch die Hierarchie\nweitergegeben. Dame fügt Studierende mit `Reporter`-Zugriff und einem\nAblaufdatum zum Ende der Lehrperiode zur `students`-Subgroup des jeweiligen\nKurses hinzu. Studierende können Assignment-Repositories klonen und pullen,\naber nicht pushen – Musterlösungen bleiben fest unter der Kontrolle der\nLehrenden.\n\nStudierende richten SSH-Schlüssel in all ihren Arbeitsumgebungen (lokale\nRechner, Cloud-Shells, virtuelle Maschinen) ein, um Repositories zu klonen\nund wöchentliche Updates via `git pull` zu erhalten. Sie kopieren relevanten\nCode in eigene private Repositories, um ihre eigene Versionshistorie zu\nverwalten.\n\n**Hinweis für große Lehrveranstaltungen:** Bei größeren Kohorten ist das\nmanuelle Hinzufügen von Studierenden unpraktisch. GitLabs REST-API\nermöglicht die Automatisierung von Subgroup-Erstellung und Mitgliedschaft\naus einer Liste von Benutzernamen. Hier ein Beispiel-Python-Skript:\n\n```python\nimport gitlab\nfrom datetime import datetime\n\n# Verbindung zur GitLab-Instanz herstellen\ngl = gitlab.Gitlab('https://gitlab.com', private_token='YOUR_PRIVATE_TOKEN')\n\n# ID der übergeordneten Group (z. B. die ID für \"css430 > students\")\nparent_group_id = 12345678\n\n# Ablaufdatum: typischerweise Beginn des nächsten Monats nach Ende der Lehrperiode\nexpiry_date = '2025-01-01'\n\n# Liste der gesammelten Studierenden-Benutzernamen\nstudent_list = ['alice_css430', 'bob_css430', 'carol_css430', 'dave_css430', 'eve_css430']\n\nfor username in student_list:\n    try:\n        # 1. Persönliche Subgroup für Studierende erstellen\n        subgroup = gl.groups.create({\n            'name': username,\n            'path': username,\n            'parent_id': parent_group_id,\n            'visibility': 'private'\n        })\n\n        # 2. Studierende mit Ablaufdatum zur neuen Subgroup hinzufügen\n        user = gl.users.list(username=username)[0]\n        subgroup.members.create({\n            'user_id': user.id,\n            'access_level': gitlab.const.REPORTER_ACCESS,\n            'expires_at': expiry_date\n        })\n        print(f\"Erfolg: Subgroup erstellt und Studierende/r hinzugefügt für {username}\")\n    except Exception as e:\n        print(f\"Fehler bei der Verarbeitung von {username}: {e}\")\n```\n\nDarüber hinaus gibt es ein von GitLab veröffentlichtes\n[Open-Source-Projekt zur Automatisierung der Kursverwaltung](https://gitlab.com/edu-docs/class-management-automation),\ndas zusätzliche Werkzeuge für diesen Workflow bereitstellt.\n\n\n## Feedback dort geben, wo die Arbeit wirklich stattfindet\n\nSobald die Struktur steht, zeigt sich der eigentliche Mehrwert von GitLab\nim Feedback-Workflow. Dame bittet Studierende, Assignments durch Öffnen\neines **[Merge Requests](https://docs.gitlab.com/user/project/merge_requests/)**\nin ihrem Repository einzureichen. Das gibt Lehrenden sofort einen sauberen\nDiff von allem, was die Studierenden geschrieben haben.\n\n![Ein GitLab Merge Request mit Inline-Kommentarfunktion für Lehrende](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777467468/icclzyglbkwlvfysggbi.png)\n\nLehrende können auf jede Codezeile klicken und einen **Inline-Kommentar**\nhinterlassen – nicht nur um zu markieren, was falsch ist, sondern um zu\nerklären, warum, und um auf den nächsten Schritt hinzuweisen. Studierende\nerhalten dieses Feedback direkt im Kontext ihres Codes – deutlich\nhandlungsrelevanter als ein Kommentar am Ende eines eingereichten Dokuments.\n\n\n## GitLab for Education nutzen\n\nDie Einrichtung des ersten GitLab-Assignments erfordert anfänglichen Aufwand,\nläuft danach aber weitgehend von selbst. Der eigentliche Mehrwert geht über\ndie Organisation hinaus: Studierende schließen ihr Studium ab, nachdem sie\ntäglich in einer Umgebung gearbeitet haben, die professionelle\nSoftwareentwicklung abbildet – und dabei Gewohnheiten rund um\n[Versionskontrolle](https://about.gitlab.com/de-de/topics/version-control/)\nund [Code-Review](https://docs.gitlab.com/development/code_review/) nicht\nals abstrakte Konzepte kennenlernen, sondern praktisch einüben.\n\nEmpfehlenswert ist ein einfacher Einstieg: eine einzelne Kurs-Group, ein\nAssignment-Template, eine grundlegende Pipeline. Die Struktur wächst\nnatürlich mit der Erfahrung auf der Plattform.\n\n**[Für GitLab for Education anmelden](https://about.gitlab.com/de-de/solutions/education/join/)**,\num Zugang zu allen Top-Tier-Funktionen zu erhalten – darunter unbegrenzte\nReviewer bei Merge Requests, zusätzliche Compute-Minuten und erweiterter\nSpeicherplatz.\n\n> [Jetzt für das GitLab for Education-Programm bewerben](https://about.gitlab.com/de-de/solutions/education/join/).\n",[620,722],"open source",{"featured":14,"template":15,"slug":724},"teaching-software-development-the-easy-way-using-gitlab",{"content":726,"config":737},{"description":727,"authors":728,"heroImage":730,"date":731,"title":732,"body":733,"category":11,"tags":734},"Komm am 10. Februar 2026 auf die GitLab Transcend in München oder sei online live dabei. Finde heraus, wie du Produktivitätsgewinne mit Qualität, Zuverlässigkeit und Sicherheit in Einklang bringst.",[729],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1767982271/e9ogyosmuummq7j65zqg.png","2026-01-12","KI verändert DevSecOps: Triff GitLab und erfahre, was als Nächstes kommt","**KI verspricht einen Quantensprung bei der Innovationsgeschwindigkeit, doch die meisten Software-Teams stoßen an ihre Grenzen.**\n\nLaut unserem brandneuen [Global DevSecOps Report mit Zahlen für Deutschland](https://learn.gitlab.com/de-developer-survey/report-de-de-de-devsecops-report-practitioner) macht KI-generierter Code mittlerweile 32 Prozent aller Entwicklungsarbeit aus. Dennoch berichten 75 Prozent der deutschen DevSecOps-Expert(inn)en, dass KI das Compliance-Management erschwert, und 78 Prozent sagen, dass agentische KI beispiellose Sicherheitsherausforderungen schaffen wird.\n\nDas ist das **KI-Paradoxon:** KI beschleunigt das Programmieren, aber die Software-Auslieferung verlangsamt sich, weil Teams damit kämpfen, den Code zu testen, abzusichern und zu deployen.\n\n> **[Lade dir unseren DevSecOps Report für Deutschland *kostenlos* herunter!](https://learn.gitlab.com/de-developer-survey/report-de-de-de-devsecops-report-practitioner)**\n\n## Produktivitätsgewinne treffen auf Workflow-Engpässe\n\nDas Problem ist nicht die KI selbst. Es liegt daran, wie Software heute entwickelt wird. Der traditionelle DevSecOps-Lebenszyklus enthält Hunderte kleiner Aufgaben, die Entwickler(innen) manuell bewältigen müssen: Tickets aktualisieren, Tests ausführen, Reviews anfordern, auf Freigaben warten, Merge-Konflikte beheben, Sicherheitsprobleme angehen. Diese Aufgaben kosten laut unserer Forschung jedes Teammitglied durchschnittlich sieben Stunden pro Woche.\n\nEntwicklungsteams produzieren Code schneller als je zuvor, aber dieser Code kriecht immer noch durch fragmentierte Toolchains, manuelle Übergaben und unverbundene Prozesse. Tatsächlich verwenden nahezu 60 Prozent der deutschen DevSecOps-Teams mehr als fünf Tools für die Softwareentwicklung insgesamt, und 45 Prozent nutzen mehr als fünf KI-Tools. Diese Fragmentierung schafft Kollaborationsbarrieren – 97 Prozent der deutschen DevSecOps-Fachleute erleben Faktoren, die die Zusammenarbeit im Software-Entwicklungszyklus einschränken.\n\nDie Antwort sind nicht noch mehr Tools. Es ist intelligente Orchestrierung, die Software-Teams und ihre KI-Agenten über Projekte und Release-Zyklen hinweg zusammenbringt – mit eingebauter Sicherheit, Governance und Compliance auf Enterprise-Niveau.\n\n## Auf der Suche nach tieferen Mensch-KI-Partnerschaften\n\nDevSecOps-Profis wollen nicht, dass KI übernimmt – sie wollen verlässliche Partnerschaften. Die große Mehrheit (81 Prozent) sagt, dass die Nutzung agentischer KI ihre Arbeitszufriedenheit erhöhen würde, und 38 Prozent stellen sich eine ideale Zukunft mit einer 50/50-Aufteilung zwischen menschlichen und KI-Beiträgen vor. Sie sind bereit, KI rund ein Drittel ihrer täglichen Aufgaben ohne menschliche Überprüfung anzuvertrauen, besonders bei Dokumentation, Test-Erstellung und Code-Reviews.\n\nWas wir deutlich von deutschen DevSecOps-Expert(inn)en gehört haben, ist, dass KI sie nicht ersetzen wird; vielmehr wird sie ihre Rollen grundlegend verändern. 80 Prozent der DevSecOps-Fachleute glauben, dass KI ihre Arbeit innerhalb von fünf Jahren erheblich verändern wird, und bemerkenswert ist, dass drei Viertel denken, dies wird mehr Engineering-Jobs schaffen, nicht weniger. Da das Programmieren mit KI einfacher wird, werden Ingenieur(inn)en, die Systeme entwerfen, Qualität sicherstellen und geschäftlichen Kontext anwenden können, sehr gefragt sein.\n\nEntscheidend ist, dass 84 Prozent zustimmen, dass es wesentliche menschliche Qualitäten gibt, die KI niemals vollständig ersetzen wird, einschließlich Kreativität, Innovation, Zusammenarbeit und strategische Vision.\n\nWie können Organisationen also die Lücke zwischen dem Versprechen der KI und der Realität fragmentierter Workflows überbrücken?\n\n## Komm zur GitLab Transcend: Erfahre, wie du mit agentischer KI echten Wert schaffst\n\nAm 10. Februar 2026 veranstaltet GitLab Transcend, wo wir zeigen werden, wie intelligente Orchestrierung die KI-gestützte Softwareentwicklung transformiert. Du erhältst einen ersten Blick auf GitLabs kommende Produkt-Roadmap und erfährst, wie Teams reale Herausforderungen lösen, indem sie Entwicklungs-Workflows mit KI modernisieren.\n\nOrganisationen, die in dieser neuen Ära gewinnen, balancieren KI-Einführung mit Sicherheit, Compliance und Plattform-Konsolidierung. KI bietet echte Produktivitätsgewinne, wenn sie durchdacht implementiert wird – nicht indem sie menschliche Entwickler(innen) ersetzt, sondern indem sie DevSecOps-Profis befreit, sich auf strategisches Denken und kreative Innovation zu konzentrieren.\n\n> ## **Registriere dich jetzt für unser Event in München oder die Online-Konferenz**\n>\n> [Hier geht's zur digitalen Transcend](https://about.gitlab.com/events/transcend/virtual/) und [hier zum Live-Event in München](https://about.gitlab.com/events/transcend/munich/). Sichere dir deinen Platz und erfahre, wie intelligente Orchestrierung deinen Software-Teams helfen kann, im Flow zu bleiben.\n> *Die Transcend in München wird auf Englisch stattfinden.*",[24,735,736],"DevOps platform","security",{"featured":31,"template":15,"slug":738},"ai-is-reshaping-devsecops-attend-gitlab-transcend-to-see-whats-next",{"content":740,"config":749},{"title":741,"category":11,"tags":742,"authors":743,"heroImage":745,"body":746,"description":747,"date":748},"Shift Left Security: DevSecOps richtig umsetzen – ein Praxisleitfaden",[735],[744],"GitLab Germany Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1765222301/czfqu7ajwcwyyn4beg6k.jpg","Traditionelle Sicherheitsmodelle geraten in modernen [DevOps-Umgebungen](https://about.gitlab.com/de-de/topics/devops/) schnell an ihre Grenzen. Sicherheitsprüfungen, die erst spät im Entwicklungsprozess erfolgen, verursachen hohe Kosten, lange Reaktionszeiten und unterbrechen agile Workflows. Der Shift Left Security-Ansatz begegnet diesen Herausforderungen, indem er Sicherheitsmaßnahmen frühzeitig integriert. Statt reaktiv auf Sicherheitslücken zu reagieren, werden Risiken bereits in der Entwicklungsphase erkannt und adressiert. Wir zeigen dir, wie dieser Ansatz funktioniert, welche Vorteile er bietet und wie du Shift Left Security umsetzt.\n\n## **Was ist Shift Left Security?**\n\nShift Left Security bezeichnet einen Ansatz in der Softwareentwicklung, bei dem Sicherheitsmaßnahmen möglichst früh im Entwicklungsprozess integriert werden.\n\nTraditionell wurden Sicherheitstests erst am Ende des Softwareentwicklungszyklus (SDLC) durchgeführt, zum Beispiel in der Test- oder Produktionsphase. Dieses Vorgehen führt oft zu höheren Kosten und längeren Entwicklungszeiten, wenn kritische Sicherheitslücken spät entdeckt werden.\n\nMit dem Shift Left Ansatz wird das Thema Sicherheit nun auf der Zeitachse der Anwendungsentwicklung nach links verschoben, sodass anfälliger Code früh entdeckt werden kann. Ziel ist es, Schwachstellen schon in den frühen Phasen wie Planung, Design oder Codierung zu erkennen und zu beheben, statt sie erst im späteren Verlauf oder nach dem Deployment zu adressieren.\n\n![Infografik So funktioniert Shift Left](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765222295/lx0qqnnyse2ginovcnxb.jpg \"Schaubild: Shift Left Security, Sicherheitsmaßnahmen werden möglichst früh im Entwicklungsprozess integriert.\")\n\n## **Der Shift Left Ansatz**\n\nShift Left Security ist eine strategische Herangehensweise, bei der Sicherheit möglichst früh in den Entwicklungsprozess integriert wird – nicht durch ein einzelnes Tool, sondern durch eine Kombination verschiedener Maßnahmen.\n\nTypischerweise werden dafür Sicherheitstools entlang des Entwicklungszyklus eingesetzt, darunter:\n\n* **SCA (Software Composition Analysis)**: SCA erkennt Schwachstellen und Lizenzrisiken in Open-Source-Komponenten, indem es Paketverwaltung, Manifestdateien, Binärdateien und Container-Images analysiert. Die Ergebnisse werden in einer Software-Stückliste (sog.[ Software Bill of Materials](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)) zusammengeführt und mit Schwachstellen- und Lizenzdatenbanken abgeglichen. So lassen sich Sicherheits- und Compliance-Probleme systematisch aufspüren und schnell adressieren.\n* **SAST (Static Application Security Testing)**: SAST ist ein White-Box-Verfahren, das den Quellcode analysiert, ohne die Anwendung auszuführen. Es spiegelt die Sichtweise von Entwickler(innen) wider und erkennt Schwachstellen früh im Softwareentwicklungszyklus, z. B. fehlende Eingabevalidierung oder unsichere Codemuster. Dadurch ist es besonders kosteneffizient. Laufzeit- oder umgebungsbezogene Probleme kann SAST allerdings nicht erfassen.\n* **DAST (Dynamic Application Security Testing)**: DAST ist ein Black-Box-Verfahren, das laufende Web-Anwendungen testet und sich an der Methodik potenzieller Angreifer(innen) orientiert. Es erkennt Schwachstellen wie XSS, fehlerhafte Authentifizierung oder Konfigurationsfehler zur Laufzeit – ohne Kenntnis des zugrundeliegenden Codes. DAST wird typischerweise in späten Phasen der Entwicklung oder in Testumgebungen eingesetzt und eignet sich ausschließlich für Web-Anwendungen und -Services.\n* **Secret Scanning:** Shift Left Security umfasst auch das Scannen von Container-Images und serverlosen Funktionen, da moderne Anwendungen zunehmend in Containern ausgeführt oder über serverlose Architekturen bereitgestellt werden. Beim Scannen eines [Container-Images](https://about.gitlab.com/de-de/topics/devsecops/beginners-guide-to-container-security/) wird der Inhalt auf Sicherheitslücken, Schwachstellen im Build-Prozess und fehlerhafte Konfigurationen geprüft. Ziel ist es, Probleme zu erkennen, bevor das Image in der Produktion verwendet wird. Das Scannen serverloser Funktionen erfordert spezielle Überwachungslösungen, die cloud-native Umgebungen abdecken und auch ohne klassische Serverinfrastruktur funktionieren.\n\nDiese Tools können einzeln oder kombiniert verwendet werden. Effektiver ist jedoch eine [automatisierte Sicherheitsplattform](https://about.gitlab.com/de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform/), die Risiken in allen Phasen des Entwicklungszyklus erkennt – von der Codierung bis zur Bereitstellung. So können DevOps-Teams Schwachstellen frühzeitig und systematisch beheben.\n\n**Lesetipp:** [SAST vs. DAST - Die Unterschiede erklärt](https://about.gitlab.com/de-de/topics/devsecops/sast-vs-dast/)\n\n## **Vorteile der Shift Left Security**\n\nDie Linksverschiebung sicherheitsrelevanter Maßnahmen führt zu einer Reihe von Vorteilen für Unternehmen und Entwickler(innen).\n\n* **Frühzeitiges Erkennen von Sicherheitsrisiken:** Durch Sicherheitsanalysen direkt im Code oder bei der Integration von Abhängigkeiten lassen sich Schwachstellen erkennen, bevor sie in produktive Systeme gelangen. Dies verschafft Entwickler(innen) mehr Zeit für die Reaktion und reduziert die potenzielle Bedrohung (beispielsweise durch Exploits oder Datenlecks) erheblich.\n* **Geringere Kosten für Fehlerbehebung:** Je später ein Sicherheitsfehler entdeckt wird, desto teurer ist seine Behebung. Wird eine Schwachstelle bereits vor dem Build entdeckt, reicht oft eine einfache Codeänderung – ohne zusätzlichen Aufwand für Tests oder Deployments. Wird das Problem erst in der Produktion bemerkt, ist der Aufwand deutlich höher und der gesamte Prozess kann Wochen dauern. Frühes Eingreifen spart Zeit, senkt die Kosten und ermöglicht es Entwickler(innen), sich stärker auf neue Funktionen statt auf Notfallpatches zu konzentrieren.\n* **Schnellere Entwicklungszyklen:** Sicherheitsprobleme lassen sich schneller beheben, solange sie nur im Quellcode bestehen. Wird ein Problem erst kurz vor dem Release oder in der Produktion entdeckt, verlängert sich der Behebungsprozess deutlich – mit der Gefahr, gesetzte Fristen zu verpassen und die Time-to-Market zu verlangsamen.\n* **Bessere Codequalität:** Sicherheitsüberprüfungen fördern eine saubere Code-Architektur, konsistente Implementierung und verständlichen Code. So entstehen robuste und wartbare Anwendungen.\n* **Bessere Zusammenarbeit:** Shift Left Security fördert die Zusammenarbeitzwischen Entwickler(innen) und Security-Teams. Wird ein Sicherheitsproblem früh im Quellcode erkannt, können beide Seiten gemeinsam daran arbeiten, ohne Schuldzuweisungen oder Zeitdruck. Das verbessert die Kommunikation und stärkt das gegenseitige Verständnis.\n* **Reduziertes Risiko im Live-Betrieb:** Wird eine Schwachstelle erst im laufenden Betrieb entdeckt, sind schnelle und oft drastische Maßnahmen nötig – etwa das Abschalten der App. Wird die Schwachstelle hingegen bereits während der Entwicklung identifiziert, lässt sie sich mit geringem Aufwand und ohne größere Auswirkungen auf Nutzer(innen) beheben.\n\n***[Wie Dunelm, der britische Marktführer für Haushaltswaren, die Sicherheit \"nach links\" geschoben hat, steht in dieser ausführlichen Case Study.](https://about.gitlab.com/de-de/customers/dunelm/)***\n\n## **Best Practices für deinen Shift Left Security Ansatz**\n\nShift Left Security erfordert die frühzeitige und umfassende Integration von Sicherheitsmaßnahmen in den Entwicklungsprozess – idealerweise ab dem ersten Moment, in dem Entwickler(innen) mit dem Programmieren beginnen. Die Sicherheitsprüfung soll nicht nachgelagert, sondern integraler Bestandteil der täglichen Entwicklungsarbeit sein. Damit das gelingt, solltest du auf Best Practices zurückgreifen.\n\n### **\\#1 Integration von Sicherheitsmaßnahmen in die CI/CD-Pipeline**\n\nSicherheits-Scans sind ein zentrales Element des Shift-Left-Ansatzes. Ihre volle Wirkung entfalten sie aber nur, wenn die Ergebnisse unmittelbar in die[ DevOps-Toolkette](https://about.gitlab.com/de-de/topics/ci-cd/shift-left-devops/) eingebunden sind. Reports sollten direkt im CI/CD-Pipeline-Bericht angezeigt werden, sodass Entwickler(innen) sie ohne Umwege nutzen können. Zusätzlich sollte die Erstellung einer Software Bill of Materials (SBOM) automatisiert werden, um alle verwendeten Abhängigkeiten, Container-Images und serverlosen Funktionen transparent zu erfassen und systematisch auf bekannte Schwachstellen zu prüfen.\n\n### **\\#2 Anwendung von Security-Tools in der Entwicklungsumgebung**\n\nSicherheitsfunktionen sollten direkt in die Entwicklungsumgebung eingebunden werden, damit Schwachstellen bereits vor Übertragung in den Main Branch erkannt werden. Durch die Integration in die vertrauten Toolsets der Entwickler(innen) wird eine kontinuierliche Zusammenarbeit mit dem Security-Team ermöglicht und der Aufwand für nachträgliche Korrekturen deutlich reduziert.\n\n### **\\#3 Schulung von Entwickler(innen)**\n\nDamit Entwickler(innen) die Anwendungssicherheit bereits frühzeitig im Prozess berücksichtigen, ist eine intensive Schulung notwendig. Entwicklerteams müssen verstehen, warum sie Sicherheitsprüfungen frühzeitig durchführen – und welchen Beitrag das zur Gesamtqualität und Stabilität der Anwendung leistet. Dazu eignen sich praxisnahe und rollenbezogene Schulungsformate wie z. B. Code Labs, Code Guidelines oder Hands-on-Training.\n\n### **\\#4 Integration von Security Reviews in Code Reviews und Pull Requests**\n\nSicherheit sollte auch Teil von [Code Reviews](https://about.gitlab.com/de-de/topics/version-control/what-is-code-review/) sein. Teams können z. B. Checklisten mit sicherheitsrelevanten Aspekten verwenden. Pair Programming bietet zusätzlich die Möglichkeit, Sicherheit direkt beim Schreiben des Codes mitzudenken – vor allem in frühen Projektphasen.\n\n## **HackerOne + GitLab: Setze Shift Left Security einfach und kostengünstig um**\n\nEine der größten Herausforderungen für die Umsetzung der Shift Left Sicherheit für Entwicklerteams ist eine aufgeblähte Toolchain. Der Wechsel zwischen Tools und unklare Rollenverteilungen können die frühzeitige Integration von Sicherheitsüberprüfungen behindern.\n\nGitLab bietet mit HackerOne eine integrierte Lösung, die Security-Teams und Entwickler(innen) effektiv verbindet. Sicherheitslücken, die über HackerOne gemeldet und validiert werden, werden automatisch in GitLab als Tickets angelegt. Diese enthalten unter anderem:\n\n* Synchronisation von Kommentaren\n* Statusänderungen\n* Zuständigkeiten\n* Belohnungen\n* Fälligkeitsdaten\n\nDie Kommunikation erfolgt dabei bidirektional zwischen beiden Plattformen. Die Integration ermöglicht es somit Entwickler(innen), im gewohnten Workflow zu bleiben und Sicherheitslücken direkt zu bearbeiten.\n\n### **Auswirkungen der automatisierten Sicherheitsintegration**\n\nDie Integration von HackerOne und GitLab führt in der Praxis zu:\n\n* Bis zu 70 Prozent Zeitersparnis von der Entdeckung bis zur Behebung von Schwachstellen\n* Erhöhte Transparenz über den Sicherheitsstatus im gesamten Unternehmen\n* Effektivere Nutzung der Ressourcen im Security-Team\n* Gesteigerte Zufriedenheit der Entwickler(innen), da sie im bevorzugten Workflow bleiben können\n\n## **Keine Kompromisse bei der Shift Left Security**\n\nShift Left Security verschiebt das Thema Sicherheit weg von der Endkontrolle hin zur kontinuierlichen Begleitung des Entwicklungsprozesses. Durch Tools wie SAST, DAST, SCA und Container-Scanning lassen sich Schwachstellen frühzeitig identifizieren – noch bevor sie produktiv wirksam werden. Das senkt Kosten, reduziert Risiken und beschleunigt Entwicklungszyklen.\n\nErfolgreich ist dieser Ansatz jedoch nur, wenn Sicherheitsprüfungen eng in die[ CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/) und Entwicklungsumgebungen integriert werden und Entwickler(innen) durch gezielte Schulungen und klare Prozesse unterstützt werden. Die Fallstudie zu GitLab und HackerOne zeigt zudem, dass integrierte Plattformen Kontextwechsel vermeiden und die Effizienz deutlich steigern können. Entscheidend für eine nachhaltige Umsetzung ist eine Sicherheitskultur, in der Entwicklung und Security partnerschaftlich und auf Augenhöhe zusammenarbeiten.","Erkenne und behebe Sicherheitslücken früh mit Shift-Left-Security. Lerne aus HackerOnes GitLab-Story und erhalte praxisnahe DevSecOps-Tipps.","2025-12-08",{"featured":14,"template":15,"slug":750},"devsecops-shift-left-guide",{"promotions":752},[753,767,779,790],{"id":754,"categories":755,"header":757,"text":758,"button":759,"image":764},"ai-modernization",[756],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":760,"config":761},"Get your AI maturity score",{"href":762,"dataGaName":763,"dataGaLocation":248},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":765},{"src":766},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":768,"categories":769,"header":771,"text":758,"button":772,"image":776},"devops-modernization",[770,11],"product","Are you just managing tools or shipping innovation?",{"text":773,"config":774},"Get your DevOps maturity score",{"href":775,"dataGaName":763,"dataGaLocation":248},"/assessments/devops-modernization-assessment/",{"config":777},{"src":778},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":780,"categories":781,"header":782,"text":758,"button":783,"image":787},"security-modernization",[736],"Are you trading speed for security?",{"text":784,"config":785},"Get your security maturity score",{"href":786,"dataGaName":763,"dataGaLocation":248},"/assessments/security-modernization-assessment/",{"config":788},{"src":789},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":791,"paths":792,"header":795,"text":796,"button":797,"image":802},"github-azure-migration",[793,794],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":798,"config":799},"See how GitLab compares to GitHub",{"href":800,"dataGaName":801,"dataGaLocation":248},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":803},{"src":778},{"header":805,"blurb":806,"button":807,"secondaryButton":812},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":808,"config":809},"Kostenlosen Test starten",{"href":810,"dataGaName":54,"dataGaLocation":811},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":56,"config":813},{"href":58,"dataGaName":59,"dataGaLocation":811},1777493586183]