[{"data":1,"prerenderedAt":815},["ShallowReactive",2],{"/de-de/blog/what-is-a-rest-api-guide-and-functions":3,"navigation-de-de":39,"banner-de-de":453,"footer-de-de":463,"blog-post-authors-de-de-GitLab Germany Team":695,"blog-related-posts-de-de-what-is-a-rest-api-guide-and-functions":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":17,"extension":24,"externalUrl":25,"featured":14,"heroImage":19,"isFeatured":14,"meta":26,"navigation":27,"path":28,"publishedDate":20,"rawbody":29,"seo":30,"slug":13,"stem":34,"tagSlugs":35,"tags":37,"template":15,"updatedDate":25,"__hash__":38},"blogPosts/de-de/blog/what-is-a-rest-api-guide-and-functions.yml","Was ist eine REST-API? Guide & Funktionen",[7],"gitlab-germany-team",[9],"GitLab Germany Team","REST-APIs sind seit über zwei Jahrzehnten ein zentraler Baustein des Internets. Bei ihnen handelt es sich um Programmierschnittstellen (APIs), die den Austausch von Daten zwischen Client und Server regeln. REST-APIs unterliegen einem Satz von Bedingungen, welche der Wissenschaftler Roy Fielding im Jahr 2000 entwickelt und unter der Abkürzung REST (representational state transfer) [festgelegt hat](https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 \"festgelegt hat\").\n\nREST legt die genaue technische Umsetzung dieser Schnittstellen nicht fest. Fielding hat REST vielmehr als einen „Architektur-Stil“ [bezeichnet](https://www.youtube.com/watch?v=6oFAmQUM8ws \"bezeichnet\"), der eine Vielzahl praktischer Lösungen erlaubt. Jede API, die sich innerhalb der Grenzen dieser Architektur bewegt, entspricht dem REST-Standard.\n\nIn diesem Artikel zeigen wir Ihnen, warum sich REST seit seiner Einführung zum dominanten Modell entwickelt hat und welche Vorteile sich für Web-Development-Teams daraus ergeben. \n\n## Constraints: Die Grundbausteine der REST-Architektur\n\nREST baut auf insgesamt sechs sogenannten „Constraints“ (Einschränkungen) auf. \n\nAus ihnen ergibt sich eine Architektur, die einfach und anpassungsfähig ist und auch in einem rasch wandelnden Geschäftsumfeld langfristig Bestand haben kann.\n\n## Definition: Was ist eine Rest-API?\n\nREST-APIs sind praktische Softwarelösungen, die auf der REST-Dokumentation aufbauen und gemäß der folgenden sechs REST-Prinzipien für ein Client-Server-Modell erstellt werden: \n\n- Unabhängigkeit zwischen Client und Server,\n- Zustandslosigkeit,\n- ein mehrschichtiges Systemmodell, \n- eine einheitliche Schnittstelle,\n- Cache-Fähigkeit und\n- ein optionales Constraint: Code on Demand.\n\nIn den folgenden Abschnitten betrachten wir diese Constraints genauer. \n\n### Unabhängigkeit zwischen Client und Server\n\nREST findet wie erwähnt für APIs Anwendung, die den Austausch von Ressourcen zwischen einem Client und einem Server ermöglichen. Entscheidend ist, dass Client und Server vollkommen unabhängig voneinander bleiben. \n\nSo kann beispielsweise der Code des Servers verändert werden, ohne dass der Client ebenfalls Änderungen vornehmen muss, um weiterhin Informationen anfragen und erhalten zu können. \n\n### Zustandslosigkeit\n\nDie Einschränkung der Zustandslosigkeit hat der REST-Architektur ihren Namen verliehen. Für APIs soll gemäß dieser Vorgabe gelten, dass für die korrekte Beantwortung einer Anfrage die übermittelten Informationen der aktuellen Sitzung ausreichen.\n\nDas bedeutet: Es ist keine dauerhafte Verbindung zwischen Client und Server erforderlich und Client-Anfragen müssen auf der Server-Seite auch nicht zwischengespeichert werden. \n\nZustandslosigkeit führt zu höherer Daten- und Ausfallsicherheit. Gleichzeitig gilt aber auch: Benötigen Nutzer(innen) dieselben Informationen ein zweites Mal, müssen sämtliche Informationen der vorigen Sitzung erneut eingeben werden. \n\n### Mehrschichtiges Systemmodell\n\nFür jedes Unternehmen ist eine andere Server-Struktur optimal. Werden Informationen beispielsweise in verschiedenen Schichten gespeichert, gestaltet sich die Abfrage mehr oder weniger komplex. Das aber sollte für eine Anfrage unerheblich bleiben, solange die Daten korrekt übermittelt werden.  \n\nDie Einschränkung des mehrschichtigen Systemmodells ist somit das Gegenstück zur Zustandslosigkeit. Während letztere besagt, dass der Server vom Client nichts weiter benötigt als die Anfrageinformationen, verlangt das mehrschichtige Modell, dass dem Client nicht bekannt zu sein braucht, wie der Server die angeforderten Daten bereitstellt. \n\nDer Server kann also mit einer Vielzahl verschiedener Architekturen arbeiten, ohne dass die REST-API-Schnittstelle beeinflusst wird. \n\n### Einheitliche Schnittstelle\n\nDiese Einschränkung ist etwas komplexer und wiederum aus vier Unterpunkten aufgebaut. Für Roy Fielding war sie die womöglich wichtigste der gesamten REST-API-Architektur. \n\nDie einheitliche Schnittstelle fordert:\n\n- dass jeder Datensatz über eine einzige URI eindeutig gekennzeichnet ist,\n- dass Veränderungen oder auch Löschungen der Daten nur mittels der grundlegenden Netzwerkprotokollbefehle, wie GET, POST, PUT/PATCH und DELETE, vorgenommen werden können,\n- dass jede Nachricht, die versandt wird, mittels Metadaten sämtliche Informationen bereithält, die für die Bearbeitung der Daten erforderlich ist und\n- dass, sofern erforderlich, Hyperlinks (HATEOAS) bereitgestellt werden, um weitere benötigte Informationen einzuholen.\n\nDie einheitliche Schnittstelle sorgt für maximale Klarheit und eine einfache, standardisierte Client-Server-Kommunikation. \n\n### Cache-Fähigkeit\n\nZwar findet bei REST-APIs der Ressourcenaustausch zustandslos statt, zugleich aber sollten einmal angeforderte Daten aus einer Sitzung auf demselben Endgerät weiterverwendet werden können.\n\nIndem REST das Cachen dieser Informationen ermöglicht, sorgt es für eine höhere Effizienz und beschleunigt viele Prozesse bedeutend.\n\n### Code on Demand\n\nFür die meisten Anwendungen reicht die Bereitstellung der Daten in der Form von XML or JSON vollkommen aus. In bestimmten Fällen aber kann es von Vorteil sein, dem Client darüber hinaus –      oder stattdessen – eine Anwendung bereitzustellen. Denken Sie dabei an Java Applets oder JavaScript.\n\nCode on Demand stellt eine sinnvolle Erweiterung der REST-Architektur dar, aber sie ist als einzige der sechs Einschränkungen optional. \n\n## Wofür eignen sich REST-APIs?\n\nFlexibilität ist eines der Hauptmerkmale von REST-APIs. So sind sehr viele praktische Anwendungen denkbar:\n\n- Ganz grundsätzlich das Abrufen und Bereitstellen von Daten. Social-Media-Seiten wie Instagram oder Facebook nutzen REST-APIs beispielsweise um Updates zu posten.\n- Gerade weil sie zustandslos sind, eignen sich REST-APIs für Cloud-Services: Auch wenn die Verbindung abbricht, können die Daten weiter genutzt werden. \n- [Microservices](https://microservices.io/ \"Microservices\") gewinnen rasch an Beliebtheit und Bedeutung. Mit ihnen geht ein umfassender Perspektivenwechsel einher: Applikationen werden nicht mehr als riesige, in sich geschlossene Systeme gedacht, sondern als modular und aus kleineren, schlanken Elementen zusammengesetzt. REST-APIs bilden die ideale Schnittstelle zur nahtlosen Integration dieser verschiedenen Bausteine.\n\nIm Laufe der letzten 20 Jahre sind Alternativen zu REST-APIs verfügbar geworden. Dennoch hat sich keine davon auf breiter Basis durchsetzen können. Ganz offensichtlich ist REST auch aktuell der beste Ansatz zum Datenaustausch im Netz. \n\n## Was sind die Vorteile einer Rest-     API?\n\nIn den frühen Tagen des Internets war SOAP (Simple object access protocol) die dominante Form des Datenaustauschs. \n\nDass sich REST seitdem durchgesetzt hat und fast ein Vierteljahrhundert lang relevant geblieben ist, lässt sich recht einfach aus seinen inhärenten Vorteilen erklären:\n\n- SOAP vs REST: SOAP ist ein Protokoll, das Regeln und auch technische Realisierungen im Gegensatz zu REST sehr präzise vorschreibt. Daraus ergibt sich unmittelbar, dass APIs, die auf diesen Anforderungen aufbauen, weitaus komplexer als REST-APIs sind.\n- Die APIs, die gemäß der REST-Richtlinien programmiert wurden, basieren auf dem HTTP-Standard. Sie sind schnell und effizient und in nahezu jedem Kontext einsetzbar. Aus genau diesen Gründen eignen sich REST-APIs auch besonders gut für mobile Anwendungen.\n- Der Begriff der Skalierbarkeit ist bereits gefallen und er ist auch einer der maßgeblichen Argumente für die Verwendung von REST-APIs. Darunter ist zu verstehen, dass bei Erweiterungen der Server-Architektur nicht die darunter liegende Datenaustausch-Technologie verändert werden muss. \n- Einige Unternehmen setzen aus Sicherheitserwägungen immer noch auf SOAP. Allerdings sind REST-APIs keineswegs grundsätzlich unsicher. Entscheidend ist, einige grundlegende Best Practices anzuwenden – darunter die Verwendung von HTTPS sowie Autorisierung und Authentifizierung. \n\n## Gibt es eine REST-API von GitLab?\n\nAuch bei GitLab sind wir von den Vorzügen der REST-Architektur überzeugt. Aus diesem Grund stellen wir unseren Nutzer(inne)n eine [GitLab-REST-API](https://docs.gitlab.com/api/rest/ \"GitLab-REST-API\") zur Verfügung. \n\nBei GitLab handelt es sich um den führenden Anbieter von DevSecOps-Lösungen. Anwender(innen) nutzen die Plattform, um sicher, fehlerfrei und kollaborativ an Entwicklungsprojekten zu arbeiten. \n\nDie GitLab-API kann sowohl genutzt werden, um öffentlich sichtbare, als auch nicht öffentliche Daten (nach erfolgter Authentifizierung und Autorisierung) abzurufen. Weil die API unmittelbar auf GitLab abgestimmt ist, erfolgt der Austausch sicher, schnell und effizient. \n\n## REST-API FAQs\n\n### Ist REST ein Standard?\n\nREST ist ein Satz aus sechs Einschränkungen, die den Datenaustausch in einer Client-Server-Beziehung regeln. Alle API-Schnittstellen, die diesen Vorgaben entsprechen, sind „RESTful“. \nEs ist somit nicht falsch, REST als einen Standard zu bezeichnen. Allerdings gilt dies weniger im Sinne eines Protokolls oder konkreter Anweisungen. REST gibt vielmehr Leitlinien und Anforderungen vor, deren Umsetzung zu gewünschten Ergebnissen führen, unabhängig davon, wie diese technisch realisiert werden.\n\nAus diesem Grund wird REST zumeist als ein „Architektur-Stil“ definiert. \n\n### Muss ich alle sechs REST-Einschränkungen befolgen?\n\nRoy Fielding hat hierzu persönlich im Laufe der Jahre mehrfach [Stellung bezogen](https://www.infoq.com/articles/roy-fielding-on-versioning/ \"Stellung bezogen\"). Seine Ansichten zu dieser Frage sind eindeutig: REST ist nicht in allen Fällen zwangsläufig die beste Option. Wenn man aber eine REST-konforme Architektur wünscht, müssen sämtliche Constraints ausnahmslos umgesetzt werden. \n\nEine API beispielsweise, die alle Einschränkungen umsetzt, bei der aber keine Daten gecached werden können, ist nicht RESTful. \n\nDie einzige Ausnahme ist Code on Demand. Diese Einschränkung ist optional und muss somit nicht umgesetzt werden, damit eine REST-API die Kriterien erfüllt. \n\n### Wie passen Cache-Fähigkeit und Zustandslosigkeit zusammen?\n\nZwischen den Einschränkungen der Cache-Fähigkeit und Zustandslosigkeit scheint ein Spannungsverhältnis zu bestehen. Wenn bei jeder Anfrage die Daten neu übermittelt werden müssen, widerspricht das Zwischenspeichern von Daten im Cache dann nicht dieser Forderung? \n\nIn Wahrheit fordert Zustandslosigkeit lediglich, dass der Server jede Anfrage so behandelt, als wäre sie die erste. Es besteht keine Zuordnung der Daten im Cache zu einer aktuellen Anfrage. \n\nDas Cachen der Daten dient lediglich einer höheren Effizienz und sorgt für Stabilität. \n\n### Was bedeutet der Begriff Idempotenz im Zusammenhang mit REST-APIs?\n\nWenn ein Client dieselbe Anfrage mehrfach nacheinander stellt, spricht man von Idempotenz. Das kann entweder passieren, weil die Verbindung instabil oder der Code fehlerhaft ist. \n\nEntscheidend ist, dass eine solche idempotente Anfrage nicht zu einem Fehler bei der Beantwortung der Anfrage führt. \n\nDie Einschränkung der Cache-Fähigkeit sorgt dafür, dass idempotente Anfragen als solche erkannt und fehlerfrei bearbeitet werden können. \n\n### Wie lassen sich Rest-APIs sichern?\n\nREST-APIs können sehr effektiv gesichert werden. \n\nÜbliche und sehr effiziente Methoden sind die Verwendung von HTTPS und API-Schlüsseln, die Durchführung von Authentifizierungen und Autorisierungen sowie die Durchführung einer Input-Validation und eines Audit-Loggings. \n\nAuch die Begrenzung der Anfragen in einem bestimmten Zeitfenster im Sinne eines Rate-Limiting empfiehlt sich.","devsecops",{"slug":13,"featured":14,"template":15},"what-is-a-rest-api-guide-and-functions",false,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21},"REST-APIs sind der de-facto-Standard für die Kommunikation zwischen Server und Client. Erfahren Sie hier alles Wissenswerte zum Thema!",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg","2024-10-16",[22,23],"DevOps","DevSecOps","yml",null,{},true,"/de-de/blog/what-is-a-rest-api-guide-and-functions","seo:\n  title: Was ist eine REST-API? Guide & Funktionen\n  description: >-\n    REST-APIs sind der de-facto-Standard für die Kommunikation zwischen Server\n    und Client. Erfahren Sie hier alles Wissenswerte zum Thema!\n  ogTitle: Was ist eine REST-API? Guide & Funktionen\n  ogDescription: >-\n    REST-APIs sind der de-facto-Standard für die Kommunikation zwischen Server\n    und Client. Erfahren Sie hier alles Wissenswerte zum Thema!\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg\n  ogUrl: https://about.gitlab.com/blog/what-is-a-rest-api-guide-and-functions\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/what-is-a-rest-api-guide-and-functions\ncontent:\n  title: Was ist eine REST-API? Guide & Funktionen\n  description: >-\n    REST-APIs sind der de-facto-Standard für die Kommunikation zwischen Server\n    und Client. Erfahren Sie hier alles Wissenswerte zum Thema!\n  authors:\n    - GitLab Germany Team\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg\n  date: '2024-10-16'\n  body: >-\n    REST-APIs sind seit über zwei Jahrzehnten ein zentraler Baustein des\n    Internets. Bei ihnen handelt es sich um Programmierschnittstellen (APIs),\n    die den Austausch von Daten zwischen Client und Server regeln. REST-APIs\n    unterliegen einem Satz von Bedingungen, welche der Wissenschaftler Roy\n    Fielding im Jahr 2000 entwickelt und unter der Abkürzung REST\n    (representational state transfer) [festgelegt\n    hat](https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7\n    \"festgelegt hat\").\n\n\n    REST legt die genaue technische Umsetzung dieser Schnittstellen nicht fest.\n    Fielding hat REST vielmehr als einen „Architektur-Stil“\n    [bezeichnet](https://www.youtube.com/watch?v=6oFAmQUM8ws \"bezeichnet\"), der\n    eine Vielzahl praktischer Lösungen erlaubt. Jede API, die sich innerhalb der\n    Grenzen dieser Architektur bewegt, entspricht dem REST-Standard.\n\n\n    In diesem Artikel zeigen wir Ihnen, warum sich REST seit seiner Einführung\n    zum dominanten Modell entwickelt hat und welche Vorteile sich für\n    Web-Development-Teams daraus ergeben. \n\n\n    ## Constraints: Die Grundbausteine der REST-Architektur\n\n\n    REST baut auf insgesamt sechs sogenannten „Constraints“ (Einschränkungen)\n    auf. \n\n\n    Aus ihnen ergibt sich eine Architektur, die einfach und anpassungsfähig ist\n    und auch in einem rasch wandelnden Geschäftsumfeld langfristig Bestand haben\n    kann.\n\n\n    ## Definition: Was ist eine Rest-API?\n\n\n    REST-APIs sind praktische Softwarelösungen, die auf der REST-Dokumentation\n    aufbauen und gemäß der folgenden sechs REST-Prinzipien für ein\n    Client-Server-Modell erstellt werden: \n\n\n    - Unabhängigkeit zwischen Client und Server,\n\n    - Zustandslosigkeit,\n\n    - ein mehrschichtiges Systemmodell, \n\n    - eine einheitliche Schnittstelle,\n\n    - Cache-Fähigkeit und\n\n    - ein optionales Constraint: Code on Demand.\n\n\n    In den folgenden Abschnitten betrachten wir diese Constraints genauer. \n\n\n    ### Unabhängigkeit zwischen Client und Server\n\n\n    REST findet wie erwähnt für APIs Anwendung, die den Austausch von Ressourcen\n    zwischen einem Client und einem Server ermöglichen. Entscheidend ist, dass\n    Client und Server vollkommen unabhängig voneinander bleiben. \n\n\n    So kann beispielsweise der Code des Servers verändert werden, ohne dass der\n    Client ebenfalls Änderungen vornehmen muss, um weiterhin Informationen\n    anfragen und erhalten zu können. \n\n\n    ### Zustandslosigkeit\n\n\n    Die Einschränkung der Zustandslosigkeit hat der REST-Architektur ihren Namen\n    verliehen. Für APIs soll gemäß dieser Vorgabe gelten, dass für die korrekte\n    Beantwortung einer Anfrage die übermittelten Informationen der aktuellen\n    Sitzung ausreichen.\n\n\n    Das bedeutet: Es ist keine dauerhafte Verbindung zwischen Client und Server\n    erforderlich und Client-Anfragen müssen auf der Server-Seite auch nicht\n    zwischengespeichert werden. \n\n\n    Zustandslosigkeit führt zu höherer Daten- und Ausfallsicherheit.\n    Gleichzeitig gilt aber auch: Benötigen Nutzer(innen) dieselben Informationen\n    ein zweites Mal, müssen sämtliche Informationen der vorigen Sitzung erneut\n    eingeben werden. \n\n\n    ### Mehrschichtiges Systemmodell\n\n\n    Für jedes Unternehmen ist eine andere Server-Struktur optimal. Werden\n    Informationen beispielsweise in verschiedenen Schichten gespeichert,\n    gestaltet sich die Abfrage mehr oder weniger komplex. Das aber sollte für\n    eine Anfrage unerheblich bleiben, solange die Daten korrekt übermittelt\n    werden.  \n\n\n    Die Einschränkung des mehrschichtigen Systemmodells ist somit das Gegenstück\n    zur Zustandslosigkeit. Während letztere besagt, dass der Server vom Client\n    nichts weiter benötigt als die Anfrageinformationen, verlangt das\n    mehrschichtige Modell, dass dem Client nicht bekannt zu sein braucht, wie\n    der Server die angeforderten Daten bereitstellt. \n\n\n    Der Server kann also mit einer Vielzahl verschiedener Architekturen\n    arbeiten, ohne dass die REST-API-Schnittstelle beeinflusst wird. \n\n\n    ### Einheitliche Schnittstelle\n\n\n    Diese Einschränkung ist etwas komplexer und wiederum aus vier Unterpunkten\n    aufgebaut. Für Roy Fielding war sie die womöglich wichtigste der gesamten\n    REST-API-Architektur. \n\n\n    Die einheitliche Schnittstelle fordert:\n\n\n    - dass jeder Datensatz über eine einzige URI eindeutig gekennzeichnet ist,\n\n    - dass Veränderungen oder auch Löschungen der Daten nur mittels der\n    grundlegenden Netzwerkprotokollbefehle, wie GET, POST, PUT/PATCH und DELETE,\n    vorgenommen werden können,\n\n    - dass jede Nachricht, die versandt wird, mittels Metadaten sämtliche\n    Informationen bereithält, die für die Bearbeitung der Daten erforderlich ist\n    und\n\n    - dass, sofern erforderlich, Hyperlinks (HATEOAS) bereitgestellt werden, um\n    weitere benötigte Informationen einzuholen.\n\n\n    Die einheitliche Schnittstelle sorgt für maximale Klarheit und eine\n    einfache, standardisierte Client-Server-Kommunikation. \n\n\n    ### Cache-Fähigkeit\n\n\n    Zwar findet bei REST-APIs der Ressourcenaustausch zustandslos statt,\n    zugleich aber sollten einmal angeforderte Daten aus einer Sitzung auf\n    demselben Endgerät weiterverwendet werden können.\n\n\n    Indem REST das Cachen dieser Informationen ermöglicht, sorgt es für eine\n    höhere Effizienz und beschleunigt viele Prozesse bedeutend.\n\n\n    ### Code on Demand\n\n\n    Für die meisten Anwendungen reicht die Bereitstellung der Daten in der Form\n    von XML or JSON vollkommen aus. In bestimmten Fällen aber kann es von\n    Vorteil sein, dem Client darüber hinaus –      oder stattdessen – eine\n    Anwendung bereitzustellen. Denken Sie dabei an Java Applets oder JavaScript.\n\n\n    Code on Demand stellt eine sinnvolle Erweiterung der REST-Architektur dar,\n    aber sie ist als einzige der sechs Einschränkungen optional. \n\n\n    ## Wofür eignen sich REST-APIs?\n\n\n    Flexibilität ist eines der Hauptmerkmale von REST-APIs. So sind sehr viele\n    praktische Anwendungen denkbar:\n\n\n    - Ganz grundsätzlich das Abrufen und Bereitstellen von Daten.\n    Social-Media-Seiten wie Instagram oder Facebook nutzen REST-APIs\n    beispielsweise um Updates zu posten.\n\n    - Gerade weil sie zustandslos sind, eignen sich REST-APIs für\n    Cloud-Services: Auch wenn die Verbindung abbricht, können die Daten weiter\n    genutzt werden. \n\n    - [Microservices](https://microservices.io/ \"Microservices\") gewinnen rasch\n    an Beliebtheit und Bedeutung. Mit ihnen geht ein umfassender\n    Perspektivenwechsel einher: Applikationen werden nicht mehr als riesige, in\n    sich geschlossene Systeme gedacht, sondern als modular und aus kleineren,\n    schlanken Elementen zusammengesetzt. REST-APIs bilden die ideale\n    Schnittstelle zur nahtlosen Integration dieser verschiedenen Bausteine.\n\n\n    Im Laufe der letzten 20 Jahre sind Alternativen zu REST-APIs verfügbar\n    geworden. Dennoch hat sich keine davon auf breiter Basis durchsetzen können.\n    Ganz offensichtlich ist REST auch aktuell der beste Ansatz zum\n    Datenaustausch im Netz. \n\n\n    ## Was sind die Vorteile einer Rest-     API?\n\n\n    In den frühen Tagen des Internets war SOAP (Simple object access protocol)\n    die dominante Form des Datenaustauschs. \n\n\n    Dass sich REST seitdem durchgesetzt hat und fast ein Vierteljahrhundert lang\n    relevant geblieben ist, lässt sich recht einfach aus seinen inhärenten\n    Vorteilen erklären:\n\n\n    - SOAP vs REST: SOAP ist ein Protokoll, das Regeln und auch technische\n    Realisierungen im Gegensatz zu REST sehr präzise vorschreibt. Daraus ergibt\n    sich unmittelbar, dass APIs, die auf diesen Anforderungen aufbauen, weitaus\n    komplexer als REST-APIs sind.\n\n    - Die APIs, die gemäß der REST-Richtlinien programmiert wurden, basieren auf\n    dem HTTP-Standard. Sie sind schnell und effizient und in nahezu jedem\n    Kontext einsetzbar. Aus genau diesen Gründen eignen sich REST-APIs auch\n    besonders gut für mobile Anwendungen.\n\n    - Der Begriff der Skalierbarkeit ist bereits gefallen und er ist auch einer\n    der maßgeblichen Argumente für die Verwendung von REST-APIs. Darunter ist zu\n    verstehen, dass bei Erweiterungen der Server-Architektur nicht die darunter\n    liegende Datenaustausch-Technologie verändert werden muss. \n\n    - Einige Unternehmen setzen aus Sicherheitserwägungen immer noch auf SOAP.\n    Allerdings sind REST-APIs keineswegs grundsätzlich unsicher. Entscheidend\n    ist, einige grundlegende Best Practices anzuwenden – darunter die Verwendung\n    von HTTPS sowie Autorisierung und Authentifizierung. \n\n\n    ## Gibt es eine REST-API von GitLab?\n\n\n    Auch bei GitLab sind wir von den Vorzügen der REST-Architektur überzeugt.\n    Aus diesem Grund stellen wir unseren Nutzer(inne)n eine\n    [GitLab-REST-API](https://docs.gitlab.com/api/rest/ \"GitLab-REST-API\")\n    zur Verfügung. \n\n\n    Bei GitLab handelt es sich um den führenden Anbieter von DevSecOps-Lösungen.\n    Anwender(innen) nutzen die Plattform, um sicher, fehlerfrei und kollaborativ\n    an Entwicklungsprojekten zu arbeiten. \n\n\n    Die GitLab-API kann sowohl genutzt werden, um öffentlich sichtbare, als auch\n    nicht öffentliche Daten (nach erfolgter Authentifizierung und Autorisierung)\n    abzurufen. Weil die API unmittelbar auf GitLab abgestimmt ist, erfolgt der\n    Austausch sicher, schnell und effizient. \n\n\n    ## REST-API FAQs\n\n\n    ### Ist REST ein Standard?\n\n\n    REST ist ein Satz aus sechs Einschränkungen, die den Datenaustausch in einer\n    Client-Server-Beziehung regeln. Alle API-Schnittstellen, die diesen Vorgaben\n    entsprechen, sind „RESTful“. \n\n    Es ist somit nicht falsch, REST als einen Standard zu bezeichnen. Allerdings\n    gilt dies weniger im Sinne eines Protokolls oder konkreter Anweisungen. REST\n    gibt vielmehr Leitlinien und Anforderungen vor, deren Umsetzung zu\n    gewünschten Ergebnissen führen, unabhängig davon, wie diese technisch\n    realisiert werden.\n\n\n    Aus diesem Grund wird REST zumeist als ein „Architektur-Stil“ definiert. \n\n\n    ### Muss ich alle sechs REST-Einschränkungen befolgen?\n\n\n    Roy Fielding hat hierzu persönlich im Laufe der Jahre mehrfach [Stellung\n    bezogen](https://www.infoq.com/articles/roy-fielding-on-versioning/\n    \"Stellung bezogen\"). Seine Ansichten zu dieser Frage sind eindeutig: REST\n    ist nicht in allen Fällen zwangsläufig die beste Option. Wenn man aber eine\n    REST-konforme Architektur wünscht, müssen sämtliche Constraints ausnahmslos\n    umgesetzt werden. \n\n\n    Eine API beispielsweise, die alle Einschränkungen umsetzt, bei der aber\n    keine Daten gecached werden können, ist nicht RESTful. \n\n\n    Die einzige Ausnahme ist Code on Demand. Diese Einschränkung ist optional\n    und muss somit nicht umgesetzt werden, damit eine REST-API die Kriterien\n    erfüllt. \n\n\n    ### Wie passen Cache-Fähigkeit und Zustandslosigkeit zusammen?\n\n\n    Zwischen den Einschränkungen der Cache-Fähigkeit und Zustandslosigkeit\n    scheint ein Spannungsverhältnis zu bestehen. Wenn bei jeder Anfrage die\n    Daten neu übermittelt werden müssen, widerspricht das Zwischenspeichern von\n    Daten im Cache dann nicht dieser Forderung? \n\n\n    In Wahrheit fordert Zustandslosigkeit lediglich, dass der Server jede\n    Anfrage so behandelt, als wäre sie die erste. Es besteht keine Zuordnung der\n    Daten im Cache zu einer aktuellen Anfrage. \n\n\n    Das Cachen der Daten dient lediglich einer höheren Effizienz und sorgt für\n    Stabilität. \n\n\n    ### Was bedeutet der Begriff Idempotenz im Zusammenhang mit REST-APIs?\n\n\n    Wenn ein Client dieselbe Anfrage mehrfach nacheinander stellt, spricht man\n    von Idempotenz. Das kann entweder passieren, weil die Verbindung instabil\n    oder der Code fehlerhaft ist. \n\n\n    Entscheidend ist, dass eine solche idempotente Anfrage nicht zu einem Fehler\n    bei der Beantwortung der Anfrage führt. \n\n\n    Die Einschränkung der Cache-Fähigkeit sorgt dafür, dass idempotente Anfragen\n    als solche erkannt und fehlerfrei bearbeitet werden können. \n\n\n    ### Wie lassen sich Rest-APIs sichern?\n\n\n    REST-APIs können sehr effektiv gesichert werden. \n\n\n    Übliche und sehr effiziente Methoden sind die Verwendung von HTTPS und\n    API-Schlüsseln, die Durchführung von Authentifizierungen und Autorisierungen\n    sowie die Durchführung einer Input-Validation und eines Audit-Loggings. \n\n\n    Auch die Begrenzung der Anfragen in einem bestimmten Zeitfenster im Sinne\n    eines Rate-Limiting empfiehlt sich.\n  category: devsecops\n  tags:\n    - DevOps\n    - DevSecOps\nconfig:\n  slug: what-is-a-rest-api-guide-and-functions\n  featured: false\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":14,"ogImage":19,"ogUrl":31,"ogSiteName":32,"ogType":33,"canonicalUrls":31},"https://about.gitlab.com/blog/what-is-a-rest-api-guide-and-functions","https://about.gitlab.com","article","de-de/blog/what-is-a-rest-api-guide-and-functions",[36,11],"devops",[22,23],"ZGSTMasdXtAKrZqzTuPfiAJw_GhufMqYD6k-svACPbQ",{"data":40},{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":371,"minimal":405,"duo":423,"switchNav":432,"pricingDeployment":443},{"config":42},{"href":43,"dataGaName":44,"dataGaLocation":45},"/de-de/","gitlab logo","header",{"text":47,"config":48},"Kostenlose Testversion anfordern",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":52,"config":53},"Vertrieb kontaktieren",{"href":54,"dataGaName":55,"dataGaLocation":45},"/de-de/sales/","sales",{"text":57,"config":58},"Anmelden",{"href":59,"dataGaName":60,"dataGaLocation":45},"https://gitlab.com/users/sign_in/","sign in",[62,89,186,191,292,352],{"text":63,"config":64,"cards":66},"Plattform",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":70,"config":71},"Die Plattform erkunden",{"href":72,"dataGaName":65,"dataGaLocation":45},"/de-de/platform/",{"title":74,"description":75,"link":76},"GitLab Duo Agent Platform","Agentische KI für den gesamten Software-Lebenszyklus",{"text":77,"config":78},"Lerne GitLab Duo kennen",{"href":79,"dataGaName":80,"dataGaLocation":45},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":82,"description":83,"link":84},"Warum GitLab?","Erfahre, warum sich Unternehmen für GitLab entscheiden",{"text":85,"config":86},"Mehr erfahren",{"href":87,"dataGaName":88,"dataGaLocation":45},"/de-de/why-gitlab/","why gitlab",{"text":90,"left":27,"config":91,"link":93,"lists":97,"footer":168},"Produkt",{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"Alle Lösungen anzeigen",{"href":96,"dataGaName":92,"dataGaLocation":45},"/de-de/solutions/",[98,123,146],{"title":99,"description":100,"link":101,"items":106},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":45},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[107,111,114,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":45,"dataGaName":108},"/de-de/solutions/continuous-integration/",{"text":74,"config":112},{"href":79,"dataGaLocation":45,"dataGaName":113},"gitlab duo agent platform - product menu",{"text":115,"config":116},"Quellcodeverwaltung",{"href":117,"dataGaLocation":45,"dataGaName":118},"/de-de/solutions/source-code-management/","Source Code Management",{"text":120,"config":121},"Automatische Softwarebereitstellung",{"href":104,"dataGaLocation":45,"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":45,"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":45},"Application security testing",{"text":137,"config":138},"Schutz der Software-Lieferkette",{"href":139,"dataGaLocation":45,"dataGaName":140},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Software-Compliance",{"href":144,"dataGaName":145,"dataGaLocation":45},"/de-de/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"Auswertung",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":45},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[154,158,163],{"text":155,"config":156},"Sichtbarkeit und Auswertung",{"href":151,"dataGaLocation":45,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Wertstrommanagement",{"href":161,"dataGaLocation":45,"dataGaName":162},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":164,"config":165},"Analysen und Einblicke",{"href":166,"dataGaLocation":45,"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":45,"dataGaName":175},"/de-de/enterprise/","enterprise",{"text":177,"config":178},"Kleinunternehmen",{"href":179,"dataGaLocation":45,"dataGaName":180},"/de-de/small-business/","small business",{"text":182,"config":183},"Öffentlicher Sektor",{"href":184,"dataGaLocation":45,"dataGaName":185},"/de-de/solutions/public-sector/","public sector",{"text":187,"config":188},"Preise",{"href":189,"dataGaName":190,"dataGaLocation":45,"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":45},"/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":45},"/de-de/install/","install",{"text":209,"config":210},"Kurzanleitungen",{"href":211,"dataGaName":212,"dataGaLocation":45},"/de-de/get-started/","quick setup checklists",{"text":214,"config":215},"Lernen",{"href":216,"dataGaLocation":45,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Produktdokumentation",{"href":221,"dataGaName":222,"dataGaLocation":45},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Best-Practice-Videos",{"href":226,"dataGaName":227,"dataGaLocation":45},"/de-de/getting-started-videos/","best practice videos",{"text":229,"config":230},"Integrationen",{"href":231,"dataGaName":232,"dataGaLocation":45},"/de-de/integrations/","integrations",{"title":234,"items":235},"Entdecken",[236,241,246],{"text":237,"config":238},"Kundenerfolge",{"href":239,"dataGaName":240,"dataGaLocation":45},"/de-de/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":45},"/de-de/blog/","blog",{"text":247,"config":248},"Remote",{"href":249,"dataGaName":250,"dataGaLocation":45},"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":45},"/de-de/services/","services",{"text":260,"config":261},"Community",{"href":262,"dataGaName":263,"dataGaLocation":45},"/community/","community",{"text":265,"config":266},"Forum",{"href":267,"dataGaName":268,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":270,"config":271},"Veranstaltungen",{"href":272,"dataGaName":273,"dataGaLocation":45},"/events/","events",{"text":275,"config":276},"Partner",{"href":277,"dataGaName":278,"dataGaLocation":45},"/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":45},"/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":45},"/de-de/company/","about",{"text":305,"config":306,"footerGa":309},"Karriere",{"href":307,"dataGaName":308,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":308},{"text":270,"config":311},{"href":272,"dataGaName":273,"dataGaLocation":45},{"text":313,"config":314},"Geschäftsführung",{"href":315,"dataGaName":316,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":318,"config":319},"Team",{"href":320,"dataGaName":321,"dataGaLocation":45},"/company/team/","team",{"text":323,"config":324},"Handbuch",{"href":325,"dataGaName":326,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"Investor Relations",{"href":330,"dataGaName":331,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"Trust Center",{"href":335,"dataGaName":336,"dataGaLocation":45},"/de-de/security/","trust center",{"text":338,"config":339},"AI Transparency Center",{"href":340,"dataGaName":341,"dataGaLocation":45},"/de-de/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"Newsletter",{"href":345,"dataGaName":346,"dataGaLocation":45},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"Presse",{"href":350,"dataGaName":351,"dataGaLocation":45},"/press/","press",{"text":353,"config":354,"lists":355},"Kontakt",{"dataNavLevelOne":295},[356],{"items":357},[358,361,366],{"text":52,"config":359},{"href":54,"dataGaName":360,"dataGaLocation":45},"talk to sales",{"text":362,"config":363},"Support-Portal",{"href":364,"dataGaName":365,"dataGaLocation":45},"https://support.gitlab.com","support portal",{"text":367,"config":368},"Kundenportal",{"href":369,"dataGaName":370,"dataGaLocation":45},"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":59,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"Vorschläge",[383,385,390,392,397,402],{"text":74,"config":384},{"href":79,"dataGaName":74,"dataGaLocation":379},{"text":386,"config":387},"Codevorschläge (KI)",{"href":388,"dataGaName":389,"dataGaLocation":379},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":108,"config":391},{"href":110,"dataGaName":108,"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":82,"config":403},{"href":87,"dataGaName":404,"dataGaLocation":379},"Why GitLab?",{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Kostenlos testen",{"href":409,"dataGaName":50,"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":79,"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":45},"/de-de/events/transcend/virtual/","transcend event",{"layout":461,"icon":462,"disabled":27},"release","AiStar",{"data":464},{"text":465,"source":466,"edit":472,"contribute":477,"config":482,"items":487,"minimal":686},"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,582,624,651],{"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":52,"config":508},{"href":54,"dataGaName":55,"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":27},"cookie preferences","ot-sdk-btn",{"title":90,"links":534,"subMenu":543},[535,539],{"text":536,"config":537},"DevSecOps-Plattform",{"href":72,"dataGaName":538,"dataGaLocation":471},"devsecops platform",{"text":540,"config":541},"KI-unterstützte Entwicklung",{"href":79,"dataGaName":542,"dataGaLocation":471},"ai-assisted development",[544],{"title":545,"links":546},"Themen",[547,551,556,559,564,567,572,577],{"text":108,"config":548},{"href":549,"dataGaName":550,"dataGaLocation":471},"/de-de/topics/ci-cd/","cicd",{"text":552,"config":553},"GitOps",{"href":554,"dataGaName":555,"dataGaLocation":471},"/de-de/topics/gitops/","gitops",{"text":22,"config":557},{"href":558,"dataGaName":36,"dataGaLocation":471},"/de-de/topics/devops/",{"text":560,"config":561},"Versionskontrolle",{"href":562,"dataGaName":563,"dataGaLocation":471},"/de-de/topics/version-control/","version control",{"text":23,"config":565},{"href":566,"dataGaName":11,"dataGaLocation":471},"/de-de/topics/devsecops/",{"text":568,"config":569},"Cloud-nativ",{"href":570,"dataGaName":571,"dataGaLocation":471},"/de-de/topics/cloud-native/","cloud native",{"text":573,"config":574},"KI für das Programmieren",{"href":575,"dataGaName":576,"dataGaLocation":471},"/de-de/topics/devops/ai-for-coding/","ai for coding",{"text":578,"config":579},"Agentische KI",{"href":580,"dataGaName":581,"dataGaLocation":471},"/de-de/topics/agentic-ai/","agentic ai",{"title":583,"links":584},"Lösungen",[585,588,590,595,599,602,605,608,610,612,614,619],{"text":133,"config":586},{"href":128,"dataGaName":587,"dataGaLocation":471},"Application Security Testing",{"text":120,"config":589},{"href":104,"dataGaName":105,"dataGaLocation":471},{"text":591,"config":592},"Agile Entwicklung",{"href":593,"dataGaName":594,"dataGaLocation":471},"/de-de/solutions/agile-delivery/","agile delivery",{"text":596,"config":597},"SCM",{"href":117,"dataGaName":598,"dataGaLocation":471},"source code management",{"text":108,"config":600},{"href":110,"dataGaName":601,"dataGaLocation":471},"continuous integration & delivery",{"text":159,"config":603},{"href":161,"dataGaName":604,"dataGaLocation":471},"value stream management",{"text":552,"config":606},{"href":607,"dataGaName":555,"dataGaLocation":471},"/de-de/solutions/gitops/",{"text":172,"config":609},{"href":174,"dataGaName":175,"dataGaLocation":471},{"text":177,"config":611},{"href":179,"dataGaName":180,"dataGaLocation":471},{"text":182,"config":613},{"href":184,"dataGaName":185,"dataGaLocation":471},{"text":615,"config":616},"Bildungswesen",{"href":617,"dataGaName":618,"dataGaLocation":471},"/de-de/solutions/education/","education",{"text":620,"config":621},"Finanzdienstleistungen",{"href":622,"dataGaName":623,"dataGaLocation":471},"/de-de/solutions/finance/","financial services",{"title":192,"links":625},[626,628,630,632,635,637,639,641,643,645,647,649],{"text":204,"config":627},{"href":206,"dataGaName":207,"dataGaLocation":471},{"text":209,"config":629},{"href":211,"dataGaName":212,"dataGaLocation":471},{"text":214,"config":631},{"href":216,"dataGaName":217,"dataGaLocation":471},{"text":219,"config":633},{"href":221,"dataGaName":634,"dataGaLocation":471},"docs",{"text":242,"config":636},{"href":244,"dataGaName":245,"dataGaLocation":471},{"text":237,"config":638},{"href":239,"dataGaName":240,"dataGaLocation":471},{"text":247,"config":640},{"href":249,"dataGaName":250,"dataGaLocation":471},{"text":255,"config":642},{"href":257,"dataGaName":258,"dataGaLocation":471},{"text":260,"config":644},{"href":262,"dataGaName":263,"dataGaLocation":471},{"text":265,"config":646},{"href":267,"dataGaName":268,"dataGaLocation":471},{"text":270,"config":648},{"href":272,"dataGaName":273,"dataGaLocation":471},{"text":275,"config":650},{"href":277,"dataGaName":278,"dataGaLocation":471},{"title":293,"links":652},[653,655,657,659,661,663,665,670,675,677,679,681],{"text":300,"config":654},{"href":302,"dataGaName":295,"dataGaLocation":471},{"text":305,"config":656},{"href":307,"dataGaName":308,"dataGaLocation":471},{"text":313,"config":658},{"href":315,"dataGaName":316,"dataGaLocation":471},{"text":318,"config":660},{"href":320,"dataGaName":321,"dataGaLocation":471},{"text":323,"config":662},{"href":325,"dataGaName":326,"dataGaLocation":471},{"text":328,"config":664},{"href":330,"dataGaName":331,"dataGaLocation":471},{"text":666,"config":667},"Nachhaltigkeit",{"href":668,"dataGaName":669,"dataGaLocation":471},"/sustainability/","Sustainability",{"text":671,"config":672},"Vielfalt, Inklusion und Zugehörigkeit",{"href":673,"dataGaName":674,"dataGaLocation":471},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":676},{"href":335,"dataGaName":336,"dataGaLocation":471},{"text":343,"config":678},{"href":345,"dataGaName":346,"dataGaLocation":471},{"text":348,"config":680},{"href":350,"dataGaName":351,"dataGaLocation":471},{"text":682,"config":683},"Transparenzerklärung zu moderner Sklaverei",{"href":684,"dataGaName":685,"dataGaLocation":471},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":687},[688,690,693],{"text":519,"config":689},{"href":521,"dataGaName":522,"dataGaLocation":471},{"text":691,"config":692},"Cookies",{"dataGaName":531,"dataGaLocation":471,"id":532,"isOneTrustButton":27},{"text":524,"config":694},{"href":526,"dataGaName":527,"dataGaLocation":471},[696],{"id":697,"title":698,"body":25,"config":699,"content":701,"description":25,"extension":24,"meta":705,"navigation":27,"path":706,"seo":707,"stem":708,"__hash__":709},"blogAuthors/en-us/blog/authors/gitlab-germany-team.yml","Gitlab Germany Team",{"template":700},"BlogAuthor",{"name":9,"config":702},{"headshot":703,"ctfId":704},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","6tNquF8jQeRRRi8k3ZXpvS",{},"/en-us/blog/authors/gitlab-germany-team",{},"en-us/blog/authors/gitlab-germany-team","vGs9BT_ji6dORS29vl80DKX6mSputlQV2W7-4vW2hL8",[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",[618,721],"open source",{"featured":14,"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,22],"tutorial","AI/ML",{"slug":737,"featured":14,"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":27,"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":50,"dataGaLocation":812},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":52,"config":814},{"href":54,"dataGaName":55,"dataGaLocation":812},1777493581719]