[{"data":1,"prerenderedAt":815},["ShallowReactive",2],{"/de-de/blog/jenkins-to-gitlab-migration-made-easy":3,"navigation-de-de":40,"banner-de-de":453,"footer-de-de":463,"blog-post-authors-de-de-Fernando Diaz":696,"blog-related-posts-de-de-jenkins-to-gitlab-migration-made-easy":710,"blog-promotions-de-de":752,"next-steps-de-de":805},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":24,"extension":25,"externalUrl":26,"featured":14,"heroImage":17,"isFeatured":14,"meta":27,"navigation":14,"path":28,"publishedDate":20,"rawbody":29,"seo":30,"slug":13,"stem":35,"tagSlugs":36,"tags":38,"template":15,"updatedDate":19,"__hash__":39},"blogPosts/de-de/blog/jenkins-to-gitlab-migration-made-easy.yml","Migration von Jenkins zu GitLab leicht gemacht",[7],"fernando-diaz",[9],"Fernando Diaz","GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Das bedeutet, dass GitLab alles bietet, was du benötigst, um sichere Software schneller zu planen, zu entwickeln und bereitzustellen – alles in einem Tool.\n\nPlattformen vereinfachen die Integration verschiedener Tools (DIY-DevOps), um den Software-Entwicklungsprozess (SDLC) zu unterstützen. Da Jenkins keine Plattform ist, sind zusätzliche Tools erforderlich, um den Software-Entwicklungsprozess zu vervollständigen. Dieser DIY-DevOps-Ansatz erhöht die Komplexität der Toolchain, was die folgenden Nachteile mit sich bringt:\n\n* Bedarf an individuellem Support für die Integration und Orchestrierung von Tools\n* Schwierigkeiten bei der Wartung/Aktualisierung/Sicherung separater Tools\n* Ineffizienz bei der Evaluierung der Unternehmenstransformation\n* Schlechte Entwicklererfahrung\n* Zusätzliche Management-/Zeit-/Budgetkosten\n* Produktivitätsverlust\n* Ineffizienz im Hinblick auf Kontextwechsel und Zusammenarbeit\n\n![Import project selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png \"DIY-DevOps im Vergleich zu einer DevSecOps-Plattform\")\n\nAus diesen Gründen erwägen viele Jenkins-Teams, zu einer DevSecOps-Plattform zu migrieren. Wer nach einer leistungsfähigeren, zuverlässigeren und sichereren Lösung sucht, sollte GitLab wählen! GitLab ist kostenlos für Einsteiger(innen) und bietet verschiedene Abonnementstufen, je nachdem, welche Anforderungen dein Unternehmen hat. Weitere Informationen zu unseren Angeboten und Funktionen findest du auf unserer [Preisseite](https://about.gitlab.com/de-de/pricing/).\n\nIn diesem Blog erfährst du:\n\n* wie du eine Migration planst\n* wie du Repositories von anderen Tools für die Quellcodeverwaltung (SCM) zu GitLab migrierst\n* wie du CI/CD-Pipelines von Jenkins zu GitLab migrierst\n* welche weiteren Überlegungen du dir zu Migrationen machen solltest\n\n### Planung einer Migration\n\nBevor du eine Migration von einem anderen Tool zu GitLab CI/CD startest, solltest du zunächst einen Migrationsplan erstellen. Ein Migrationsplan ist ein wichtiger technischer Schritt, um Erwartungen festzulegen. CI/CD-Tools unterscheiden sich im Hinblick auf ihren Ansatz und Aufbau sowie ihre technischen Besonderheiten. Das bedeutet, dass Migrationen keine simplen, direkten Zuordnungen von Daten sind. Ein Migrationsplan bietet folgende Vorteile:\n\n* Er legt eine klare Vorstellung deiner Migrationsziele fest und kommuniziert sie. Dies hilft deinen Benutzer(innen) dabei, zu verstehen, warum sich der Aufwand lohnt. Der Nutzen wird deutlich, wenn die Migration abgeschlossen ist, aber die Beteiligten müssen sich dessen auch während der Migration bewusst sein.\n* Er ermöglicht die Unterstützung und Beteiligung der entsprechenden Führungsteams – dies trägt zum oben genannten Punkt bei.\n* Er bietet die Gelegenheit, Benutzer(innen) über Veränderungen aufzuklären.\n* Er findet Wege, um Teile der Migration zu sequenzieren oder zu verzögern und zu verhindern, dass nicht migrierte (oder teilweise migrierte) Zustände zu lange bestehen bleiben.\n* Er dokumentiert die Vorteile der Verbesserungen, die GitLab CI/CD bietet, und aktualisiert deine Implementierung im Rahmen der Umstellung.\n\nMit einem Migrationsplan kannst du einen Prozess einrichten, bei dem du mit minimalen Unterbrechungen langsam zu GitLab migrieren kannst. Dies kann bedeuten, dass Jenkins und GitLab parallel eingesetzt werden, während bestimmte Projekte zu GitLab verschoben und von Jenkins abgezogen werden.\n\n### Definition eines Change-Management-Prozesses\n\nDer Migrationsplan sollte einen effektiven Change-Management-Prozess definieren. Entwicklungs- und IT Operations-Teams, Cloud-Administrator(inn)en sowie Sicherheits- und Qualitätsteams haben möglicherweise keine Erfahrung mit GitLab und sie wissen möglicherweise nicht, warum du oder deine Führungskraft sich entschieden haben, diesen Weg einzuschlagen.\n\nWer von den Veränderungen betroffen ist, muss Folgendes wissen:\n\n* **Warum** die Veränderung vorgenommen wird\n* **Wie** der zukünftige Zustand aussehen wird\n* **Wie** das Unternehmen den neuen Zustand erreichen möchte\n* **Wo** weitere Informationen oder Unterstützung zu finden sind\n\nZu diesem Zweck solltest du die folgenden Schritte in Erwägung ziehen, um Veränderungen für diese funktionalen Rollen zu steuern:\n\n* **Analysiere den aktuellen Zustand**: Dokumentiere den aktuellen Zustand der Prozesse. Sammle Indikatoren als Basis. Ermittle, was im Hinblick auf CI/CD funktioniert und was nicht, indem du wichtige Teammitglieder befragst. Dokumentiere die Herausforderungen, die du feststellst, sowohl in quantitativer als auch in qualitativer Hinsicht. Du musst andere von der Vision und dem Grund für die Veränderung überzeugen. Je klarer du also die Problemstellung definieren kannst, desto einfacher wird es, die Zustimmung des gesamten Unternehmens zu gewinnen.\n* **Baue eine Vision auf**: Nun, da du die aktuellen Probleme quantitativ mithilfe von Basisindikatoren und qualitativ (mit den Worten deiner Teammitglieder) beschrieben hast, stelle eine Vision des zukünftigen Zustands vor. Erläutere, warum dies wichtig ist (stelle einen Zusammenhang zu geschäftlichen Erfolgsindikatoren her). Biete Live- sowie aufgezeichnete Demos an, um aufzuzeigen, welche Möglichkeiten es gibt, und vergleiche diese Vision mit dem aktuellen Zustand. Betone diese Botschaft auf mehreren Kanäle und in verschiedenen Medien – Chat-Gruppen, allgemeine Meetings, E-Mail-Benachrichtigungen, Banner-Benachrichtigungen auf GitLab usw.\n* **Kläre die Belegschaft auf**: Investiere in [GitLab-CI/CD-Schulungen (nur in englischer Sprache verfügbar)](https://university.gitlab.com/pages/ci-cd-training/), die von GitLab-Expert(inn)en durchgeführt werden. Evaluiere den Erwerb und das Verinnerlichen von Kenntnissen mithilfe von [GitLab-Zertifizierungen (nur in englischer Sprache verfügbar)](https://levelup.gitlab.com/pages/certifications).\n* **Kommuniziere Roadmap und Ressourcen**: Teile deinen Teammitgliedern den geplanten Zeitplan sowie die verfügbaren Ressourcen für die Migration mit. Nenne Community-Ressourcen wie Chat-Gruppen, Q&A-Boards oder die Kontaktzeiten von GitLab-Influencern oder -Influencerinnen, damit dein Team Fragen stellen und Unterstützung erhalten kann. Der Aufbau eines Belohnungssystems, das das Teams dazu anregt, frühzeitig umzusteigen und ihre Erfahrungen mit anderen Anwendergruppen zu teilen, wäre ein Pluspunkt!\n\nWenn du diese Elemente zu Beginn der Migration sicherstellst, stellst du die Weichen für ihren Erfolg.\n\n### Festlegung von Migrationszielen\n\nBevor du eine Migration durchführst, solltest du dir über deine Ziele im Klaren sein und wissen, wie du sie erreichen kannst. Einige Fragen, auf die du Antworten haben solltest, sind beispielsweise folgende:\n\n* Was ist dein Zeitplan für die Migration?\n* Wie ist dein Jenkins-Server aktuell konfiguriert?\n* Wie viele Projekte müssen migriert werden?\n* Wie komplex ist deine Pipeline?\n* Gibt es externe Abhängigkeiten, mehrere Pipeline-Trigger, parallele Builds usw.?\n* Wie/wo stellst du deinen Code bereit?\n* Was ist der Veröffentlichungs-/Überprüfungsprozess für die Bereitstellung von Code?\n* Ist der Workflow in Jenkins integriert oder gibt es einen separaten Workflow, der von Jenkins ausgelöst wird?\n* Welche Build-Artefakte oder Binärdateien sind für den Erfolg der Pipeline erforderlich?\n* Welche Plugins verwenden Jobs in Jenkins derzeit?\n* Welche Software ist auf den Jenkins-Agenten installiert?\n* Welche Lösung für die Quellcodeverwaltung verwendest du aktuell?\n* Verwenden deine Jenkins-Jobs gemeinsam genutzte Bibliotheken?\n* Welche Authentifizierungsmethode kommt für Jenkins zum Einsatz (Basic Authentication, LDAP/AD, SSO)?\n* Gibt es andere Projekte, auf die du von deiner Pipeline aus zugreifen musst?\n* Gibt es Zugangsdaten in Jenkins, die für den Zugriff auf externe Dienste verwendet werden?\n\nWenn du diese Fragen beantwortest, weißt du, wie du bei der Migration vorgehen solltest, wie lange sie dauert und wo du anfangen solltest. Wenn du einen Plan erstellt hast und dir die Erwartungen und möglichen Fallstricke bewusst sind, kannst du mit dem Migrationsprozess beginnen.\n\n### Voraussetzungen für die Migration\n\nSobald du einen Migrationsplan erstellt und alle Erwartungen an die Migration bedacht hast, kannst du mit der Einrichtung von GitLab beginnen. Hier sind einige empfohlene Voraussetzungen für die Migration:\n\n* Mache dich mit GitLab vertraut. Informiere dich über die [wichtigsten GitLab CI/CD-Funktionen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/).\n* Folge den englichsprachigen Tutorials, um deine erste [GitLab-Pipeline](https://docs.gitlab.com/ci/quick_start/) und [komplexere Pipelines](https://docs.gitlab.com/ci/quick_start/tutorial/) zu generieren, die eine statische Website erstellen, testen und bereitstellen.\n* Lies die [Keyword-Referenz für .gitlab-ci.yml (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/yaml/).\n* Richte GitLab ein und konfiguriere es.\n* Teste deine GitLab-Instanz.\n\nSobald du mit GitLab vertraut bist und eine Instanz konfiguriert hast, kannst du deinem Migrationsplan folgen und damit beginnen, Projekte von Jenkins zu GitLab zu verschieben. Stelle sicher, dass deine GitLab-Instanz mithilfe von bewährten Methoden für GitLab und gemäß [Referenzarchitekturen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/reference_architectures/) ordnungsgemäß eingerichtet wurde.\n\n### Migration von Repositories zu GitLab\n\nEiner der wichtigsten Nachteile von Jenkins ist, dass es keine Lösung für die Quellcodeverwaltung (SCM, Source Code Management) bietet. Wenn du Jenkins verwendest, muss dein Code in einer separaten SCM-Lösung gespeichert werden, auf die Jenkins Zugriff haben muss. Da GitLab über eine integrierte Quellcodeverwaltung verfügt, ermöglicht der Umstieg von Jenkins auch die Migration der zuvor genutzten SCM-Lösung. Dies verringert die Kosten zusätzlich.\n\nGitLab bietet Tools, mit denen du dein Repository und seine Metadaten einfach zu GitLab verschieben kannst. Die folgenden Importer (nur in englischer Sprache verfügbar) unterstützen dich bei der Migration deiner Projekte zu GitLab:\n\n* [GitHub](https://docs.gitlab.com/user/project/import/github/)\n* [Eine weitere GitLab-Instanz](https://docs.gitlab.com/user/project/settings/import_export/)\n* [Bitbucket Cloud](https://docs.gitlab.com/user/project/import/bitbucket/)\n* [Bitbucket Server](https://docs.gitlab.com/user/project/import/bitbucket_server/)\n* [FogBugz](https://docs.gitlab.com/user/project/import/fogbugz/)\n* [Gitea](https://docs.gitlab.com/user/project/import/gitea/)\n* [Jira (nur Issues)](https://docs.gitlab.com/user/project/import/jira/)\n – [Repo per Manifestdatei](https://docs.gitlab.com/user/project/import/manifest/)\n* [Repo per URL](https://docs.gitlab.com/user/project/import/repo_by_url/)\n\n\n![GitHub to GitLab Repo Exporter](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png \"Repoitory-Exporter von GitHub zu GitLab\")\n\n\u003Cp>\u003C/p>\n\nJeder Importer importiert unterschiedliche Daten aus einem Projekt. Lies die [Dokumentation zum Import und zur Migration von Projekten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/import/), um mehr Informationen über die bereitgestellten Importer zu erhalten und zu erfahren, welche Daten zu GitLab migriert werden. Darüber hinaus kannst du [den Import von Gruppen und Projekten automatisieren (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/import/#automate-group-and-project-import) und eine benutzerdefinierte Lösung erstellen, welche die Anforderungen deines Unternehmens noch besser erfüllt:\n\n* [Professional Services](https://about.gitlab.com/de-de/services/)\n* [Migrations-Tools](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n* [Häufig gestellte Fragen zur Migration](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n### So migrierst du ein Repository\n\nMit unseren integrierten Importern kannst du Repositories ganz einfach zu GitLab migrieren. In diesem Beispiel erfährst du, wie du ein Repo zusammen mit [seinen Ressourcen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/import/github/#imported-data) (Tickets, Pull Requests, Meilensteine usw.) aus GitHub zu GitLab kopierst. Um ein Repository aus einem anderen GitHub zu GitLab zu migrieren, führe die folgenden Schritte aus:\n\n1. Wähle oben in der linken Menüleiste **Neu erstellen (+)** aus.\n2. Wähle im Abschnitt „In GitLab“ **Neues Projekt/Repository** aus.\n\n3. Wähle **Projekt importieren** aus.\n\n\n![Import project selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png \"Auswahl des zu importierenden Projekts\")\n\n\u003Cp>\u003C/p>\n\n4. Klicke auf die Schaltfläche **GitHub**.\n\n * Wenn du GitLab Self-Managed verwendest, musst du [den GitHub-Importer aktivieren (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/settings/import_and_export_settings/#configure-allowed-import-sources).\n * Beachte, dass andere Importer auf dieselbe Weise initiiert werden können.\n5. Jetzt kannst du:\n\n * dich mit GitHub OAuth autorisieren: Wähle **Mit GitHub autorisieren** aus.\n * einen persönlichen GitHub-Zugriffstoken verwenden:\n\n * Gehe zu \u003Chttps://github.com/settings/tokens/new>.\n * Gib im Feld **Notizen** eine Token-Beschreibung ein.\n * Wähle den Geltungsbereich für das Repository aus.\n * Um Beteiligte zu importieren, wähle optional den Geltungsbereich **read:org** aus.\n * Klicke auf die Schaltfläche **Token generieren**.\n * Füge auf der GitLab-Importseite im Feld „Persönlicher Zugriffstoken“ den persönlichen GitHub-Zugriffstoken ein.\n6. Klicke auf die Schaltfläche **Authentifizieren**.\n7. Wähle die Elemente aus, die du migrieren möchtest.\n8. Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie migrieren möchtest.\n9. Klicke auf die Schaltfläche **Importieren**.\n\nNun sollte sich das importierte Projekt in deinem Arbeitsbereich befinden. Weitere Informationen über die Migration von GitHub zu GitLab findest du in diesem englischsprachigen Video:\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nSobald du die Migration des Repositories abgeschlossen hast, kannst du deine Jenkins-Pipeline so einstellen, dass sie die Jenkins-Datei in GitLab nutzt. Lege dazu die Repository-URL für dein neu importiertes Projekt über das Jenkin-Pipeline-Konfigurationsmenü fest:\n\n\n![Jenkins Pipeline SCM settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png \"SCM-Einstellungen für die Jenkins-Pipeline\")\n\n\u003Cp>\u003C/p>\n\nDies ist nützlich für die anfängliche Repo-Migrationsphase und hilft dir dabei, sowohl Jenkins als auch GitLab parallel zu verwenden. So kannst du Dienstunterbrechungen vermeiden, während du die CI/CD-Funktionalität migrierst.\n\nDarüber hinaus kannst du das [GitLab-Jenkins-Plugin](https://plugins.jenkins.io/gitlab-plugin/) als Hilfestellung bei der Migration nutzen. Mit diesem Plugin kann GitLab den Status von Jenkins-Builds auslösen und abrufen.\n\n### Migration von CI/CD-Pipelines\n\nSobald du deine Repositories zu GitLab migriert hast, kannst du mit der Migration deiner Jenkins-Pipelines zu GitLab fortfahren. Dieser Prozess kann relativ simpel sein, du solltest dazu jedoch die Konzepte und die Syntax von Jenkins und GitLab verstehen.\n\nJenkins bietet zwei verschiedene Arten von Syntax für die Definition von Pipelines: Declarative und Scripted. Dieser Leitfaden behandelt die Migration von Pipelines des Typs Declarative, da diese am häufigsten vorkommen.\n\n### Schritt-für-Schritt-Migration der Pipeline\n\nIn diesem Tutorial wird eine Jenkins-Datei (Groovy) im Vergleich zu einer GitLab-CI/CD-Konfigurationsdatei (YAML) analysiert, die einen in Golang geschriebenen Microservice generiert, testet und bereitstellt. Anschließend werden die Pipeline in GitLab aktiviert und die Ergebnisse angezeigt. Die Pipeline wird:\n\n* das Golang-Container-Image mit dem Tag **alpine** verwenden,\n* einen Job zur Erstellung des Golang-Codes in einer ausführbaren Binärdatei ausführen,\n\n * die erstellte ausführbare Datei als Artefakt speichern,\n* einen Job ausführen, um Unit-Tests durchzuführen,\n* einen Jobs zur Bereitstellung im Staging ausführen.\n\n * Dieser wird nur ausgeführt, wenn der Commit auf den Branch **Staging** abzielt,\n * beginnt, nachdem die Phase **Test** erfolgreich abgeschlossen wurde,\n * verwendet das erstellte ausführbare Artefakt aus dem vorherigen Job.\n\nUnten findest du die Pipeline-Definitionen aus Jenkins und GitLab sowie beschreibende Kommentare. Im [Meow-Migrationsprojekt](https://gitlab.com/gitlab-da/projects/blogs/meow-migration) kannst du die Pipeline in Aktion sehen.\n\nSchaue dir eine in Groovy geschriebene Jenkins-Datei an:\n\n```shell\n// Die höchste Ebene der Declarative-\n// Pipeline.\npipeline {\n\n // Definiert den zu verwendenden Standard-Agenten,\n // sofern nicht explizit in einem Job\n // definiert.\n agent any\n\n // Definiert die Staging-Phasen, die in\n // numerischer Reihenfolge ausgeführt werden. Jede Staging-Phase\n // führt nur einen Job aus.\n stages {\n\n // Definiert den Namen der Staging-Phase.\n stage('build') {\n // Definiert das Container-Image,\n // das für diesen Job verwendet werden soll. Dies überschreibt\n // die Standardeinstellung 'agent any'.\n // Das Jenkins-Docker-Plugin\n // muss konfiguriert sein, damit dies\n // ausgeführt wird.\n agent { docker 'golang:alpine' }\n\n // Definiert die Abfolge von Schritten,\n // die bei der Ausführung der Staging-Phase\n // befolgt werden soll.\n steps {\n sh 'go build -o bin/meow-micro'\n sh 'chmod +x bin/meow-micro'\n }\n\n // Die Schritte, die nach Abschluss der\n // Staging-Phase ausgeführt werden sollen.\n post {\n always {\n\n // Speichert die Artefakte der Staging-Phase,\n // die zur Verwendung in einem anderen Job\n // generiert wurden.\n archiveArtifacts artifacts: 'bin/meow-micro'\n onlyIfSuccessful: true\n }\n }\n }\n\n stage('test') {\n agent { docker 'golang:alpine' }\n steps {\n sh 'go test .'\n }\n }\n\n stage('deploy') {\n // Definiert die Bedingungen,\n // die zur Ausführung des Jobs\n // erfüllt sein müssen. In diesem Fall wird der\n // Bereitstellungs-Job nur auf dem\n // Staging-Branch ausgeführt.\n when {\n branch 'staging'\n }\n steps {\n echo 'Deploying meow-micro to staging'\n // Verwendet das Artefakt, das in der\n // Build-Staging-Phase gespeichert wurde.\n sh './bin/meow-micro'\n }\n }\n }\n}\n```\n\nSchaue dir nun an, wie die gleiche Funktion in GitLab erstellt werden kann:\n\n```text\n# Definiert das zu verwendende Standard-Image,\n# sofern nicht explizit in einem Job\n# angegeben.\ndefault:\n image: alpine:latest\n\n# Definiert die Reihenfolge der auszuführenden Staging-Phasen.\n# Jede Staging-Phase kann mehrere Jobs umfassen.\nstages:\n - build\n - test\n - deploy\n\n# Definiert den Namen des Jobs.\ncreate-binary:\n # Definiert die Staging-Phase, in welcher der Job ausgeführt wird.\n stage: build\n # Definiert das Container-Image, das für\n # diesen Job verwendet werden soll. Dies überschreibt die Standardeinstellung.\n image: golang:alpine\n # Definiert die Reihenfolge der Schritte,\n # die bei der Ausführung des Jobs befolgt werden sollen.\n script:\n - go build -o bin/meow-micro\n - chmod +x bin/meow-micro\n # Speichert die Job-Artefakte, die zur\n # Verwendung in einem anderen Job gespeichert wurden.\n artifacts:\n paths:\n - bin/meow-micro\n expire_in: 1 week\n\nunit-tests:\n stage: test\n image: golang:alpine\n script:\n - go test .\n # Definiert Befehle, die im Anschluss an den Job\n # ausgeführt werden sollen.\n after_script:\n - echo \"Tests Complete\"\n\nstaging-deploy:\n stage: deploy\n # Definiert die Befehle, die vor dem\n # eigentlichen Job ausgeführt werden sollen.\n before_script:\n - apk update\n script:\n - echo \"Deploying meow-micro to staging environment\"\n - ./bin/meow-micro\n # Definiert die Bedingungen, die zur\n # Ausführung dieses Jobs erfüllt sein müssen. In\n # diesem Fall wird der Bereitstellungs-Job der Staging-Phase nur\n # auf dem Staging-Branch ausgeführt.\n rules:\n - if: $CI_COMMIT_BRANCH == 'staging'\n # Erlaubt die Verwendung der Artefakte, die im\n # Build-Job gespeichert wurden, in diesem Job.\n artifacts:\n paths:\n - bin/meow-micro\n```\n\nWie du vielleicht bemerkt hast, gibt es viele Gemeinsamkeiten zwischen Jenkins und GitLab im Hinblick auf die Syntax. Dies vereinfacht die Pipeline-Migration. Sieh dir die umfassende Liste der [Funktions- und Konzeptvergleiche (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/migration/jenkins/#comparison-of-features-and-concepts) zwischen den beiden Tools an.\n\nNun, da du verstehst, wie man Jenkins in GitLab abbildet, kannst du damit beginnen, eine Pipeline mit der gleichen Funktionalität in GitLab zu erstellen. Um CI/CD zu migrieren, kannst du die folgenden Schritte ausführen:\n\n##### 1. Öffne das Repository, das du im obigen Abschnitt zu GitLab migriert hast.\n\n* Klicke oben in der linken Seitenleiste auf **Suchen oder aufrufen …**.\n* Wähle dein Projekt aus.\n\n##### 2. Öffne den [Pipeline-Editor (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/pipeline_editor/).\n\n* Wähle in der linken Seitenleiste **Build > Pipeline-Editor** aus.\n* Klicke auf die Schaltfläche **Pipeline konfigurieren**.\n\n\n![Configure pipeline selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png \"Auswahl der Schaltfläche „Pipeline konfigurieren“\")\n\n\u003Cp>\u003C/p>\n\n##### 3. Befülle die Datei [.gitlab-ci.yml (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/yaml/).\n\n* Füge den GitLab-CI-Pipeline-Code hinzu.\n* Prüfe, ob die Syntax korrekt ist.\n\n\n![Pipeline syntax validation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png \"Validierung der Pipeline-Syntax\")\n\n\u003Cp>\u003C/p>\n\n* Visualisiere die Pipeline.\n\n\n![Pipeline visualization](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png \"Visualisierung der Pipeline\")\n\n\u003Cp>\u003C/p>\n\n##### 4. Committe die Datei in den Main-Branch.\n\n* Füge eine Commit-Nachricht hinzu.\n* Stelle sicher, dass es sich um den Main-Branch handelt.\n* Klicke auf die Schaltfläche **Änderungen committen**.\n\n\n![Commit changes dialog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png \"Dialog „Änderungen committen“\")\n\n\u003Cp>\u003C/p>\n\nSobald die Datei zusammengeführt wurde, wird die definierte Pipeline gestartet. Du kannst zu deinem Projekt zurückkehren und [die Pipeline anzeigen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/pipelines/#view-pipelines), indem du sie auf der Seite deines Projekts **Build > Pipelines** auswählst. Da sie auf dem **Main**-Branch ausgeführt wurde, siehst du nur den Job **create-binary** sowie die „unit-test“ Jobs. Der Job **staging-deploy** wird nur auf dem Staging-Branch ausgeführt.\n\n\n![Pipeline running on main branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png \"Auf dem Main-Branch ausgeführte Pipeline\")\n\n\u003Cp>\u003C/p>\n\nBei der Erstellung eines Staging-Branches wird die folgende Pipeline gestartet.\n\n\n![Pipeline running on staging branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png \"Auf dem Staging-Branch ausgeführte Pipeline\")\n\n\u003Cp>\u003C/p>\n\nWenn du auf einen Job klickst, wird dessen Ausgabe angezeigt:\n\n\n![create-binary job output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png \"Ausgabe des Jobs create-binary\")\n\n\u003Cp>\u003C/p>\n\n\n![unit-tests job output input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png \"Eingabe/Ausgabe des Jobs unit-tests\")\n\n\u003Cp>\u003C/p>\n\n\n![staging-deploy job output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png \"Ausgabe des Jobs staging-deploy\")\n\n\u003Cp>\u003C/p>\n\nDu kannst sehen, wie das Artefakt im Job create-binary gespeichert und im Job staging-deploy verwendet wird. Und so einfach ist es, eine Pipeline von Jenkins zu GitLab zu migrieren!\n\n### Zusätzliche Überlegungen zur Migration\n\nEinige hilfreiche Überlegungen, die den Bereitstellungsprozess unserer Ansicht nach einfacher machen, sind folgende:\n\n* Versuche nicht, Aufgaben exakt als GitLab-Jobs zu replizieren. Nimm dir Zeit und schaue dir genauer an, was die aktuelle Pipeline bewirkt und welches Problem sie löst.\n* Einige Jenkins-Jobs sind möglicherweise zu komplex, um sofort zu GitLab migriert zu werden. Deshalb kann es von Vorteil sein, das [GitLab-Jenkins-Plugin](https://plugins.jenkins.io/gitlab-plugin/) zu verwenden, um Jenkins-Pipelines zu starten und ihre Ergebnisse direkt in GitLab anzuzeigen. Auf diese Weise kannst du bestimmte Aktionen langsam zu GitLab migrieren, bis die gesamte Pipeline verschoben werden kann.\n* Implementiere [Sicherheitsscanner und Codequalität (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/application_security/) mithilfe von integrierten Vorlagen, die GitLab von Anfang an bereitstellt. So kannst du die Sicherheit im Vorfeld kontrollieren und die Gefahr eines Sicherheitsverstoßes verringern.\n Gestalte die CI/CD-Konfiguration nicht zu kompliziert und versuche nicht, alle Funktionsvorteile gleichzeitig zu nutzen. Modularisiere den Code und implementiere ihn in kleinen Iterationen.\n* Implementiere Funktionen zur Überwachung und Steuerung von Anfang an.\n* Bedenke, dass sich ein GitLab Runner (Go) möglicherweise anders verhält als ein Jenkins-Agent (Java). Die CPU-Auslastung und der Speicherverbrauch können unterschiedlich sein – achte darauf, sie im Laufe der Zeit miteinander zu vergleichen.\n* Ziehe in Erwägung, in automatische Skalierungsmechanismen zu investieren, und lege nicht benötigte Ressourcen am Wochenende oder außerhalb der Arbeitszeiten still.\n* Modernisiere die Anwendungsentwicklung, indem du deine Jobs containerisierst. Jenkins-Jobs laufen aktuell nicht in einem Container, sondern auf einem Jenkins-Agenten, der als VM ausgeführt wird.\n\nDiese Liste ist nicht erschöpfend, stellt aber einen guten Ausgangspunkt für einige Überlegungen dar, die du beachten solltest. Wenn du zusätzliche Hilfe benötigst, bietet GitLab [Professional Services](https://about.gitlab.com/de-de/get-help/) an, um dich bei deiner Migration zu unterstützen.\n\n### Mehr erfahren\n\nVielen Dank, dass du diesen Leitfaden gelesen hast! Ich hoffe, dass er dir dabei geholfen hat, besser zu verstehen, warum und wie du von Jenkins zu GitLab migrieren kannst. Noch nicht überzeugt? [Melde dich für eine kostenlose Testversion von GitLab an](https://about.gitlab.com/de-de/free-trial/) und erkenne den Nutzen einer DevSecOps-Plattform!\n\nHier findest du einige englischsprachige Ressourcen mit weiteren Informationen zu GitLab, den Vorteilen einer DevSecOps-Plattform und der Migration aus Jenkins:\n\n* [Migration von Jenkins](https://docs.gitlab.com/ci/migration/jenkins/)\n* [Planung einer Migration](https://docs.gitlab.com/ci/migration/plan_a_migration/)\n* [GitLab-Projektimporter](https://docs.gitlab.com/user/project/import/)\n* [Tutorial: Einfache Migration von GitHub zu GitLab](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n* [Video: Einfache Migration von GitHub zu GitLab](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n* [Von Jenkins zu GitLab: Der ultimative Leitfaden zur Modernisierung deiner CI/CD-Umgebung](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)","devsecops",{"slug":13,"featured":14,"template":15},"jenkins-to-gitlab-migration-made-easy",true,"BlogPost",{"heroImage":17,"body":10,"authors":18,"updatedDate":19,"date":20,"title":5,"tags":21,"description":24,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg",[9],"2025-02-13","2024-02-01",[22,23],"CI/CD","DevSecOps","In diesem Schritt-für-Schritt-Leitfaden erfährst du, warum und wie du ganz einfach von Jenkins zu GitLab migrieren kannst.","yml",null,{},"/de-de/blog/jenkins-to-gitlab-migration-made-easy","seo:\n ogTitle: Migration von Jenkins zu GitLab leicht gemacht\n ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg\n ogDescription: In diesem Schritt-für-Schritt-Leitfaden erfährst du, warum und\n wie du ganz einfach von Jenkins zu GitLab migrieren kannst.\n ogSiteName: https://about.gitlab.com\n noIndex: false\n ogType: article\n ogUrl: https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy\n title: Migration von Jenkins zu GitLab leicht gemacht\n canonicalUrls: https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy\n description: In diesem Schritt-für-Schritt-Leitfaden erfährst du, warum und wie\n du ganz einfach von Jenkins zu GitLab migrieren kannst.\ncontent:\n heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg\n body: >-\n GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Das bedeutet,\n dass GitLab alles bietet, was du benötigst, um sichere Software schneller zu\n planen, zu entwickeln und bereitzustellen – alles in einem Tool.\n\n\n Plattformen vereinfachen die Integration verschiedener Tools (DIY-DevOps),\n um den Software-Entwicklungsprozess (SDLC) zu unterstützen. Da Jenkins keine\n Plattform ist, sind zusätzliche Tools erforderlich, um den\n Software-Entwicklungsprozess zu vervollständigen. Dieser DIY-DevOps-Ansatz\n erhöht die Komplexität der Toolchain, was die folgenden Nachteile mit sich\n bringt:\n\n\n * Bedarf an individuellem Support für die Integration und Orchestrierung von\n Tools\n\n * Schwierigkeiten bei der Wartung/Aktualisierung/Sicherung separater Tools\n\n * Ineffizienz bei der Evaluierung der Unternehmenstransformation\n\n * Schlechte Entwicklererfahrung\n\n * Zusätzliche Management-/Zeit-/Budgetkosten\n\n * Produktivitätsverlust\n\n * Ineffizienz im Hinblick auf Kontextwechsel und Zusammenarbeit\n\n\n ![Import project\n selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png\n \"DIY-DevOps im Vergleich zu einer DevSecOps-Plattform\")\n\n\n Aus diesen Gründen erwägen viele Jenkins-Teams, zu einer DevSecOps-Plattform\n zu migrieren. Wer nach einer leistungsfähigeren, zuverlässigeren und\n sichereren Lösung sucht, sollte GitLab wählen! GitLab ist kostenlos für\n Einsteiger(innen) und bietet verschiedene Abonnementstufen, je nachdem,\n welche Anforderungen dein Unternehmen hat. Weitere Informationen zu unseren\n Angeboten und Funktionen findest du auf unserer\n [Preisseite](https://about.gitlab.com/de-de/pricing/).\n\n\n In diesem Blog erfährst du:\n\n\n * wie du eine Migration planst\n\n * wie du Repositories von anderen Tools für die Quellcodeverwaltung (SCM) zu\n GitLab migrierst\n\n * wie du CI/CD-Pipelines von Jenkins zu GitLab migrierst\n\n * welche weiteren Überlegungen du dir zu Migrationen machen solltest\n\n\n ### Planung einer Migration\n\n\n Bevor du eine Migration von einem anderen Tool zu GitLab CI/CD startest,\n solltest du zunächst einen Migrationsplan erstellen. Ein Migrationsplan ist\n ein wichtiger technischer Schritt, um Erwartungen festzulegen. CI/CD-Tools\n unterscheiden sich im Hinblick auf ihren Ansatz und Aufbau sowie ihre\n technischen Besonderheiten. Das bedeutet, dass Migrationen keine simplen,\n direkten Zuordnungen von Daten sind. Ein Migrationsplan bietet folgende\n Vorteile:\n\n\n * Er legt eine klare Vorstellung deiner Migrationsziele fest und\n kommuniziert sie. Dies hilft deinen Benutzer(innen) dabei, zu verstehen,\n warum sich der Aufwand lohnt. Der Nutzen wird deutlich, wenn die Migration\n abgeschlossen ist, aber die Beteiligten müssen sich dessen auch während der\n Migration bewusst sein.\n\n * Er ermöglicht die Unterstützung und Beteiligung der entsprechenden\n Führungsteams – dies trägt zum oben genannten Punkt bei.\n\n * Er bietet die Gelegenheit, Benutzer(innen) über Veränderungen aufzuklären.\n\n * Er findet Wege, um Teile der Migration zu sequenzieren oder zu verzögern\n und zu verhindern, dass nicht migrierte (oder teilweise migrierte) Zustände\n zu lange bestehen bleiben.\n\n * Er dokumentiert die Vorteile der Verbesserungen, die GitLab CI/CD bietet,\n und aktualisiert deine Implementierung im Rahmen der Umstellung.\n\n\n Mit einem Migrationsplan kannst du einen Prozess einrichten, bei dem du mit\n minimalen Unterbrechungen langsam zu GitLab migrieren kannst. Dies kann\n bedeuten, dass Jenkins und GitLab parallel eingesetzt werden, während\n bestimmte Projekte zu GitLab verschoben und von Jenkins abgezogen werden.\n\n\n ### Definition eines Change-Management-Prozesses\n\n\n Der Migrationsplan sollte einen effektiven Change-Management-Prozess\n definieren. Entwicklungs- und IT Operations-Teams,\n Cloud-Administrator(inn)en sowie Sicherheits- und Qualitätsteams haben\n möglicherweise keine Erfahrung mit GitLab und sie wissen möglicherweise\n nicht, warum du oder deine Führungskraft sich entschieden haben, diesen Weg\n einzuschlagen.\n\n\n Wer von den Veränderungen betroffen ist, muss Folgendes wissen:\n\n\n * **Warum** die Veränderung vorgenommen wird\n\n * **Wie** der zukünftige Zustand aussehen wird\n\n * **Wie** das Unternehmen den neuen Zustand erreichen möchte\n\n * **Wo** weitere Informationen oder Unterstützung zu finden sind\n\n\n Zu diesem Zweck solltest du die folgenden Schritte in Erwägung ziehen, um\n Veränderungen für diese funktionalen Rollen zu steuern:\n\n\n * **Analysiere den aktuellen Zustand**: Dokumentiere den aktuellen Zustand\n der Prozesse. Sammle Indikatoren als Basis. Ermittle, was im Hinblick auf\n CI/CD funktioniert und was nicht, indem du wichtige Teammitglieder befragst.\n Dokumentiere die Herausforderungen, die du feststellst, sowohl in\n quantitativer als auch in qualitativer Hinsicht. Du musst andere von der\n Vision und dem Grund für die Veränderung überzeugen. Je klarer du also die\n Problemstellung definieren kannst, desto einfacher wird es, die Zustimmung\n des gesamten Unternehmens zu gewinnen.\n\n * **Baue eine Vision auf**: Nun, da du die aktuellen Probleme quantitativ\n mithilfe von Basisindikatoren und qualitativ (mit den Worten deiner\n Teammitglieder) beschrieben hast, stelle eine Vision des zukünftigen\n Zustands vor. Erläutere, warum dies wichtig ist (stelle einen Zusammenhang\n zu geschäftlichen Erfolgsindikatoren her). Biete Live- sowie aufgezeichnete\n Demos an, um aufzuzeigen, welche Möglichkeiten es gibt, und vergleiche diese\n Vision mit dem aktuellen Zustand. Betone diese Botschaft auf mehreren Kanäle\n und in verschiedenen Medien – Chat-Gruppen, allgemeine Meetings,\n E-Mail-Benachrichtigungen, Banner-Benachrichtigungen auf GitLab usw.\n\n * **Kläre die Belegschaft auf**: Investiere in [GitLab-CI/CD-Schulungen (nur\n in englischer Sprache\n verfügbar)](https://university.gitlab.com/pages/ci-cd-training/), die von\n GitLab-Expert(inn)en durchgeführt werden. Evaluiere den Erwerb und das\n Verinnerlichen von Kenntnissen mithilfe von [GitLab-Zertifizierungen (nur in\n englischer Sprache\n verfügbar)](https://levelup.gitlab.com/pages/certifications).\n\n * **Kommuniziere Roadmap und Ressourcen**: Teile deinen Teammitgliedern den\n geplanten Zeitplan sowie die verfügbaren Ressourcen für die Migration mit.\n Nenne Community-Ressourcen wie Chat-Gruppen, Q&A-Boards oder die\n Kontaktzeiten von GitLab-Influencern oder -Influencerinnen, damit dein Team\n Fragen stellen und Unterstützung erhalten kann. Der Aufbau eines\n Belohnungssystems, das das Teams dazu anregt, frühzeitig umzusteigen und\n ihre Erfahrungen mit anderen Anwendergruppen zu teilen, wäre ein Pluspunkt!\n\n\n Wenn du diese Elemente zu Beginn der Migration sicherstellst, stellst du die\n Weichen für ihren Erfolg.\n\n\n ### Festlegung von Migrationszielen\n\n\n Bevor du eine Migration durchführst, solltest du dir über deine Ziele im\n Klaren sein und wissen, wie du sie erreichen kannst. Einige Fragen, auf die\n du Antworten haben solltest, sind beispielsweise folgende:\n\n\n * Was ist dein Zeitplan für die Migration?\n\n * Wie ist dein Jenkins-Server aktuell konfiguriert?\n\n * Wie viele Projekte müssen migriert werden?\n\n * Wie komplex ist deine Pipeline?\n\n * Gibt es externe Abhängigkeiten, mehrere Pipeline-Trigger, parallele Builds\n usw.?\n\n * Wie/wo stellst du deinen Code bereit?\n\n * Was ist der Veröffentlichungs-/Überprüfungsprozess für die Bereitstellung\n von Code?\n\n * Ist der Workflow in Jenkins integriert oder gibt es einen separaten\n Workflow, der von Jenkins ausgelöst wird?\n\n * Welche Build-Artefakte oder Binärdateien sind für den Erfolg der Pipeline\n erforderlich?\n\n * Welche Plugins verwenden Jobs in Jenkins derzeit?\n\n * Welche Software ist auf den Jenkins-Agenten installiert?\n\n * Welche Lösung für die Quellcodeverwaltung verwendest du aktuell?\n\n * Verwenden deine Jenkins-Jobs gemeinsam genutzte Bibliotheken?\n\n * Welche Authentifizierungsmethode kommt für Jenkins zum Einsatz (Basic\n Authentication, LDAP/AD, SSO)?\n\n * Gibt es andere Projekte, auf die du von deiner Pipeline aus zugreifen\n musst?\n\n * Gibt es Zugangsdaten in Jenkins, die für den Zugriff auf externe Dienste\n verwendet werden?\n\n\n Wenn du diese Fragen beantwortest, weißt du, wie du bei der Migration\n vorgehen solltest, wie lange sie dauert und wo du anfangen solltest. Wenn du\n einen Plan erstellt hast und dir die Erwartungen und möglichen Fallstricke\n bewusst sind, kannst du mit dem Migrationsprozess beginnen.\n\n\n ### Voraussetzungen für die Migration\n\n\n Sobald du einen Migrationsplan erstellt und alle Erwartungen an die\n Migration bedacht hast, kannst du mit der Einrichtung von GitLab beginnen.\n Hier sind einige empfohlene Voraussetzungen für die Migration:\n\n\n * Mache dich mit GitLab vertraut. Informiere dich über die [wichtigsten\n GitLab CI/CD-Funktionen (nur in englischer Sprache\n verfügbar)](https://docs.gitlab.com/ci/).\n\n * Folge den englichsprachigen Tutorials, um deine erste\n [GitLab-Pipeline](https://docs.gitlab.com/ci/quick_start/) und\n [komplexere\n Pipelines](https://docs.gitlab.com/ci/quick_start/tutorial/) zu\n generieren, die eine statische Website erstellen, testen und bereitstellen.\n\n * Lies die [Keyword-Referenz für .gitlab-ci.yml (nur in englischer Sprache\n verfügbar)](https://docs.gitlab.com/ci/yaml/).\n\n * Richte GitLab ein und konfiguriere es.\n\n * Teste deine GitLab-Instanz.\n\n\n Sobald du mit GitLab vertraut bist und eine Instanz konfiguriert hast,\n kannst du deinem Migrationsplan folgen und damit beginnen, Projekte von\n Jenkins zu GitLab zu verschieben. Stelle sicher, dass deine GitLab-Instanz\n mithilfe von bewährten Methoden für GitLab und gemäß [Referenzarchitekturen\n (nur in englischer Sprache\n verfügbar)](https://docs.gitlab.com/administration/reference_architectures/)\n ordnungsgemäß eingerichtet wurde.\n\n\n ### Migration von Repositories zu GitLab\n\n\n Einer der wichtigsten Nachteile von Jenkins ist, dass es keine Lösung für\n die Quellcodeverwaltung (SCM, Source Code Management) bietet. Wenn du\n Jenkins verwendest, muss dein Code in einer separaten SCM-Lösung gespeichert\n werden, auf die Jenkins Zugriff haben muss. Da GitLab über eine integrierte\n Quellcodeverwaltung verfügt, ermöglicht der Umstieg von Jenkins auch die\n Migration der zuvor genutzten SCM-Lösung. Dies verringert die Kosten\n zusätzlich.\n\n\n GitLab bietet Tools, mit denen du dein Repository und seine Metadaten\n einfach zu GitLab verschieben kannst. Die folgenden Importer (nur in\n englischer Sprache verfügbar) unterstützen dich bei der Migration deiner\n Projekte zu GitLab:\n\n\n * [GitHub](https://docs.gitlab.com/user/project/import/github/)\n\n * [Eine weitere\n GitLab-Instanz](https://docs.gitlab.com/user/project/settings/import_export/)\n\n * [Bitbucket\n Cloud](https://docs.gitlab.com/user/project/import/bitbucket/)\n\n * [Bitbucket\n Server](https://docs.gitlab.com/user/project/import/bitbucket_server/)\n\n * [FogBugz](https://docs.gitlab.com/user/project/import/fogbugz/)\n\n * [Gitea](https://docs.gitlab.com/user/project/import/gitea/)\n\n * [Jira (nur\n Issues)](https://docs.gitlab.com/user/project/import/jira/)\n – [Repo per Manifestdatei](https://docs.gitlab.com/user/project/import/manifest/)\n * [Repo per\n URL](https://docs.gitlab.com/user/project/import/repo_by_url/)\n\n\n\n ![GitHub to GitLab Repo\n Exporter](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png\n \"Repoitory-Exporter von GitHub zu GitLab\")\n\n\n \u003Cp>\u003C/p>\n\n\n Jeder Importer importiert unterschiedliche Daten aus einem Projekt. Lies die\n [Dokumentation zum Import und zur Migration von Projekten (nur in englischer\n Sprache verfügbar)](https://docs.gitlab.com/user/project/import/), um\n mehr Informationen über die bereitgestellten Importer zu erhalten und zu\n erfahren, welche Daten zu GitLab migriert werden. Darüber hinaus kannst du\n [den Import von Gruppen und Projekten automatisieren (nur in englischer\n Sprache\n verfügbar)](https://docs.gitlab.com/user/project/import/#automate-group-and-project-import)\n und eine benutzerdefinierte Lösung erstellen, welche die Anforderungen\n deines Unternehmens noch besser erfüllt:\n\n\n * [Professional Services](https://about.gitlab.com/de-de/services/)\n\n *\n [Migrations-Tools](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n\n * [Häufig gestellte Fragen zur\n Migration](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n\n ### So migrierst du ein Repository\n\n\n Mit unseren integrierten Importern kannst du Repositories ganz einfach zu\n GitLab migrieren. In diesem Beispiel erfährst du, wie du ein Repo zusammen\n mit [seinen Ressourcen (nur in englischer Sprache\n verfügbar)](https://docs.gitlab.com/user/project/import/github/#imported-data)\n (Tickets, Pull Requests, Meilensteine usw.) aus GitHub zu GitLab kopierst.\n Um ein Repository aus einem anderen GitHub zu GitLab zu migrieren, führe die\n folgenden Schritte aus:\n\n\n 1. Wähle oben in der linken Menüleiste **Neu erstellen (+)** aus.\n\n 2. Wähle im Abschnitt „In GitLab“ **Neues Projekt/Repository** aus.\n\n\n 3. Wähle **Projekt importieren** aus.\n\n\n\n ![Import project\n selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png\n \"Auswahl des zu importierenden Projekts\")\n\n\n \u003Cp>\u003C/p>\n\n\n 4. Klicke auf die Schaltfläche **GitHub**.\n\n * Wenn du GitLab Self-Managed verwendest, musst du [den GitHub-Importer aktivieren (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/settings/import_and_export_settings/#configure-allowed-import-sources).\n * Beachte, dass andere Importer auf dieselbe Weise initiiert werden können.\n 5. Jetzt kannst du:\n\n * dich mit GitHub OAuth autorisieren: Wähle **Mit GitHub autorisieren** aus.\n * einen persönlichen GitHub-Zugriffstoken verwenden:\n\n * Gehe zu \u003Chttps://github.com/settings/tokens/new>.\n * Gib im Feld **Notizen** eine Token-Beschreibung ein.\n * Wähle den Geltungsbereich für das Repository aus.\n * Um Beteiligte zu importieren, wähle optional den Geltungsbereich **read:org** aus.\n * Klicke auf die Schaltfläche **Token generieren**.\n * Füge auf der GitLab-Importseite im Feld „Persönlicher Zugriffstoken“ den persönlichen GitHub-Zugriffstoken ein.\n 6. Klicke auf die Schaltfläche **Authentifizieren**.\n\n 7. Wähle die Elemente aus, die du migrieren möchtest.\n\n 8. Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie\n migrieren möchtest.\n\n 9. Klicke auf die Schaltfläche **Importieren**.\n\n\n Nun sollte sich das importierte Projekt in deinem Arbeitsbereich befinden.\n Weitere Informationen über die Migration von GitHub zu GitLab findest du in\n diesem englischsprachigen Video:\n\n\n \u003C!-- blank line -->\n\n\n \u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n \u003C/figure>\n\n \u003C!-- blank line -->\n\n\n Sobald du die Migration des Repositories abgeschlossen hast, kannst du deine\n Jenkins-Pipeline so einstellen, dass sie die Jenkins-Datei in GitLab nutzt.\n Lege dazu die Repository-URL für dein neu importiertes Projekt über das\n Jenkin-Pipeline-Konfigurationsmenü fest:\n\n\n\n ![Jenkins Pipeline SCM\n settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png\n \"SCM-Einstellungen für die Jenkins-Pipeline\")\n\n\n \u003Cp>\u003C/p>\n\n\n Dies ist nützlich für die anfängliche Repo-Migrationsphase und hilft dir\n dabei, sowohl Jenkins als auch GitLab parallel zu verwenden. So kannst du\n Dienstunterbrechungen vermeiden, während du die CI/CD-Funktionalität\n migrierst.\n\n\n Darüber hinaus kannst du das\n [GitLab-Jenkins-Plugin](https://plugins.jenkins.io/gitlab-plugin/) als\n Hilfestellung bei der Migration nutzen. Mit diesem Plugin kann GitLab den\n Status von Jenkins-Builds auslösen und abrufen.\n\n\n ### Migration von CI/CD-Pipelines\n\n\n Sobald du deine Repositories zu GitLab migriert hast, kannst du mit der\n Migration deiner Jenkins-Pipelines zu GitLab fortfahren. Dieser Prozess kann\n relativ simpel sein, du solltest dazu jedoch die Konzepte und die Syntax von\n Jenkins und GitLab verstehen.\n\n\n Jenkins bietet zwei verschiedene Arten von Syntax für die Definition von\n Pipelines: Declarative und Scripted. Dieser Leitfaden behandelt die\n Migration von Pipelines des Typs Declarative, da diese am häufigsten\n vorkommen.\n\n\n ### Schritt-für-Schritt-Migration der Pipeline\n\n\n In diesem Tutorial wird eine Jenkins-Datei (Groovy) im Vergleich zu einer\n GitLab-CI/CD-Konfigurationsdatei (YAML) analysiert, die einen in Golang\n geschriebenen Microservice generiert, testet und bereitstellt. Anschließend\n werden die Pipeline in GitLab aktiviert und die Ergebnisse angezeigt. Die\n Pipeline wird:\n\n\n * das Golang-Container-Image mit dem Tag **alpine** verwenden,\n\n * einen Job zur Erstellung des Golang-Codes in einer ausführbaren Binärdatei\n ausführen,\n\n * die erstellte ausführbare Datei als Artefakt speichern,\n * einen Job ausführen, um Unit-Tests durchzuführen,\n\n * einen Jobs zur Bereitstellung im Staging ausführen.\n\n * Dieser wird nur ausgeführt, wenn der Commit auf den Branch **Staging** abzielt,\n * beginnt, nachdem die Phase **Test** erfolgreich abgeschlossen wurde,\n * verwendet das erstellte ausführbare Artefakt aus dem vorherigen Job.\n\n Unten findest du die Pipeline-Definitionen aus Jenkins und GitLab sowie\n beschreibende Kommentare. Im\n [Meow-Migrationsprojekt](https://gitlab.com/gitlab-da/projects/blogs/meow-migration)\n kannst du die Pipeline in Aktion sehen.\n\n\n Schaue dir eine in Groovy geschriebene Jenkins-Datei an:\n\n\n ```shell\n\n // Die höchste Ebene der Declarative-\n\n // Pipeline.\n\n pipeline {\n\n // Definiert den zu verwendenden Standard-Agenten,\n // sofern nicht explizit in einem Job\n // definiert.\n agent any\n\n // Definiert die Staging-Phasen, die in\n // numerischer Reihenfolge ausgeführt werden. Jede Staging-Phase\n // führt nur einen Job aus.\n stages {\n\n // Definiert den Namen der Staging-Phase.\n stage('build') {\n // Definiert das Container-Image,\n // das für diesen Job verwendet werden soll. Dies überschreibt\n // die Standardeinstellung 'agent any'.\n // Das Jenkins-Docker-Plugin\n // muss konfiguriert sein, damit dies\n // ausgeführt wird.\n agent { docker 'golang:alpine' }\n\n // Definiert die Abfolge von Schritten,\n // die bei der Ausführung der Staging-Phase\n // befolgt werden soll.\n steps {\n sh 'go build -o bin/meow-micro'\n sh 'chmod +x bin/meow-micro'\n }\n\n // Die Schritte, die nach Abschluss der\n // Staging-Phase ausgeführt werden sollen.\n post {\n always {\n\n // Speichert die Artefakte der Staging-Phase,\n // die zur Verwendung in einem anderen Job\n // generiert wurden.\n archiveArtifacts artifacts: 'bin/meow-micro'\n onlyIfSuccessful: true\n }\n }\n }\n\n stage('test') {\n agent { docker 'golang:alpine' }\n steps {\n sh 'go test .'\n }\n }\n\n stage('deploy') {\n // Definiert die Bedingungen,\n // die zur Ausführung des Jobs\n // erfüllt sein müssen. In diesem Fall wird der\n // Bereitstellungs-Job nur auf dem\n // Staging-Branch ausgeführt.\n when {\n branch 'staging'\n }\n steps {\n echo 'Deploying meow-micro to staging'\n // Verwendet das Artefakt, das in der\n // Build-Staging-Phase gespeichert wurde.\n sh './bin/meow-micro'\n }\n }\n }\n }\n\n ```\n\n\n Schaue dir nun an, wie die gleiche Funktion in GitLab erstellt werden kann:\n\n\n ```text\n\n # Definiert das zu verwendende Standard-Image,\n\n # sofern nicht explizit in einem Job\n\n # angegeben.\n\n default:\n image: alpine:latest\n\n # Definiert die Reihenfolge der auszuführenden Staging-Phasen.\n\n # Jede Staging-Phase kann mehrere Jobs umfassen.\n\n stages:\n - build\n - test\n - deploy\n\n # Definiert den Namen des Jobs.\n\n create-binary:\n # Definiert die Staging-Phase, in welcher der Job ausgeführt wird.\n stage: build\n # Definiert das Container-Image, das für\n # diesen Job verwendet werden soll. Dies überschreibt die Standardeinstellung.\n image: golang:alpine\n # Definiert die Reihenfolge der Schritte,\n # die bei der Ausführung des Jobs befolgt werden sollen.\n script:\n - go build -o bin/meow-micro\n - chmod +x bin/meow-micro\n # Speichert die Job-Artefakte, die zur\n # Verwendung in einem anderen Job gespeichert wurden.\n artifacts:\n paths:\n - bin/meow-micro\n expire_in: 1 week\n\n unit-tests:\n stage: test\n image: golang:alpine\n script:\n - go test .\n # Definiert Befehle, die im Anschluss an den Job\n # ausgeführt werden sollen.\n after_script:\n - echo \"Tests Complete\"\n\n staging-deploy:\n stage: deploy\n # Definiert die Befehle, die vor dem\n # eigentlichen Job ausgeführt werden sollen.\n before_script:\n - apk update\n script:\n - echo \"Deploying meow-micro to staging environment\"\n - ./bin/meow-micro\n # Definiert die Bedingungen, die zur\n # Ausführung dieses Jobs erfüllt sein müssen. In\n # diesem Fall wird der Bereitstellungs-Job der Staging-Phase nur\n # auf dem Staging-Branch ausgeführt.\n rules:\n - if: $CI_COMMIT_BRANCH == 'staging'\n # Erlaubt die Verwendung der Artefakte, die im\n # Build-Job gespeichert wurden, in diesem Job.\n artifacts:\n paths:\n - bin/meow-micro\n ```\n\n\n Wie du vielleicht bemerkt hast, gibt es viele Gemeinsamkeiten zwischen\n Jenkins und GitLab im Hinblick auf die Syntax. Dies vereinfacht die\n Pipeline-Migration. Sieh dir die umfassende Liste der [Funktions- und\n Konzeptvergleiche (nur in englischer Sprache\n verfügbar)](https://docs.gitlab.com/ci/migration/jenkins/#comparison-of-features-and-concepts)\n zwischen den beiden Tools an.\n\n\n Nun, da du verstehst, wie man Jenkins in GitLab abbildet, kannst du damit\n beginnen, eine Pipeline mit der gleichen Funktionalität in GitLab zu\n erstellen. Um CI/CD zu migrieren, kannst du die folgenden Schritte\n ausführen:\n\n\n ##### 1. Öffne das Repository, das du im obigen Abschnitt zu GitLab migriert\n hast.\n\n\n * Klicke oben in der linken Seitenleiste auf **Suchen oder aufrufen …**.\n\n * Wähle dein Projekt aus.\n\n\n ##### 2. Öffne den [Pipeline-Editor (nur in englischer Sprache\n verfügbar)](https://docs.gitlab.com/ci/pipeline_editor/).\n\n\n * Wähle in der linken Seitenleiste **Build > Pipeline-Editor** aus.\n\n * Klicke auf die Schaltfläche **Pipeline konfigurieren**.\n\n\n\n ![Configure pipeline\n selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png\n \"Auswahl der Schaltfläche „Pipeline konfigurieren“\")\n\n\n \u003Cp>\u003C/p>\n\n\n ##### 3. Befülle die Datei [.gitlab-ci.yml (nur in englischer Sprache\n verfügbar)](https://docs.gitlab.com/ci/yaml/).\n\n\n * Füge den GitLab-CI-Pipeline-Code hinzu.\n\n * Prüfe, ob die Syntax korrekt ist.\n\n\n\n ![Pipeline syntax\n validation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png\n \"Validierung der Pipeline-Syntax\")\n\n\n \u003Cp>\u003C/p>\n\n\n * Visualisiere die Pipeline.\n\n\n\n ![Pipeline\n visualization](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png\n \"Visualisierung der Pipeline\")\n\n\n \u003Cp>\u003C/p>\n\n\n ##### 4. Committe die Datei in den Main-Branch.\n\n\n * Füge eine Commit-Nachricht hinzu.\n\n * Stelle sicher, dass es sich um den Main-Branch handelt.\n\n * Klicke auf die Schaltfläche **Änderungen committen**.\n\n\n\n ![Commit changes\n dialog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png\n \"Dialog „Änderungen committen“\")\n\n\n \u003Cp>\u003C/p>\n\n\n Sobald die Datei zusammengeführt wurde, wird die definierte Pipeline\n gestartet. Du kannst zu deinem Projekt zurückkehren und [die Pipeline\n anzeigen (nur in englischer Sprache\n verfügbar)](https://docs.gitlab.com/ci/pipelines/#view-pipelines), indem\n du sie auf der Seite deines Projekts **Build > Pipelines** auswählst. Da sie\n auf dem **Main**-Branch ausgeführt wurde, siehst du nur den Job\n **create-binary** sowie die „unit-test“ Jobs. Der Job **staging-deploy**\n wird nur auf dem Staging-Branch ausgeführt.\n\n\n\n ![Pipeline running on main\n branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png\n \"Auf dem Main-Branch ausgeführte Pipeline\")\n\n\n \u003Cp>\u003C/p>\n\n\n Bei der Erstellung eines Staging-Branches wird die folgende Pipeline\n gestartet.\n\n\n\n ![Pipeline running on staging\n branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png\n \"Auf dem Staging-Branch ausgeführte Pipeline\")\n\n\n \u003Cp>\u003C/p>\n\n\n Wenn du auf einen Job klickst, wird dessen Ausgabe angezeigt:\n\n\n\n ![create-binary job\n output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png\n \"Ausgabe des Jobs create-binary\")\n\n\n \u003Cp>\u003C/p>\n\n\n\n ![unit-tests job output\n input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png\n \"Eingabe/Ausgabe des Jobs unit-tests\")\n\n\n \u003Cp>\u003C/p>\n\n\n\n ![staging-deploy job\n output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png\n \"Ausgabe des Jobs staging-deploy\")\n\n\n \u003Cp>\u003C/p>\n\n\n Du kannst sehen, wie das Artefakt im Job create-binary gespeichert und im\n Job staging-deploy verwendet wird. Und so einfach ist es, eine Pipeline von\n Jenkins zu GitLab zu migrieren!\n\n\n ### Zusätzliche Überlegungen zur Migration\n\n\n Einige hilfreiche Überlegungen, die den Bereitstellungsprozess unserer\n Ansicht nach einfacher machen, sind folgende:\n\n\n * Versuche nicht, Aufgaben exakt als GitLab-Jobs zu replizieren. Nimm dir\n Zeit und schaue dir genauer an, was die aktuelle Pipeline bewirkt und\n welches Problem sie löst.\n\n * Einige Jenkins-Jobs sind möglicherweise zu komplex, um sofort zu GitLab\n migriert zu werden. Deshalb kann es von Vorteil sein, das\n [GitLab-Jenkins-Plugin](https://plugins.jenkins.io/gitlab-plugin/) zu\n verwenden, um Jenkins-Pipelines zu starten und ihre Ergebnisse direkt in\n GitLab anzuzeigen. Auf diese Weise kannst du bestimmte Aktionen langsam zu\n GitLab migrieren, bis die gesamte Pipeline verschoben werden kann.\n\n * Implementiere [Sicherheitsscanner und Codequalität (nur in englischer\n Sprache verfügbar)](https://docs.gitlab.com/user/application_security/)\n mithilfe von integrierten Vorlagen, die GitLab von Anfang an bereitstellt.\n So kannst du die Sicherheit im Vorfeld kontrollieren und die Gefahr eines\n Sicherheitsverstoßes verringern.\n Gestalte die CI/CD-Konfiguration nicht zu kompliziert und versuche nicht, alle Funktionsvorteile gleichzeitig zu nutzen. Modularisiere den Code und implementiere ihn in kleinen Iterationen.\n * Implementiere Funktionen zur Überwachung und Steuerung von Anfang an.\n\n * Bedenke, dass sich ein GitLab Runner (Go) möglicherweise anders verhält\n als ein Jenkins-Agent (Java). Die CPU-Auslastung und der Speicherverbrauch\n können unterschiedlich sein – achte darauf, sie im Laufe der Zeit\n miteinander zu vergleichen.\n\n * Ziehe in Erwägung, in automatische Skalierungsmechanismen zu investieren,\n und lege nicht benötigte Ressourcen am Wochenende oder außerhalb der\n Arbeitszeiten still.\n\n * Modernisiere die Anwendungsentwicklung, indem du deine Jobs\n containerisierst. Jenkins-Jobs laufen aktuell nicht in einem Container,\n sondern auf einem Jenkins-Agenten, der als VM ausgeführt wird.\n\n\n Diese Liste ist nicht erschöpfend, stellt aber einen guten Ausgangspunkt für\n einige Überlegungen dar, die du beachten solltest. Wenn du zusätzliche Hilfe\n benötigst, bietet GitLab [Professional\n Services](https://about.gitlab.com/de-de/get-help/) an, um dich bei deiner\n Migration zu unterstützen.\n\n\n ### Mehr erfahren\n\n\n Vielen Dank, dass du diesen Leitfaden gelesen hast! Ich hoffe, dass er dir\n dabei geholfen hat, besser zu verstehen, warum und wie du von Jenkins zu\n GitLab migrieren kannst. Noch nicht überzeugt? [Melde dich für eine\n kostenlose Testversion von GitLab\n an](https://about.gitlab.com/de-de/free-trial/) und erkenne den Nutzen einer\n DevSecOps-Plattform!\n\n\n Hier findest du einige englischsprachige Ressourcen mit weiteren\n Informationen zu GitLab, den Vorteilen einer DevSecOps-Plattform und der\n Migration aus Jenkins:\n\n\n * [Migration von\n Jenkins](https://docs.gitlab.com/ci/migration/jenkins/)\n\n * [Planung einer\n Migration](https://docs.gitlab.com/ci/migration/plan_a_migration/)\n\n * [GitLab-Projektimporter](https://docs.gitlab.com/user/project/import/)\n\n * [Tutorial: Einfache Migration von GitHub zu\n GitLab](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n\n * [Video: Einfache Migration von GitHub zu\n GitLab](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n\n * [Von Jenkins zu GitLab: Der ultimative Leitfaden zur Modernisierung deiner\n CI/CD-Umgebung](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n authors:\n - Fernando Diaz\n updatedDate: 2025-02-13\n date: 2024-02-01\n title: Migration von Jenkins zu GitLab leicht gemacht\n tags:\n - CI/CD\n - DevSecOps\n description: In diesem Schritt-für-Schritt-Leitfaden erfährst du, warum und wie\n du ganz einfach von Jenkins zu GitLab migrieren kannst.\n category: devsecops\nconfig:\n slug: jenkins-to-gitlab-migration-made-easy\n featured: true\n template: BlogPost\n",{"ogTitle":5,"ogImage":17,"ogDescription":24,"ogSiteName":31,"noIndex":32,"ogType":33,"ogUrl":34,"title":5,"canonicalUrls":34,"description":24},"https://about.gitlab.com",false,"article","https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy","de-de/blog/jenkins-to-gitlab-migration-made-easy",[37,11],"cicd",[22,23],"1qPUQql3VgxI56R-IqliL1Vjv8CDYugRjzOaJzgWEcs",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":371,"minimal":405,"duo":423,"switchNav":432,"pricingDeployment":443},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/de-de/","gitlab logo","header",{"text":48,"config":49},"Kostenlose Testversion anfordern",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"Vertrieb kontaktieren",{"href":55,"dataGaName":56,"dataGaLocation":46},"/de-de/sales/","sales",{"text":58,"config":59},"Anmelden",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,186,191,292,352],{"text":64,"config":65,"cards":67},"Plattform",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":71,"config":72},"Die Plattform erkunden",{"href":73,"dataGaName":66,"dataGaLocation":46},"/de-de/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","Agentische KI für den gesamten Software-Lebenszyklus",{"text":78,"config":79},"Lerne GitLab Duo kennen",{"href":80,"dataGaName":81,"dataGaLocation":46},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"Warum GitLab?","Erfahre, warum sich Unternehmen für GitLab entscheiden",{"text":86,"config":87},"Mehr erfahren",{"href":88,"dataGaName":89,"dataGaLocation":46},"/de-de/why-gitlab/","why gitlab",{"text":91,"left":14,"config":92,"link":94,"lists":98,"footer":168},"Produkt",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Alle Lösungen anzeigen",{"href":97,"dataGaName":93,"dataGaLocation":46},"/de-de/solutions/",[99,123,146],{"title":100,"description":101,"link":102,"items":107},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[108,111,114,119],{"text":22,"config":109},{"href":110,"dataGaLocation":46,"dataGaName":22},"/de-de/solutions/continuous-integration/",{"text":75,"config":112},{"href":80,"dataGaLocation":46,"dataGaName":113},"gitlab duo agent platform - product menu",{"text":115,"config":116},"Quellcodeverwaltung",{"href":117,"dataGaLocation":46,"dataGaName":118},"/de-de/solutions/source-code-management/","Source Code Management",{"text":120,"config":121},"Automatische Softwarebereitstellung",{"href":105,"dataGaLocation":46,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Sicherheit","Entwickle Code schneller ohne Abstriche bei der Sicherheit",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":46,"icon":130},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"Anwendungssicherheitstests",{"href":128,"dataGaName":135,"dataGaLocation":46},"Application security testing",{"text":137,"config":138},"Schutz der Software-Lieferkette",{"href":139,"dataGaLocation":46,"dataGaName":140},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Software-Compliance",{"href":144,"dataGaName":145,"dataGaLocation":46},"/de-de/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"Auswertung",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":46},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[154,158,163],{"text":155,"config":156},"Sichtbarkeit und Auswertung",{"href":151,"dataGaLocation":46,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Wertstrommanagement",{"href":161,"dataGaLocation":46,"dataGaName":162},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":164,"config":165},"Analysen und Einblicke",{"href":166,"dataGaLocation":46,"dataGaName":167},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":169,"items":170},"GitLab für",[171,176,181],{"text":172,"config":173},"Enterprise",{"href":174,"dataGaLocation":46,"dataGaName":175},"/de-de/enterprise/","enterprise",{"text":177,"config":178},"Kleinunternehmen",{"href":179,"dataGaLocation":46,"dataGaName":180},"/de-de/small-business/","small business",{"text":182,"config":183},"Öffentlicher Sektor",{"href":184,"dataGaLocation":46,"dataGaName":185},"/de-de/solutions/public-sector/","public sector",{"text":187,"config":188},"Preise",{"href":189,"dataGaName":190,"dataGaLocation":46,"dataNavLevelOne":190},"/de-de/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":279},"Ressourcen",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"Alle Ressourcen anzeigen",{"href":198,"dataGaName":194,"dataGaLocation":46},"/de-de/resources/",[200,233,251],{"title":201,"items":202},"Erste Schritte",[203,208,213,218,223,228],{"text":204,"config":205},"Installieren",{"href":206,"dataGaName":207,"dataGaLocation":46},"/de-de/install/","install",{"text":209,"config":210},"Kurzanleitungen",{"href":211,"dataGaName":212,"dataGaLocation":46},"/de-de/get-started/","quick setup checklists",{"text":214,"config":215},"Lernen",{"href":216,"dataGaLocation":46,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Produktdokumentation",{"href":221,"dataGaName":222,"dataGaLocation":46},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Best-Practice-Videos",{"href":226,"dataGaName":227,"dataGaLocation":46},"/de-de/getting-started-videos/","best practice videos",{"text":229,"config":230},"Integrationen",{"href":231,"dataGaName":232,"dataGaLocation":46},"/de-de/integrations/","integrations",{"title":234,"items":235},"Entdecken",[236,241,246],{"text":237,"config":238},"Kundenerfolge",{"href":239,"dataGaName":240,"dataGaLocation":46},"/de-de/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":46},"/de-de/blog/","blog",{"text":247,"config":248},"Remote",{"href":249,"dataGaName":250,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":252,"items":253},"Vernetzen",[254,259,264,269,274],{"text":255,"config":256},"GitLab Services",{"href":257,"dataGaName":258,"dataGaLocation":46},"/de-de/services/","services",{"text":260,"config":261},"Community",{"href":262,"dataGaName":263,"dataGaLocation":46},"/community/","community",{"text":265,"config":266},"Forum",{"href":267,"dataGaName":268,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":270,"config":271},"Veranstaltungen",{"href":272,"dataGaName":273,"dataGaLocation":46},"/events/","events",{"text":275,"config":276},"Partner",{"href":277,"dataGaName":278,"dataGaLocation":46},"/de-de/partners/","partners",{"background":280,"textColor":281,"text":282,"image":283,"link":287},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":284,"config":285},"The Source Promo-Karte",{"src":286},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":288,"config":289},"Aktuelles",{"href":290,"dataGaName":291,"dataGaLocation":46},"/de-de/the-source/","the source",{"text":293,"config":294,"lists":296},"Unternehmen",{"dataNavLevelOne":295},"company",[297],{"items":298},[299,304,310,312,317,322,327,332,337,342,347],{"text":300,"config":301},"Über",{"href":302,"dataGaName":303,"dataGaLocation":46},"/de-de/company/","about",{"text":305,"config":306,"footerGa":309},"Karriere",{"href":307,"dataGaName":308,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":308},{"text":270,"config":311},{"href":272,"dataGaName":273,"dataGaLocation":46},{"text":313,"config":314},"Geschäftsführung",{"href":315,"dataGaName":316,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":318,"config":319},"Team",{"href":320,"dataGaName":321,"dataGaLocation":46},"/company/team/","team",{"text":323,"config":324},"Handbuch",{"href":325,"dataGaName":326,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"Investor Relations",{"href":330,"dataGaName":331,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"Trust Center",{"href":335,"dataGaName":336,"dataGaLocation":46},"/de-de/security/","trust center",{"text":338,"config":339},"AI Transparency Center",{"href":340,"dataGaName":341,"dataGaLocation":46},"/de-de/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"Newsletter",{"href":345,"dataGaName":346,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"Presse",{"href":350,"dataGaName":351,"dataGaLocation":46},"/press/","press",{"text":353,"config":354,"lists":355},"Kontakt",{"dataNavLevelOne":295},[356],{"items":357},[358,361,366],{"text":53,"config":359},{"href":55,"dataGaName":360,"dataGaLocation":46},"talk to sales",{"text":362,"config":363},"Support-Portal",{"href":364,"dataGaName":365,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":367,"config":368},"Kundenportal",{"href":369,"dataGaName":370,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"Schließen",{"text":374,"link":375},"Um Repositorys und Projekte zu durchsuchen, melde dich an bei",{"text":376,"config":377},"gitlab.com",{"href":60,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"Vorschläge",[383,385,390,392,397,402],{"text":75,"config":384},{"href":80,"dataGaName":75,"dataGaLocation":379},{"text":386,"config":387},"Codevorschläge (KI)",{"href":388,"dataGaName":389,"dataGaLocation":379},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":22,"config":391},{"href":110,"dataGaName":22,"dataGaLocation":379},{"text":393,"config":394},"GitLab auf AWS",{"href":395,"dataGaName":396,"dataGaLocation":379},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":398,"config":399},"GitLab auf Google Cloud",{"href":400,"dataGaName":401,"dataGaLocation":379},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":83,"config":403},{"href":88,"dataGaName":404,"dataGaLocation":379},"Why GitLab?",{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Kostenlos testen",{"href":409,"dataGaName":51,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"GitLab-Symbol",{"src":414,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":201,"config":420},{"href":421,"dataGaName":422,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":424,"mobileIcon":428,"desktopIcon":430},{"text":425,"config":426},"Mehr über GitLab Duo erfahren",{"href":80,"dataGaName":427,"dataGaLocation":410},"gitlab duo",{"altText":412,"config":429},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":431},{"src":418,"dataGaName":415,"dataGaLocation":410},{"button":433,"mobileIcon":438,"desktopIcon":440},{"text":434,"config":435},"/Option",{"href":436,"dataGaName":437,"dataGaLocation":410},"#contact","switch",{"altText":412,"config":439},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":441},{"src":442,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":444,"mobileIcon":449,"desktopIcon":451},{"text":445,"config":446},"Zurück zur Preisübersicht",{"href":189,"dataGaName":447,"dataGaLocation":410,"icon":448},"back to pricing","GoBack",{"altText":412,"config":450},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":452},{"src":418,"dataGaName":415,"dataGaLocation":410},{"title":454,"button":455,"config":460},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":456,"config":457},"GitLab Transcend jetzt ansehen",{"href":458,"dataGaName":459,"dataGaLocation":46},"/de-de/events/transcend/virtual/","transcend event",{"layout":461,"icon":462,"disabled":14},"release","AiStar",{"data":464},{"text":465,"source":466,"edit":472,"contribute":477,"config":482,"items":487,"minimal":687},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":467,"config":468},"Quelltext der Seite anzeigen",{"href":469,"dataGaName":470,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":473,"config":474},"Diese Seite bearbeiten",{"href":475,"dataGaName":476,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":478,"config":479},"Beteilige dich",{"href":480,"dataGaName":481,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":483,"facebook":484,"youtube":485,"linkedin":486},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[488,533,583,625,652],{"title":187,"links":489,"subMenu":504},[490,494,499],{"text":491,"config":492},"Tarife anzeigen",{"href":189,"dataGaName":493,"dataGaLocation":471},"view plans",{"text":495,"config":496},"Vorteile von Premium",{"href":497,"dataGaName":498,"dataGaLocation":471},"/de-de/pricing/premium/","why premium",{"text":500,"config":501},"Vorteile von Ultimate",{"href":502,"dataGaName":503,"dataGaLocation":471},"/de-de/pricing/ultimate/","why ultimate",[505],{"title":353,"links":506},[507,509,511,513,518,523,528],{"text":53,"config":508},{"href":55,"dataGaName":56,"dataGaLocation":471},{"text":362,"config":510},{"href":364,"dataGaName":365,"dataGaLocation":471},{"text":367,"config":512},{"href":369,"dataGaName":370,"dataGaLocation":471},{"text":514,"config":515},"Status",{"href":516,"dataGaName":517,"dataGaLocation":471},"https://status.gitlab.com/","status",{"text":519,"config":520},"Nutzungsbedingungen",{"href":521,"dataGaName":522,"dataGaLocation":471},"/terms/","terms of use",{"text":524,"config":525},"Datenschutzerklärung",{"href":526,"dataGaName":527,"dataGaLocation":471},"/de-de/privacy/","privacy statement",{"text":529,"config":530},"Cookie-Einstellungen",{"dataGaName":531,"dataGaLocation":471,"id":532,"isOneTrustButton":14},"cookie preferences","ot-sdk-btn",{"title":91,"links":534,"subMenu":543},[535,539],{"text":536,"config":537},"DevSecOps-Plattform",{"href":73,"dataGaName":538,"dataGaLocation":471},"devsecops platform",{"text":540,"config":541},"KI-unterstützte Entwicklung",{"href":80,"dataGaName":542,"dataGaLocation":471},"ai-assisted development",[544],{"title":545,"links":546},"Themen",[547,550,555,560,565,568,573,578],{"text":22,"config":548},{"href":549,"dataGaName":37,"dataGaLocation":471},"/de-de/topics/ci-cd/",{"text":551,"config":552},"GitOps",{"href":553,"dataGaName":554,"dataGaLocation":471},"/de-de/topics/gitops/","gitops",{"text":556,"config":557},"DevOps",{"href":558,"dataGaName":559,"dataGaLocation":471},"/de-de/topics/devops/","devops",{"text":561,"config":562},"Versionskontrolle",{"href":563,"dataGaName":564,"dataGaLocation":471},"/de-de/topics/version-control/","version control",{"text":23,"config":566},{"href":567,"dataGaName":11,"dataGaLocation":471},"/de-de/topics/devsecops/",{"text":569,"config":570},"Cloud-nativ",{"href":571,"dataGaName":572,"dataGaLocation":471},"/de-de/topics/cloud-native/","cloud native",{"text":574,"config":575},"KI für das Programmieren",{"href":576,"dataGaName":577,"dataGaLocation":471},"/de-de/topics/devops/ai-for-coding/","ai for coding",{"text":579,"config":580},"Agentische KI",{"href":581,"dataGaName":582,"dataGaLocation":471},"/de-de/topics/agentic-ai/","agentic ai",{"title":584,"links":585},"Lösungen",[586,589,591,596,600,603,606,609,611,613,615,620],{"text":133,"config":587},{"href":128,"dataGaName":588,"dataGaLocation":471},"Application Security Testing",{"text":120,"config":590},{"href":105,"dataGaName":106,"dataGaLocation":471},{"text":592,"config":593},"Agile Entwicklung",{"href":594,"dataGaName":595,"dataGaLocation":471},"/de-de/solutions/agile-delivery/","agile delivery",{"text":597,"config":598},"SCM",{"href":117,"dataGaName":599,"dataGaLocation":471},"source code management",{"text":22,"config":601},{"href":110,"dataGaName":602,"dataGaLocation":471},"continuous integration & delivery",{"text":159,"config":604},{"href":161,"dataGaName":605,"dataGaLocation":471},"value stream management",{"text":551,"config":607},{"href":608,"dataGaName":554,"dataGaLocation":471},"/de-de/solutions/gitops/",{"text":172,"config":610},{"href":174,"dataGaName":175,"dataGaLocation":471},{"text":177,"config":612},{"href":179,"dataGaName":180,"dataGaLocation":471},{"text":182,"config":614},{"href":184,"dataGaName":185,"dataGaLocation":471},{"text":616,"config":617},"Bildungswesen",{"href":618,"dataGaName":619,"dataGaLocation":471},"/de-de/solutions/education/","education",{"text":621,"config":622},"Finanzdienstleistungen",{"href":623,"dataGaName":624,"dataGaLocation":471},"/de-de/solutions/finance/","financial services",{"title":192,"links":626},[627,629,631,633,636,638,640,642,644,646,648,650],{"text":204,"config":628},{"href":206,"dataGaName":207,"dataGaLocation":471},{"text":209,"config":630},{"href":211,"dataGaName":212,"dataGaLocation":471},{"text":214,"config":632},{"href":216,"dataGaName":217,"dataGaLocation":471},{"text":219,"config":634},{"href":221,"dataGaName":635,"dataGaLocation":471},"docs",{"text":242,"config":637},{"href":244,"dataGaName":245,"dataGaLocation":471},{"text":237,"config":639},{"href":239,"dataGaName":240,"dataGaLocation":471},{"text":247,"config":641},{"href":249,"dataGaName":250,"dataGaLocation":471},{"text":255,"config":643},{"href":257,"dataGaName":258,"dataGaLocation":471},{"text":260,"config":645},{"href":262,"dataGaName":263,"dataGaLocation":471},{"text":265,"config":647},{"href":267,"dataGaName":268,"dataGaLocation":471},{"text":270,"config":649},{"href":272,"dataGaName":273,"dataGaLocation":471},{"text":275,"config":651},{"href":277,"dataGaName":278,"dataGaLocation":471},{"title":293,"links":653},[654,656,658,660,662,664,666,671,676,678,680,682],{"text":300,"config":655},{"href":302,"dataGaName":295,"dataGaLocation":471},{"text":305,"config":657},{"href":307,"dataGaName":308,"dataGaLocation":471},{"text":313,"config":659},{"href":315,"dataGaName":316,"dataGaLocation":471},{"text":318,"config":661},{"href":320,"dataGaName":321,"dataGaLocation":471},{"text":323,"config":663},{"href":325,"dataGaName":326,"dataGaLocation":471},{"text":328,"config":665},{"href":330,"dataGaName":331,"dataGaLocation":471},{"text":667,"config":668},"Nachhaltigkeit",{"href":669,"dataGaName":670,"dataGaLocation":471},"/sustainability/","Sustainability",{"text":672,"config":673},"Vielfalt, Inklusion und Zugehörigkeit",{"href":674,"dataGaName":675,"dataGaLocation":471},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":677},{"href":335,"dataGaName":336,"dataGaLocation":471},{"text":343,"config":679},{"href":345,"dataGaName":346,"dataGaLocation":471},{"text":348,"config":681},{"href":350,"dataGaName":351,"dataGaLocation":471},{"text":683,"config":684},"Transparenzerklärung zu moderner Sklaverei",{"href":685,"dataGaName":686,"dataGaLocation":471},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":688},[689,691,694],{"text":519,"config":690},{"href":521,"dataGaName":522,"dataGaLocation":471},{"text":692,"config":693},"Cookies",{"dataGaName":531,"dataGaLocation":471,"id":532,"isOneTrustButton":14},{"text":524,"config":695},{"href":526,"dataGaName":527,"dataGaLocation":471},[697],{"id":698,"title":9,"body":26,"config":699,"content":701,"description":26,"extension":25,"meta":705,"navigation":14,"path":706,"seo":707,"stem":708,"__hash__":709},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":700},"BlogAuthor",{"name":9,"config":702},{"headshot":703,"ctfId":704},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{},"/en-us/blog/authors/fernando-diaz",{},"en-us/blog/authors/fernando-diaz","lxRJIOydP4_yzYZvsPcuQevP9AYAKREF7i8QmmdnOWc",[711,724,738],{"content":712,"config":722},{"title":713,"description":714,"authors":715,"heroImage":717,"date":718,"body":719,"category":11,"tags":720},"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.",[716],"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",[619,721],"open source",{"featured":32,"template":15,"slug":723},"teaching-software-development-the-easy-way-using-gitlab",{"content":725,"config":736},{"title":726,"description":727,"authors":728,"heroImage":730,"date":731,"body":732,"category":11,"tags":733},"Von Jenkins zu GitLab: Der vollständige Migrationsleitfaden","Schwachstellen in Jenkins-Umgebungen systematisch adressieren – mit GitLab CI als integrierter DevSecOps-Plattform.",[729],"Itzik Gan Baruch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","2026-03-15","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",[734,273,735,232,23,556],"tutorial","AI/ML",{"slug":737,"featured":32,"template":15},"jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment",{"content":739,"config":750},{"description":740,"authors":741,"heroImage":743,"date":744,"title":745,"body":746,"category":11,"tags":747},"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.",[742],"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.*",[735,748,749],"DevOps platform","security",{"featured":14,"template":15,"slug":751},"ai-is-reshaping-devsecops-attend-gitlab-transcend-to-see-whats-next",{"promotions":753},[754,768,780,791],{"id":755,"categories":756,"header":758,"text":759,"button":760,"image":765},"ai-modernization",[757],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":761,"config":762},"Get your AI maturity score",{"href":763,"dataGaName":764,"dataGaLocation":245},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":766},{"src":767},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":769,"categories":770,"header":772,"text":759,"button":773,"image":777},"devops-modernization",[771,11],"product","Are you just managing tools or shipping innovation?",{"text":774,"config":775},"Get your DevOps maturity score",{"href":776,"dataGaName":764,"dataGaLocation":245},"/assessments/devops-modernization-assessment/",{"config":778},{"src":779},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":781,"categories":782,"header":783,"text":759,"button":784,"image":788},"security-modernization",[749],"Are you trading speed for security?",{"text":785,"config":786},"Get your security maturity score",{"href":787,"dataGaName":764,"dataGaLocation":245},"/assessments/security-modernization-assessment/",{"config":789},{"src":790},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":792,"paths":793,"header":796,"text":797,"button":798,"image":803},"github-azure-migration",[794,795],"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":799,"config":800},"See how GitLab compares to GitHub",{"href":801,"dataGaName":802,"dataGaLocation":245},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":804},{"src":779},{"header":806,"blurb":807,"button":808,"secondaryButton":813},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":809,"config":810},"Kostenlosen Test starten",{"href":811,"dataGaName":51,"dataGaLocation":812},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":53,"config":814},{"href":55,"dataGaName":56,"dataGaLocation":812},1777493613375]