[{"data":1,"prerenderedAt":776},["ShallowReactive",2],{"/de-de/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation":3,"navigation-de-de":41,"banner-de-de":443,"footer-de-de":453,"blog-post-authors-de-de-Michael Friedrich":658,"blog-related-posts-de-de-efficient-devsecops-workflows-hands-on-python-gitlab-api-automation":672,"blog-promotions-de-de":714,"next-steps-de-de":766},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":28,"isFeatured":12,"meta":29,"navigation":30,"path":31,"publishedDate":20,"seo":32,"stem":36,"tagSlugs":37,"__hash__":40},"blogPosts/de-de/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation.yml","Efficient Devsecops Workflows Hands On Python Gitlab Api Automation",[7],"michael-friedrich",null,"engineering",{"slug":11,"featured":12,"template":13},"efficient-devsecops-workflows-hands-on-python-gitlab-api-automation",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22,"updatedDate":27},"Effiziente DevSecOps-Workflows: Praktische python-gitlab-API-Automatisierung","Die Python-GitLab-Bibliothek ist eine nützliche Basis für die GitLab-API. In diesem Tutorial erfährst du mehr über praktische Beispiele und bewährte Verfahren.",[18],"Michael Friedrich","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659883/Blog/Hero%20Images/post-cover-image.jpg","2023-02-01","Ein oft zitiertes Sprichwort aus einer Konferenzpräsentation lautet: „Manuelle Arbeit ist ein Fehler“. Bei sich wiederholenden Aufgaben in Arbeitsabläufen ist es ratsam, so viel wie möglich zu automatisieren. Ein Beispiel dafür ist die Nutzung einer REST-API zur Bestandsaufnahme von Einstellungen oder das Erstellen neuer Kommentare in GitLab-Issues und Merge-Anfragen mittels API-Aktionen.\n\n## GitLab-API-Interaktion: Möglichkeiten und Unterstützung durch API-Abstraktionsbibliotheken\n\nDie Interaktion mit der REST-API von GitLab kann auf verschiedene Weise erfolgen: entweder durch HTTP-Anfragen mit curl (oder hurl) in der Befehlszeile oder durch das Schreiben von Skripten in einer Programmiersprache. Letzteres kann dazu führen, dass der Code für HTTP-Anfragen und das Parsen der JSON-Antworten neu entwickelt werden muss. Glücklicherweise unterstützt die umfangreiche GitLab-Community viele Programmiersprachen mit API-Abstraktionsbibliotheken.\n\nDiese Bibliotheken bieten Unterstützung für alle API-Attribute, fügen Hilfsfunktionen zum Abrufen, Erstellen und Löschen von Objekten hinzu und helfen Entwicklern dabei, sich auf ihre Kernaufgaben zu konzentrieren. Die [python-gitlab Bibliothek](https://python-gitlab.readthedocs.io/en/stable/) ist ein besonders funktionsreiches und einfach zu verwendendes Beispiel für eine solche Bibliothek in Python.\n\nIn diesem Blogbeitrag wird die grundlegende Nutzung der python-gitlab-Bibliothek erläutert, einschließlich der Arbeit mit API-Objekten, Attributen, Paginierung und Resultsets. Zudem werden spezifischere Anwendungsfälle vorgestellt, in denen Daten gesammelt, Zusammenfassungen gedruckt und Daten in die API geschrieben werden, um Kommentare und Commits zu erstellen. Viele dieser Anwendungsfälle basieren auf Fragen aus der Community in Foren, auf Hacker News oder in Issues.\n\n## Inhaltsverzeichnis\n- [GitLab-API-Interaktion: Möglichkeiten und Unterstützung durch API-Abstraktionsbibliotheken](#gitlab-api-interaktion-möglichkeiten-und-unterstützung-durch-api-abstraktionsbibliotheken)\n- [Los geht's: python-gitlab Install](#los-geht's-python-gitlab-install)\n- [GitLab API Python: Konfiguration](#gitlab-api-python-konfiguration)\n- [Objekte verwalten: das GitLab-Objekt](#objekte-verwalten-das-gitlab-objekt)\n  - [Objektmanager und Laden von Objekten](#objektmanager-und-laden-von-objekten)\n  - [Paginierung der Ergebnisse](#paginierung-der-ergebnisse)\n  - [Arbeiten mit Objektbeziehungen](#arbeiten-mit-objektbeziehungen)\n  - [Arbeiten mit verschiedenen Objektsammlungsbereichen](#arbeiten-mit-verschiedenen-objektsammlungsbereichen)\n- [DevSecOps-Anwendungsfälle für API-Leseaktionen](#devsecops-anwendungsfälle-für-api-leseaktionen)\n  - [Zweige nach Zusammenführungsstatus auflisten](#zweige-nach-zusammenführungsstatus-auflisten)\n  - [Drucken von Projekteinstellungen zur Überprüfung: MR-Genehmigungsregeln](#drucken-von-projekteinstellungen-zur-überprüfung-mr-genehmigungsregeln)\n  - [Inventarisierung: Abrufen aller CI/CD-Variablen, die geschützt oder maskiert sind](#inventarisierung-abrufen-aller-cicd-variablen-die-geschützt-oder-maskiert-sind)\n  - [Herunterladen einer Datei aus dem Repository](#herunterladen-einer-datei-aus-dem-repository)\n  - [Hilfe zur Migration: Auflistung aller zertifikatsbasierten Kubernetes-Cluster](#hilfe-zur-migration-auflistung-aller-zertifikatsbasierten-kubernetes-cluster)\n  - [Team-Effizienz: Prüfe, ob bestehende Merge-Requests nach dem Mergen einer großen Refactoring-MR neu gebasht werden müssen](#team-effizienz-prüfe-ob-bestehende-merge-requests-nach-dem-mergen-einer-großen-refactoring-mr-neu-gebasht-werden-müssen)\n- [DevSecOps-Anwendungsfälle für API-Schreibaktionen](#devsecops-anwendungsfälle-für-api-schreibaktionen)\n  - [Verschieben von Epics zwischen Gruppen](#verschieben-von-epics-zwischen-gruppen)\n  - [Automatisierung des Verschiebens von Epics](#automatisierung-des-verschiebens-von-epics)\n  - [Compliance: Sicherstellen, dass Projekteinstellungen nicht überschrieben werden](#compliance-sicherstellen-dass-projekteinstellungen-nicht-überschrieben-werden)\n  - [Notizen machen, Fälligkeitsübersicht erstellen](#notizen-machen-fälligkeitsübersicht-erstellen)\n\n## Los geht's: python-gitlab Install\n\nDie Dokumentation von python-gitlab bietet eine umfassende Einführung in die Nutzung, einschließlich Anleitungen für den Einstieg, Informationen zu Objekttypen und deren Methoden sowie kombinierte Workflow-Beispiele. Ergänzend dazu ist die Dokumentation der GitLab-API-Ressourcen hilfreich, da sie die verfügbaren Objektattribute detailliert beschreibt. Zusammen sind diese beiden Dokumentationen die besten Ressourcen für den Einstieg.\n\nDie Code-Beispiele in diesem Blogbeitrag setzen Python 3.8+ und die python-gitlab-Bibliothek voraus. Weitere notwendige Abhängigkeiten sind in der Datei requirements.txt aufgeführt. Ein Beispiel erfordert die Bibliothek pyyaml zum Parsen von YAML-Konfigurationen. Um den Code der Anwendungsfälle nachzuvollziehen und zu üben, empfiehlt es sich, das Projekt zu klonen, die Anforderungen zu installieren und die Skripte auszuführen.\n\n```shell\ngit clone https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python.git\n\ncd gitlab-api-python\n\nbrew install python\n\npip3 install -r requirements.txt\n\npython3 \u003Cscriptname>.py\n```\nDie Skripte verwenden absichtlich keine gemeinsam genutzte Bibliothek, die z. B. generische Funktionen für das Lesen von Parametern oder zusätzliche Hilfsfunktionen bereitstellt. Die Idee ist, einfach zu verstehende Beispiele zu zeigen, die eigenständig zum Testen verwendet werden können und lediglich die Installation der python-gitlab-Bibliothek erfordern.\n\nEs wird empfohlen, den Code für den Produktionseinsatz zu verbessern. Dies kann auch beim Aufbau eines gewarteten API-Tooling-Projekts helfen, das z. B. Container-Images und CI/CD-Vorlagen für Entwickler enthält, die auf einer DevSecOps-Plattform genutzt werden können.\n\n## GitLab API Python: Konfiguration\n\nOhne Konfiguration führt python-gitlab unauthentifizierte Anfragen an den Standardserver https://gitlab.com aus. Die häufigsten Konfigurationseinstellungen beziehen sich auf die GitLab-Instanz, mit der eine Verbindung hergestellt werden soll, und die Authentifizierungsmethode durch Angabe von Zugriffstokens. python-gitlab unterstützt verschiedene Arten der Konfiguration: Eine Konfigurationsdatei oder Umgebungsvariablen.\n\nDie Konfigurationsdatei ist für die API-Bibliotheksbindungen und die CLI verfügbar (die CLI wird in diesem Blogpost nicht erläutert). Die Konfigurationsdatei unterstützt Credential Helpers für den direkten Zugriff auf Token.\n\nUmgebungsvariablen als alternative Konfigurationsmethode bieten eine einfache Möglichkeit, das Skript auf dem Terminal auszuführen, in Container-Images zu integrieren und sie für die Ausführung in CI/CD-Pipelines vorzubereiten.\n\nDie Konfiguration muss in den Kontext des Python-Skripts geladen werden. Beginne mit dem Import der os-Bibliothek, um die Umgebungsvariablen mit der Methode os.environ.get() abzurufen. Der erste Parameter gibt den Schlüssel an, der zweite Parameter legt den Standardwert fest, wenn die Variable in der Umgebung nicht verfügbar ist.\n\n```python\nimport os\n\ngl_server = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\nprint(gl_server)\n```\n\nDie Parametrisierung auf dem Terminal kann direkt nur für den Befehl erfolgen oder in die Shell-Umgebung exportiert werden.\n\n```shell\n$ GL_SERVER=’https://gitlab.company.com’ python3 script.py\n\n$ export GL_SERVER=’https://gitlab.company.com’\n$ python3 script.py\n```\n\nEs wird empfohlen, Sicherheitsprüfungen hinzuzufügen, um sicherzustellen, dass alle Variablen gesetzt sind, bevor das Programm weiter ausgeführt wird. Der folgende Ausschnitt importiert die erforderlichen Bibliotheken, liest die Umgebungsvariable GL_SERVER und erwartet, dass der Benutzer die Variable GL_TOKEN setzt. Wenn dies nicht der Fall ist, gibt das Skript Fehler aus und ruft sys.exit(1) auf, um einen Fehlerstatus anzuzeigen.\n\n```python\nimport gitlab\nimport os\nimport sys\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\n```\n\nFolgend siehst du ein ausführlicheres Beispiel, das eine Verbindung zur API herstellt und eine tatsächliche Datenabfrage durchführt.\n\n## Objekte verwalten: das GitLab-Objekt\n\nFür jede Interaktion mit der API muss das GitLab-Objekt instanziiert werden. Dies ist der Einstiegspunkt für die Konfiguration des GitLab-Servers für die Verbindung, die Authentifizierung mithilfe von Zugriffstokens und weitere globale Einstellungen für die Paginierung, das Laden von Objekten und mehr.\n\nIm folgenden Beispiel wird eine nicht authentifizierte Anfrage an gitlab.com ausgeführt. Es ist möglich, auf öffentliche API-Endpunkte zuzugreifen und zum Beispiel eine bestimmte [.gitignore Vorlage für Python](https://python-gitlab.readthedocs.io/en/stable/gl_objects/templates.html#gitignore-templates) abzurufen.\n\n[python_gitlab_object_unauthenticated.py](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/python_gitlab_object_unauthenticated.py)\n\n```python\nimport gitlab\n\ngl = gitlab.Gitlab()\n\n# Get .gitignore templates without authentication\ngitignore_templates = gl.gitignores.get('Python')\n\nprint(gitignore_templates.content)\n```\n\nDie nächsten Abschnitte geben weitere Einblicke in:\n\n- Objektmanager und Laden von Objekten\n- Paginierung von Ergebnissen\n- Arbeiten mit Objektbeziehungen\n- Arbeiten mit verschiedenen Objektsammlungsbereichen\n\n### Objektmanager und Laden von Objekten\n\nDie python-gitlab-Bibliothek ermöglicht den Zugriff auf GitLab-Ressourcen über sogenannte „[Manager](https://python-gitlab.readthedocs.io/en/stable/api-usage.html#managers)\". Jeder Managertyp implementiert Methoden zur Arbeit mit den Datensätzen (list, get, etc.).\n\nDas Skript zeigt, wie man auf Untergruppen, direkte Projekte, alle Projekte einschließlich Untergruppen, Issues, Epics und To-dos zugreifen kann. Diese Methoden und der API-Endpunkt erfordern eine Authentifizierung für den Zugriff auf alle Attribute. Der Codeschnipsel verwendet daher Variablen, um das Authentifizierungs-Token abzurufen sowie die GROUP_ID-Variable, um eine Hauptgruppe anzugeben, bei der die Suche beginnen soll.\n\n```python\n#!/usr/bin/env python\n\nimport gitlab\nimport os\nimport sys\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n# https://gitlab.com/gitlab-da/use-cases/\nGROUP_ID = os.environ.get('GL_GROUP_ID', 16058698)\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n# Main\nmain_group = gl.groups.get(GROUP_ID)\n\nprint(\"Sub groups\")\nfor sg in main_group.subgroups.list():\n    print(\"Subgroup name: {sg}\".format(sg=sg.name))\n\nprint(\"Projects (direct)\")\nfor p in main_group.projects.list():\n    print(\"Project name: {p}\".format(p=p.name))\n\nprint(\"Projects (including subgroups)\")\nfor p in main_group.projects.list(include_subgroups=True, all=True):\n     print(\"Project name: {p}\".format(p=p.name))\n\nprint(\"Issues\")\nfor i in main_group.issues.list(state='opened'):\n    print(\"Issue title: {t}\".format(t=i.title))\n\nprint(\"Epics\")\nfor e in main_group.issues.list():\n    print(\"Epic title: {t}\".format(t=e.title))\n\nprint(\"Todos\")\nfor t in gl.todos.list(state='pending'):\n    print(\"Todo: {t} url: {u}\".format(t=t.body, u=t.target_url\n\n```\n\nDu kannst das Skript [`python_gitlab_object_manager_methods.py`](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/python_gitlab_object_manager_methods.py) ausführen, indem du die GROUP_ID-Variable auf GitLab.com SaaS für deine eigene zu analysierende Gruppe überschreibst. Die Variable GL_SERVER muss für selbstverwaltete Instanzziele angegeben werden. GL_TOKEN muss das persönliche Zugriffstoken enthalten.\n\n```shell\nexport GL_TOKEN=xxx\n\nexport GL_SERVER=”https://gitlab.company.com”\n\nexport GL_SERVER=”https://gitlab.com”\n\nexport GL_GROUP_ID=1234\n\npython3 python_gitlab_object_manager_methods.py\n```\nIn Zukunft werden die Beispiel-Snippets die Python-Header und das Parsen von Umgebungsvariablen nicht mehr zeigen, um sich auf den Algorithmus und die Funktionalität zu konzentrieren. Alle Skripte sind Open Source unter der MIT-Lizenz und in [diesem Projekt](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python) verfügbar.\n\n### Paginierung der Ergebnisse\n\nStandardmäßig gibt die GitLab-API nicht alle Ergebnissätze zurück und erfordert, dass die Clients die Paginierung verwenden, um durch alle Ergebnisseiten zu iterieren. Mit der python-gitlab-Bibliothek können Benutzer die Einstellungen global im GitLab-Objekt oder bei jedem list()-Aufruf [festlegen](https://python-gitlab.readthedocs.io/en/stable/api-usage.html#pagination). Standardmäßig würden alle Ergebnissätze API-Anfragen auslösen, was die Skriptausführung verlangsamen kann. Die empfohlene Methode ist die Verwendung von iterator=True, die ein Generatorobjekt zurückgibt, und API-Aufrufe werden beim Zugriff auf das Objekt bei Bedarf ausgelöst.\n\nDas folgende Beispiel sucht nach dem Gruppennamen everyonecancontribute und verwendet eine [Paginierung](https://docs.gitlab.com/ee/api/rest/index.html#pagination) der Schlüsselsätze mit 100 Ergebnissen auf jeder Seite. Der Iterator wird bei gl.groups.list(iterator=True) auf true gesetzt, um bei Bedarf neue Ergebnissätze abzurufen. Wird der gesuchte Gruppenname gefunden, bricht die Schleife ab und gibt eine Zusammenfassung aus, einschließlich der Messung der Dauer der gesamten Suchanfrage.\n\n```python\nSEARCH_GROUP_NAME=\"everyonecancontribute\"\n\n# Use keyset pagination\n# https://python-gitlab.readthedocs.io/en/stable/api-usage.html#pagination\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN,\n    pagination=\"keyset\", order_by=\"id\", per_page=100)\n\n# Iterate over the list, and fire new API calls in case the result set does not match yet\ngroups = gl.groups.list(iterator=True)\n\nfound_page = 0\nstart = timer()\n\nfor group in groups:\n    if SEARCH_GROUP_NAME == group.name:\n        # print(group) # debug\n        found_page = groups.current_page\n        break\n\nend = timer()\n\nduration = f'{end-start:.2f}'\n\nif found_page > 0:\n    print(\"Pagination API example for Python with GitLab{desc} - found group {g} on page {p}, duration {d}s\".format(\n        desc=\", the DevSecOps platform\", g=SEARCH_GROUP_NAME, p=found_page, d=duration))\nelse:\n    print(\"Could not find group name '{g}', duration {d}\".format(g=SEARCH_GROUP_NAME, d=duration))\n\n```\n\nBeim Ausführen von python_gitlab_pagination.py wurde die Gruppe [everyonecancontribute](https://gitlab.com/everyonecancontribute) auf Seite 5 gefunden.\n\n```shell\n$ python3 python_gitlab_pagination.py\nPagination API example for Python with GitLab, the DevSecOps platform - found group everyonecancontribute on page 5, duration 8.51s\n```\n\n### Arbeiten mit Objektbeziehungen\n\nBei der Arbeit mit Objektbeziehungen – z. B. beim Sammeln aller Projekte in einer bestimmten Gruppe – müssen zusätzliche Schritte unternommen werden. Die zurückgegebenen Projektobjekte enthalten standardmäßig nur begrenzte Attribute. Für verwaltbare Objekte ist ein zusätzlicher get()-Aufruf erforderlich, der das vollständige Projektobjekt von der API im Hintergrund anfordert. Dieser On-Demand-Workflow hilft, Wartezeiten und Datenverkehr zu vermeiden, indem er die sofort zurückgegebenen Attribute reduziert.\n\nDas folgende Beispiel veranschaulicht das Problem, indem es eine Schleife durch alle Projekte in einer Gruppe durchläuft und versucht, die Funktion project.branches.list() aufzurufen, was eine Ausnahme im try/except-Flow auslöst. Im zweiten Beispiel wird ein verwaltbares Projektobjekt ermittelt und der Funktionsaufruf erneut versucht.\n\n```python\n# Main\ngroup = gl.groups.get(GROUP_ID)\n\n# Collect all projects in group and subgroups\nprojects = group.projects.list(include_subgroups=True, all=True)\n\nfor project in projects:\n    # Try running a method on a weak object\n    try:\n       print(\"🤔 Project: {pn} 💡 Branches: {b}\\n\".format(\n        pn=project.name,\n        b=\", \".join([x.name for x in project.branches.list()])))\n    except Exception as e:\n        print(\"Got exception: {e} \\n ===================================== \\n\".format(e=e))\n\n    # Retrieve a full manageable project object\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n    manageable_project = gl.projects.get(project.id)\n\n    # Print a method available on a manageable object\n    print(\"🤔 Project: {pn} 💡 Branches: {b}\\n\".format(\n        pn=manageable_project.name,\n        b=\", \".join([x.name for x in manageable_project.branches.list()])))\n\n```\n\nDer Exception-Handler in der python-gitlab-Bibliothek gibt die Fehlermeldung aus und verlinkt auch auf die Dokumentation. Es ist hilfreich, bei der Fehlersuche zu beachten, dass Objekte möglicherweise nicht verwaltet werden können, wenn du nicht auf Objektattribute oder Funktionsaufrufe zugreifen kannst.\n\n```shell\n$ python3 python_gitlab_manageable_objects.py\n\n🤔 Project: GitLab API Playground 💡 Branches: cicd-demo-automated-comments, docs-mr-approval-settings, main\n\nGot exception: 'GroupProject' object has no attribute 'branches'\n\n\u003Cclass 'gitlab.v4.objects.projects.GroupProject'> was created via a\nlist() call and only a subset of the data may be present. To ensure\nall data is present get the object using a get(object.id) call. For\nmore details, see:\n\nhttps://python-gitlab.readthedocs.io/en/v3.8.1/faq.html#attribute-error-list\n =====================================\n\n```\n\nHier findest du das vollständige [Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/python_gitlab_manageable_objects.py).\n\n### Arbeiten mit verschiedenen Objektsammlungsbereichen\n\nManchmal muss das Skript alle Projekte aus einer selbstverwalteten Instanz, aus einer Gruppe mit Untergruppen oder aus einem einzelnen Projekt sammeln. Letzteres ist hilfreich, um die erforderlichen Attribute schneller testen zu können, und der Gruppenabruf hilft später beim Testen im großen Maßstab. Das folgende Snippet sammelt alle Projektobjekte in der projects-Liste und fügt Objekte aus verschiedenen eingehenden Konfigurationen hinzu. Du wirst auch wieder das verwaltbare Objektmuster für Projekte in Gruppen sehen.\n\n```python\n\n    # Collect all projects, or prefer projects from a group id, or a project id\n    projects = []\n\n    # Direct project ID\n    if PROJECT_ID:\n        projects.append(gl.projects.get(PROJECT_ID))\n\n    # Groups and projects inside\n    elif GROUP_ID:\n        group = gl.groups.get(GROUP_ID)\n\n        for project in group.projects.list(include_subgroups=True, all=True):\n            # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n            manageable_project = gl.projects.get(project.id)\n            projects.append(manageable_project)\n\n    # All projects on the instance (may take a while to process)\n    else:\n        projects = gl.projects.list(get_all=True)\n\n```\n\nDas vollständige Beispiel befindet sich in [diesem Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_mr_approval_rules.py) für die Auflistung der Einstellungen der MR-Genehmigungsregeln für bestimmte Projektziele.\n\n## DevSecOps-Anwendungsfälle für API-Leseaktionen\n\nDas authentifizierte Zugriffstoken benötigt den Bereich [`read_api` scope](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-token-scopes).\n\nDie folgenden Anwendungsfälle werden diskutiert:\n\n- Zweige nach Zusammenführungsstatus auflisten\n- Drucken von Projekteinstellungen zur Überprüfung: MR-Genehmigungsregeln\n- Inventarisierung: Abrufen aller CI/CD-Variablen, die geschützt oder maskiert sind\n- Herunterladen einer Datei aus dem Repository\n- Hilfe zur Migration: Auflistung aller zertifikatsbasierten Kubernetes-Cluster\n- Team-Effizienz: Prüfen Sie, ob bestehende Merge-Requests nach dem Mergen einer großen Refactoring-MR neu gebasht werden müssen\n\n### Zweige nach Zusammenführungsstatus auflisten\n\nEin häufiges Anliegen ist es, in einem Projekt ein wenig Git-Housekeeping zu betreiben und zu sehen, wie viele zusammengeführte und nicht zusammengeführte Zweige im Umlauf sind. Eine [Frage](https://forum.gitlab.com/t/python-gitlab-project-branch-list-filter/80257) im GitLab-Community-Forum zum Filtern von Zweiglisten hat mich dazu inspiriert, ein [Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_branches_by_state.py) zu schreiben, mit dem sich dieses Ziel erreichen lässt. Die Methode branches.list() gibt alle Zweigobjekte zurück, die in einer temporären Liste für die spätere Verarbeitung in zwei Schleifen gespeichert werden: Sammeln der Namen der zusammengeführten Zweige und der Namen der nicht zusammengeführten Zweige. Das Attribut merged des branch-Objekts ist ein boolescher Wert, der angibt, ob der Zweig zusammengeführt wurde.\n\n```python\nproject = gl.projects.get(PROJECT_ID, lazy=False, pagination=\"keyset\", order_by=\"updated_at\", per_page=100)\n\n# Get all branches\nreal_branches = []\nfor branch in project.branches.list():\n    real_branches.append(branch)\n\nprint(\"All branches\")\nfor rb in real_branches:\n    print(\"Branch: {b}\".format(b=rb.name))\n\n# Get all merged branches\nmerged_branches_names = []\nfor branch in real_branches:\n    if branch.default:\n        continue # ignore the default branch for merge status\n\n    if branch.merged:\n        merged_branches_names.append(branch.name)\n\nprint(\"Branches merged: {b}\".format(b=\", \".join(merged_branches_names)))\n\n# Get un-merged branches\nnot_merged_branches_names = []\nfor branch in real_branches:\n    if branch.default:\n        continue # ignore the default branch for merge status\n\n    if not branch.merged:\n        not_merged_branches_names.append(branch.name)\n\nprint(\"Branches not merged: {b}\".format(b=\", \".join(not_merged_branches_names)))\n```\n\nDer Arbeitsablauf ist absichtlich schrittweise zu lesen. Du kannst die Optimierung des Python-Codes für die bedingte Zweignamensammlung üben.\n\n### Drucken von Projekteinstellungen zur Überprüfung: MR-Genehmigungsregeln\n\nDas folgende [Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_mr_approval_rules.py) geht durch alle gesammelten Projektobjekte und prüft, ob Genehmigungsregeln angegeben sind. Wenn die Länge der Liste größer als Null ist, durchläuft es die Liste in einem Loop und druckt die Einstellungen mit einer JSON-Ph pretty-print-Methode aus.\n\n```python\n\n    # Loop over projects and print the settings\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/merge_request_approvals.html\n    for project in projects:\n        if len(project.approvalrules.list()) > 0:\n            #print(project) #debug\n            print(\"# Project: {name}, ID: {id}\\n\\n\".format(name=project.name_with_namespace, id=project.id))\n            print(\"[MR Approval settings]({url}/-/settings/merge_requests)\\n\\n\".format(url=project.web_url))\n\n            for ar in project.approvalrules.list():\n                print(\"## Approval rule: {name}, ID: {id}\".format(name=ar.name, id=ar.id))\n                print(\"\\n```json\\n\")\n                print(json.dumps(ar.attributes, indent=2)) # TODO: can be more beautiful, but serves its purpose with pretty print JSON\n                print(\"\\n```\\n\")\n\n```\n\n### Inventarisierung: Abrufen aller CI/CD-Variablen, die geschützt oder maskiert sind\n\n[CI/CD Variablen](https://docs.gitlab.com/ee/ci/variables/) sind hilfreich für die Pipeline-Parametrisierung und können global auf der Instanz, in Gruppen und in Projekten konfiguriert werden. Auch Daten, Passwörter und andere sensible Informationen können dort gespeichert werden. Manchmal kann es notwendig sein, sich einen Überblick über alle CI/CD-Variablen zu verschaffen, die entweder geschützt oder maskiert sind, um ein Gefühl dafür zu bekommen, wie viele Variablen aktualisiert werden müssen, wenn Token zum Beispiel rotieren.\n\nDas folgende [Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_all_cicd_variables_masked_or_protected.py) ruft alle Gruppen und Projekte ab und versucht, die CI/CD-Variablen der globalen Instanz (erfordert Admin-Rechte), der Gruppen und Projekte (erfordert Maintainer-/Eigentümer-Rechte) zu sammeln. Es gibt alle CI/CD-Variablen aus, die entweder geschützt oder maskiert sind, und fügt hinzu, dass ein möglicher geheimer Wert gespeichert ist.\n\n```python\n#!/usr/bin/env python\n\nimport gitlab\nimport os\nimport sys\n\n# Helper function to evaluate secrets and print the variables\ndef eval_print_var(var):\n    if var.protected or var.masked:\n        print(\"🛡️🛡️🛡️ Potential secret: Variable '{name}', protected {p}, masked: {m}\".format(name=var.key,p=var.protected,m=var.masked))\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\nGITLAB_TOKEN = os.environ.get('GL_TOKEN') # token requires maintainer+ permissions. Instance variables require admin access.\nPROJECT_ID = os.environ.get('GL_PROJECT_ID') #optional\nGROUP_ID = os.environ.get('GL_GROUP_ID', 8034603) # https://gitlab.com/everyonecancontribute\n\nif not GITLAB_TOKEN:\n    print(\"🤔 Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n# Collect all projects, or prefer projects from a group id, or a project id\nprojects = []\n# Collect all groups, or prefer group from a group id\ngroups = []\n\n# Direct project ID\nif PROJECT_ID:\n    projects.append(gl.projects.get(PROJECT_ID))\n\n# Groups and projects inside\nelif GROUP_ID:\n    group = gl.groups.get(GROUP_ID)\n\n    for project in group.projects.list(include_subgroups=True, all=True):\n        # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n        manageable_project = gl.projects.get(project.id)\n        projects.append(manageable_project)\n\n    groups.append(group)\n\n# All projects/groups on the instance (may take a while to process, use iterators to fetch on-demand).\nelse:\n    projects = gl.projects.list(iterator=True)\n    groups = gl.groups.list(iterator=True)\n\nprint(\"# List of all CI/CD variables marked as secret (instance, groups, projects)\")\n\n# https://python-gitlab.readthedocs.io/en/stable/gl_objects/variables.html\n\n# Instance variables (if the token has permissions)\nprint(\"Instance variables, if accessible\")\ntry:\n    for i_var in gl.variables.list(iterator=True):\n        eval_print_var(i_var)\nexcept:\n    print(\"No permission to fetch global instance variables, continueing without.\")\n    print(\"\\n\")\n\n# group variables (maintainer permissions for groups required)\nfor group in groups:\n    print(\"Group {n}, URL: {u}\".format(n=group.full_path, u=group.web_url))\n    for g_var in group.variables.list(iterator=True):\n        eval_print_var(g_var)\n\n    print(\"\\n\")\n\n# Loop over projects and print the settings\nfor project in projects:\n    # skip archived projects, they throw 403 errors\n    if project.archived:\n        continue\n\n    print(\"Project {n}, URL: {u}\".format(n=project.path_with_namespace, u=project.web_url))\n    for p_var in project.variables.list(iterator=True):\n        eval_print_var(p_var)\n\n    print(\"\\n\")\n\n```\nDas Skript druckt die Variablenwerte absichtlich nicht aus; dies soll als Übung für sichere Umgebungen dienen. Für die Speicherung von Daten empfiehlt sich die Verwendung [externer Anbieter](https://docs.gitlab.com/ee/ci/secrets/).\n\n### Herunterladen einer Datei aus dem Repository\n\nZiel des [Skripts](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_raw_file_content.py) ist es, einen Dateipfad von einem angegebenen Verzweigungsnamen herunterzuladen und dessen Inhalt in einer neuen Datei zu speichern.\n\n```python\n# Goal: Try to download README.md from https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/README.md\nFILE_NAME = 'README.md'\nBRANCH_NAME = 'main'\n\n# Search the file in the repository tree and get the raw blob\nfor f in project.repository_tree():\n    print(\"File path '{name}' with id '{id}'\".format(name=f['name'], id=f['id']))\n\n    if f['name'] == FILE_NAME:\n        f_content = project.repository_raw_blob(f['id'])\n        print(f_content)\n\n# Alternative approach: Get the raw file from the main branch\nraw_content = project.files.raw(file_path=FILE_NAME, ref=BRANCH_NAME)\nprint(raw_content)\n\n# Store the file on disk\nwith open('raw_README.md', 'wb') as f:\n    project.files.raw(file_path=FILE_NAME, ref=BRANCH_NAME, streamed=True, action=f.write)\n\n```\n\n### Hilfe zur Migration: Auflistung aller zertifikatsbasierten Kubernetes-Cluster\n\nDie zertifikatsbasierte Integration von Kubernetes-Clustern in GitLab wurde [abgeschafft](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes). Um Migrationspläne zu unterstützen, kann die Erfassung bestehender Gruppen und Projekte mithilfe der GitLab-API automatisiert werden.\n\n```python\ngroups = [ ]\n\n# get GROUP_ID group\ngroups.append(gl.groups.get(GROUP_ID))\n\nfor group in groups:\n    for sg in group.subgroups.list(include_subgroups=True, all=True):\n        real_group = gl.groups.get(sg.id)\n        groups.append(real_group)\n\ngroup_clusters = {}\nproject_clusters = {}\n\nfor group in groups:\n    #Collect group clusters\n    g_clusters = group.clusters.list()\n\n    if len(g_clusters) > 0:\n        group_clusters[group.id] = g_clusters\n\n    # Collect all projects in group and subgroups and their clusters\n    projects = group.projects.list(include_subgroups=True, all=True)\n\n    for project in projects:\n        # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n        manageable_project = gl.projects.get(project.id)\n\n        # skip archived projects\n        if project.archived:\n            continue\n\n        p_clusters = manageable_project.clusters.list()\n\n        if len(p_clusters) > 0:\n            project_clusters[project.id] = p_clusters\n\n# Print summary\nprint(\"## Group clusters\\n\\n\")\nfor g_id, g_clusters in group_clusters.items():\n    url = gl.groups.get(g_id).web_url\n    print(\"Group ID {g_id}: {u}\\n\\n\".format(g_id=g_id, u=url))\n    print_clusters(g_clusters)\n\nprint(\"## Project clusters\\n\\n\")\nfor p_id, p_clusters in project_clusters.items():\n    url = gl.projects.get(p_id).web_url\n    print(\"Project ID {p_id}: {u}\\n\\n\".format(p_id=p_id, u=url))\n    print_clusters(p_clusters)\n\n```\n\nHier findest du das vollständige [Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/list_cert_based_kubernetes_clusters.py).\n\n### Team-Effizienz: Prüfe, ob bestehende Merge-Requests nach dem Mergen einer großen Refactoring-MR neu gebasht werden müssen\n\nDas [GitLab-Handbuch-Repository](https://handbook.gitlab.com/handbook/) ist ein großes Monorepo mit zahlreichen Merge-Requests, die erstellt, geprüft, genehmigt und zusammengeführt werden müssen. Einige Prüfungen dauern länger als andere, insbesondere wenn Zusammenführungsanfragen mehrere Seiten betreffen, beispielsweise wenn ein String umbenannt wird oder Änderungen auf [alle](https://handbook.gitlab.com/handbook/about/#count-handbook-pages) Handbuchseiten ausgedehnt werden. Das Marketing-Handbuch wurde umstrukturiert, was zu vielen Verschiebungen oder Umbenennungen von Verzeichnissen und Pfaden führte.\n\nMit der Zeit nahmen die Issues zu, und es bestand die Sorge, dass andere Merge-Anfragen nach dem Zusammenführen der großen Änderungen auf Konflikte stoßen könnten. Es wurde festgestellt, dass Python-Gitlab in der Lage ist, alle Merge-Requests in einem bestimmten Projekt abzurufen, einschließlich Details über den Git-Zweig, geänderte Quellpfade und vieles mehr.\n\nDas daraus resultierende Skript konfiguriert eine Liste von Quellpfaden, die von allen pythongitlab-Merge-Requests berührt werden, und vergleicht die Diffs der Merge-Requests mit mr.diffs.list(), um festzustellen, ob ein Muster mit dem Wert in old_path. übereinstimmt. Bei einer Übereinstimmung protokolliert das Skript diese und speichert die Zusammenführungsanforderung im seen_mr-Wörterbuch für die spätere Zusammenfassung. Zusätzlich werden Attribute gesammelt, um eine Markdown-Aufgabenliste mit URLs zum leichteren Einfügen in Issue-Beschreibungen zu erstellen.\n\n```python\nPATH_PATTERNS = [\n    'path/to/handbook/source/page.md',\n]\n\n# Only list opened MRs\n# https://python-gitlab.readthedocs.io/en/stable/gl_objects/merge_requests.html#project-merge-requests\nmrs = project.mergerequests.list(state='opened', iterator=True)\n\nseen_mr = {}\n\nfor mr in mrs:\n    # https://docs.gitlab.com/ee/api/merge_requests.html#list-merge-request-diffs\n    real_mr = project.mergerequests.get(mr.get_id())\n    real_mr_id = real_mr.attributes['iid']\n    real_mr_url = real_mr.attributes['web_url']\n\n    for diff in real_mr.diffs.list(iterator=True):\n        real_diff = real_mr.diffs.get(diff.id)\n\n        for d in real_diff.attributes['diffs']:\n            for p in PATH_PATTERNS:\n                if p in d['old_path']:\n                    print(\"MATCH: {p} in MR {mr_id}, status '{s}', title '{t}' - URL: {mr_url}\".format(\n                        p=p,\n                        mr_id=real_mr_id,\n                        s=mr_status,\n                        t=real_mr.attributes['title'],\n                        mr_url=real_mr_url))\n\n                    if not real_mr_id in seen_mr:\n                        seen_mr[real_mr_id] = real_mr\n\nprint(\"\\n# MRs to update\\n\")\n\nfor id, real_mr in seen_mr.items():\n    print(\"- [ ] !{mr_id} - {mr_url}+ Status: {s}, Title: {t}\".format(\n        mr_id=id,\n        mr_url=real_mr.attributes['web_url'],\n        s=real_mr.attributes['detailed_merge_status'],\n        t=real_mr.attributes['title']))\n\n```\n\n## DevSecOps-Anwendungsfälle für API-Schreibaktionen\n\nDas authentifizierte Zugriffstoken benötigt den vollen Anwendungsbereich der [`api`](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-token-scopes).\n\nDie folgenden Anwendungsfälle werden diskutiert:\n\n- Verschieben von Epics zwischen Gruppen\n- Compliance: Sicherstellen, dass Projekteinstellungen nicht überschrieben werden\n- Notizen machen, Fälligkeitsübersicht erstellen\n\n### Verschieben von Epics zwischen Gruppen\n\nManchmal ist es erforderlich, Epics, ähnlich wie Issues, in eine andere Gruppe zu verschieben. Eine Frage im GitLab-Marketing-Slack-Kanal hat dazu geführt, einen [Funktionsvorschlag](https://gitlab.com/gitlab-org/gitlab/-/issues/12689) für die Benutzeroberfläche und die [Schnellaktionen](/blog/improve-your-gitlab-productivity-with-these-10-tips/) zu prüfen und später über das Schreiben eines API-Skripts nachzudenken, um die Schritte zu automatisieren.\n\n### Automatisierung des Verschiebens von Epics\n\nDie Idee ist einfach: Ein Epic wird von einer Quellgruppe in eine Zielgruppe verschoben, wobei Titel, Beschreibung und Labels kopiert werden. Da Epics es erlauben, Themen zu gruppieren, müssen sie auch dem Ziel-Epic neu zugewiesen werden. Parent-Child-Epic-Relationships müssen dabei berücksichtigt werden: Alle Child-Epics der Quell-Epics müssen dem Ziel-Epic neu zugewiesen werden.\n\nDas folgende Skript sucht zunächst alle [Attribute](https://python-gitlab.readthedocs.io/en/stable/gl_objects/epics.html) des Quellepos und erstellt dann ein neues Zielepos mit den minimalen Attributen: Titel und Beschreibung. Die Liste der Bezeichnungen wird kopiert und die Änderungen werden mit dem save()-Aufruf beibehalten. Die Ausgaben, die dem Epos zugeordnet sind, müssen im Zielepos neu erstellt werden.\n\nDer create()-Aufruf erzeugt das Beziehungselement und nicht ein neues Issue-Objekt selbst. Das Verschieben von Child-Epics erfordert einen anderen Ansatz, da die Beziehung umgekehrt ist: Die parent_id des Child-Epics muss mit der ID des Quell-Epics verglichen und bei Übereinstimmung auf die ID des Ziel-Epics aktualisiert werden. Nachdem alles erfolgreich kopiert wurde, muss das Quell-Epos in den closed-Zustand versetzt werden.\n\n```python\n#!/usr/bin/env python\n\n# Description: Show how epics can be moved between groups, including title, description, labels, child epics and issues.\n# Requirements: python-gitlab Python libraries. GitLab API write access, and maintainer access to all configured groups/projects.\n# Author: Michael Friedrich \u003Cmfriedrich@gitlab.com>\n# License: MIT, (c) 2023-present GitLab B.V.\n\nimport gitlab\nimport os\nimport sys\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n# https://gitlab.com/gitlab-da/use-cases/gitlab-api\nSOURCE_GROUP_ID = os.environ.get('GL_SOURCE_GROUP_ID', 62378643)\n# https://gitlab.com/gitlab-da/use-cases/gitlab-api/epic-move-target\nTARGET_GROUP_ID = os.environ.get('GL_TARGET_GROUP_ID', 62742177)\n# https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/-/epics/1\nEPIC_ID = os.environ.get('GL_EPIC_ID', 1)\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n# Main\n# Goal: Move epic to target group, including title, body, labels, and child epics and issues.\nsource_group = gl.groups.get(SOURCE_GROUP_ID)\ntarget_group = gl.groups.get(TARGET_GROUP_ID)\n\n# Create a new target epic and copy all its items, then close the source epic.\nsource_epic = source_group.epics.get(EPIC_ID)\n# print(source_epic) #debug\n\nepic_title = source_epic.title\nepic_description = source_epic.description\nepic_labels = source_epic.labels\nepic_issues = source_epic.issues.list()\n\n# Create the epic with minimal attributes\ntarget_epic = target_group.epics.create({\n    'title': epic_title,\n    'description': epic_description,\n})\n\n# Assign the list\ntarget_epic.labels = epic_labels\n\n# Persist the changes in the new epic\ntarget_epic.save()\n\n# Epic issues need to be re-assigned in a loop\nfor epic_issue in epic_issues:\n    ei = target_epic.issues.create({'issue_id': epic_issue.id})\n\n# Child epics need to update their parent_id to the new epic\n# Need to search in all epics, use lazy object loading\nfor sge in source_group.epics.list(lazy=True):\n    # this epic has the source epic as parent epic?\n    if sge.parent_id == source_epic.id:\n        # Update the parent id\n        sge.parent_id = target_epic.id\n        sge.save()\n\nprint(\"Copied source epic {source_id} ({source_url}) to target epic {target_id} ({target_url})\".format(\n    source_id=source_epic.id, source_url=source_epic.web_url,\n    target_id=target_epic.id, target_url=target_epic.web_url))\n\n# Close the old epic\nsource_epic.state_event = 'close'\nsource_epic.save()\nprint(\"Closed source epic {source_id} ({source_url})\".format(\n    source_id=source_epic.id, source_url=source_epic.web_url))\n\n```\n\n```shell\n$  python3 move_epic_between_groups.py\nCopied source epic 725341 (https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/-/epics/1) to target epic 725358 (https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/epic-move-target/-/epics/6)\nClosed source epic 725341 (https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/-/epics/1)\n```\n\nDas [Ziel-Epic](https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/epic-move-target/-/epics/5) wurde erstellt und zeigt das erwartete Ergebnis: Derselbe Titel, dieselbe Beschreibung, dieselben Bezeichnungen, dasselbe untergeordnete Epic und dieselben Issues.\n\n![Target epic which has all attributes copied from the source epic: title, description, labels, child epics, issues](https://about.gitlab.com/images/blogimages/efficient-devsecops-workflows-python-gitlab-handson/python_gitlab_moved_epic_with_all_attributes.png){: .shadow}\n\n**Übung:** Das Skript kopiert noch keine [Kommentare](https://python-gitlab.readthedocs.io/en/stable/gl_objects/notes.html) und [Diskussionsstränge](https://python-gitlab.readthedocs.io/en/stable/gl_objects/discussions.html). Recherchiere und hilf mit, das Skript zu aktualisieren – Merge-Requests willkommen!\n\n### Compliance: Sicherstellen, dass Projekteinstellungen nicht überschrieben werden\n\nProjekt- und Gruppeneinstellungen können versehentlich von Teammitgliedern mit Administratorrechten geändert werden. Die Compliance-Anforderungen müssen erfüllt werden. Ein weiterer Anwendungsfall ist die Verwaltung der Konfiguration mit Infrastructure-as-Code-Tools, um sicherzustellen, dass die Konfiguration von GitLab-Instanzen, -Gruppen, -Projekten usw. erhalten bleibt und immer dieselbe ist. Tools wie Ansible oder Terraform können ein API-Skript aufrufen oder die Python-GitLab-Bibliothek verwenden, um Aufgaben zur Verwaltung von Einstellungen auszuführen.\n\nIm folgenden Beispiel ist nur der main-Zweig geschützt.\n\n![GitLab project settings for repositories and protected branches, main branch](https://about.gitlab.com/images/blogimages/efficient-devsecops-workflows-python-gitlab-handson/python_gitlab_protected_branches_settings_main.png){: .shadow}\n\nNehmen wir an, dass ein neuer production-Zweig hinzugefügt wurde und ebenfalls geschützt werden soll. Das folgende [Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/enforce_protected_branches.py) definiert das Wörterbuch der geschützten Zweige und ihre Zugriffsebenen für Push-/Merge-Berechtigungen auf Maintainer-Ebene und baut die Vergleichslogik auf der Grundlage der [python-gitlab-Dokumentation](https://python-gitlab.readthedocs.io/en/stable/gl_objects/protected_branches.html) zu geschützten Zweigen auf.\n\n```python\n#!/usr/bin/env python\n\nimport gitlab\nimport os\nimport sys\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n# https://gitlab.com/gitlab-da/use-cases/\nGROUP_ID = os.environ.get('GL_GROUP_ID', 16058698)\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\nPROTECTED_BRANCHES = {\n    'main': {\n        'merge_access_level': gitlab.const.AccessLevel.MAINTAINER,\n        'push_access_level': gitlab.const.AccessLevel.MAINTAINER\n    },\n    'production': {\n        'merge_access_level': gitlab.const.AccessLevel.MAINTAINER,\n        'push_access_level': gitlab.const.AccessLevel.MAINTAINER\n    },\n}\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n# Main\ngroup = gl.groups.get(GROUP_ID)\n\n# Collect all projects in group and subgroups\nprojects = group.projects.list(include_subgroups=True, all=True)\n\nfor project in projects:\n    # Retrieve a full manageable project object\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n    manageable_project = gl.projects.get(project.id)\n\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/protected_branches.html\n    protected_branch_names = []\n\n    for pb in manageable_project.protectedbranches.list():\n        manageable_protected_branch = manageable_project.protectedbranches.get(pb.name)\n        print(\"Protected branch name: {n}, merge_access_level: {mal}, push_access_level: {pal}\".format(\n            n=manageable_protected_branch.name,\n            mal=manageable_protected_branch.merge_access_levels,\n            pal=manageable_protected_branch.push_access_levels\n        ))\n\n        protected_branch_names.append(manageable_protected_branch.name)\n\n    for branch_to_protect, levels in PROTECTED_BRANCHES.items():\n        # Fix missing protected branches\n        if branch_to_protect not in protected_branch_names:\n            print(\"Adding branch {n} to protected branches settings\".format(n=branch_to_protect))\n            p_branch = manageable_project.protectedbranches.create({\n                'name': branch_to_protect,\n                'merge_access_level': gitlab.const.AccessLevel.MAINTAINER,\n                'push_access_level': gitlab.const.AccessLevel.MAINTAINER\n            })\n\n```\n\nWenn das Skript ausgeführt wird, werden der bestehende main-Zweig und ein Hinweis, dass die production aktualisiert wird, ausgegeben. Der Screenshot aus den Repository-Einstellungen verdeutlicht diese Aktion.\n\n```shell\n$ python3 enforce_protected_branches.py ─╯\nProtected branch name: main, merge_access_level: [{'id': 67294702, 'access_level': 40, 'access_level_description': 'Maintainers', 'user_id': None, 'group_id': None}], push_access_level: [{'id': 68546039, 'access_level': 40, 'access_level_description': 'Maintainers', 'user_id': None, 'group_id': None}]\nAdding branch production to protected branches settings\n```\n\n![GitLab project settings for repositories and protected branches, main and production branch](https://about.gitlab.com/images/blogimages/efficient-devsecops-workflows-python-gitlab-handson/python_gitlab_protected_branches_settings_main_production.png){: .shadow}\n\n### Notizen machen, Fälligkeitsübersicht erstellen\n\nEine Diskussion auf [Hacker News](https://news.ycombinator.com/item?id=32155848) über Tools zum Erstellen von Notizen hat mich dazu inspiriert, eine Übersicht in Form einer Markdown-Tabelle zu erstellen, die aus Dateien, die Notizen aufnehmen, geholt und nach dem geparsten Fälligkeitsdatum sortiert wird. Das [Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/generate_snippets_index_by_due_date.py) ist hier zu finden und etwas komplexer zu verstehen.\n\n\u003C!--\n# 2022-07-19 Notes\n\nHN topic about taking notes: https://news.ycombinator.com/item?id=32152935\n\n-->\n\n***Die englischsprachige [Originalversion](https://about.gitlab.com/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation/) dieses Artikels wurde bereits aktualisiert und erhält einige weitere Tipps, welche wir der deutschen Version beizeiten hinzufügen werden.***\n",[23,24,25,26],"integrations","tutorial","DevSecOps","DevSecOps platform","2025-05-16","yml",{},true,"/de-de/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":12,"ogImage":19,"ogUrl":33,"ogSiteName":34,"ogType":35,"canonicalUrls":33},"https://about.gitlab.com/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation","https://about.gitlab.com","article","de-de/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation",[23,24,38,39],"devsecops","devsecops-platform","dI6wpygXcbqKYuGFzrGajUildwjBwWyB4uKtDHp0mzE",{"data":42},{"logo":43,"freeTrial":48,"sales":53,"login":58,"items":63,"search":371,"minimal":406,"duo":424,"pricingDeployment":433},{"config":44},{"href":45,"dataGaName":46,"dataGaLocation":47},"/de-de/","gitlab logo","header",{"text":49,"config":50},"Kostenlose Testversion anfordern",{"href":51,"dataGaName":52,"dataGaLocation":47},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":54,"config":55},"Vertrieb kontaktieren",{"href":56,"dataGaName":57,"dataGaLocation":47},"/de-de/sales/","sales",{"text":59,"config":60},"Anmelden",{"href":61,"dataGaName":62,"dataGaLocation":47},"https://gitlab.com/users/sign_in/","sign in",[64,91,187,192,292,352],{"text":65,"config":66,"cards":68},"Plattform",{"dataNavLevelOne":67},"platform",[69,75,83],{"title":65,"description":70,"link":71},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":72,"config":73},"Erkunde unsere Plattform",{"href":74,"dataGaName":67,"dataGaLocation":47},"/de-de/platform/",{"title":76,"description":77,"link":78},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":79,"config":80},"Lerne GitLab Duo kennen",{"href":81,"dataGaName":82,"dataGaLocation":47},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":84,"description":85,"link":86},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":87,"config":88},"Mehr erfahren",{"href":89,"dataGaName":90,"dataGaLocation":47},"/de-de/why-gitlab/","why gitlab",{"text":92,"left":30,"config":93,"link":95,"lists":99,"footer":169},"Produkt",{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"Alle Lösungen anzeigen",{"href":98,"dataGaName":94,"dataGaLocation":47},"/de-de/solutions/",[100,125,147],{"title":101,"description":102,"link":103,"items":108},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":47},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[109,113,116,121],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":47,"dataGaName":110},"/de-de/solutions/continuous-integration/",{"text":76,"config":114},{"href":81,"dataGaLocation":47,"dataGaName":115},"gitlab duo agent platform - product menu",{"text":117,"config":118},"Quellcodeverwaltung",{"href":119,"dataGaLocation":47,"dataGaName":120},"/de-de/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Automatisierte Softwarebereitstellung",{"href":106,"dataGaLocation":47,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":47,"icon":132},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"Application Security Testing",{"href":130,"dataGaName":137,"dataGaLocation":47},"Application security testing",{"text":139,"config":140},"Schutz der Software-Lieferkette",{"href":141,"dataGaLocation":47,"dataGaName":142},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":47},"/de-de/solutions/software-compliance/",{"title":148,"link":149,"items":154},"Bewertung",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":47},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"Sichtbarkeit und Bewertung",{"href":152,"dataGaLocation":47,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Wertstrommanagement",{"href":162,"dataGaLocation":47,"dataGaName":163},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"Analysen und Einblicke",{"href":167,"dataGaLocation":47,"dataGaName":168},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab für",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":47,"dataGaName":176},"/de-de/enterprise/","enterprise",{"text":178,"config":179},"Kleinunternehmen",{"href":180,"dataGaLocation":47,"dataGaName":181},"/de-de/small-business/","small business",{"text":183,"config":184},"den öffentlichen Sektor",{"href":185,"dataGaLocation":47,"dataGaName":186},"/de-de/solutions/public-sector/","public sector",{"text":188,"config":189},"Preise",{"href":190,"dataGaName":191,"dataGaLocation":47,"dataNavLevelOne":191},"/de-de/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":279},"Ressourcen",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"Alle Ressourcen anzeigen",{"href":199,"dataGaName":195,"dataGaLocation":47},"/de-de/resources/",[201,233,251],{"title":202,"items":203},"Erste Schritte",[204,209,214,219,224,229],{"text":205,"config":206},"Installieren",{"href":207,"dataGaName":208,"dataGaLocation":47},"/de-de/install/","install",{"text":210,"config":211},"Kurzanleitungen",{"href":212,"dataGaName":213,"dataGaLocation":47},"/de-de/get-started/","quick setup checklists",{"text":215,"config":216},"Lernen",{"href":217,"dataGaLocation":47,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Produktdokumentation",{"href":222,"dataGaName":223,"dataGaLocation":47},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Best-Practice-Videos",{"href":227,"dataGaName":228,"dataGaLocation":47},"/de-de/getting-started-videos/","best practice videos",{"text":230,"config":231},"Integrationen",{"href":232,"dataGaName":23,"dataGaLocation":47},"/de-de/integrations/",{"title":234,"items":235},"Entdecken",[236,241,246],{"text":237,"config":238},"Kundenerfolge",{"href":239,"dataGaName":240,"dataGaLocation":47},"/de-de/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":47},"/de-de/blog/","blog",{"text":247,"config":248},"Remote",{"href":249,"dataGaName":250,"dataGaLocation":47},"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":47},"/de-de/services/","services",{"text":260,"config":261},"Community",{"href":262,"dataGaName":263,"dataGaLocation":47},"/community/","community",{"text":265,"config":266},"Forum",{"href":267,"dataGaName":268,"dataGaLocation":47},"https://forum.gitlab.com/","forum",{"text":270,"config":271},"Veranstaltungen",{"href":272,"dataGaName":273,"dataGaLocation":47},"/events/","events",{"text":275,"config":276},"Partner",{"href":277,"dataGaName":278,"dataGaLocation":47},"/de-de/partners/","partners",{"backgroundColor":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 card",{"src":286},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":288,"config":289},"Lies die News",{"href":290,"dataGaName":291,"dataGaLocation":47},"/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":47},"/de-de/company/","about",{"text":305,"config":306,"footerGa":309},"Karriere",{"href":307,"dataGaName":308,"dataGaLocation":47},"/jobs/","jobs",{"dataGaName":308},{"text":270,"config":311},{"href":272,"dataGaName":273,"dataGaLocation":47},{"text":313,"config":314},"Geschäftsführung",{"href":315,"dataGaName":316,"dataGaLocation":47},"/company/team/e-group/","leadership",{"text":318,"config":319},"Team",{"href":320,"dataGaName":321,"dataGaLocation":47},"/company/team/","team",{"text":323,"config":324},"Handbuch",{"href":325,"dataGaName":326,"dataGaLocation":47},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"Investor Relations",{"href":330,"dataGaName":331,"dataGaLocation":47},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"Trust Center",{"href":335,"dataGaName":336,"dataGaLocation":47},"/de-de/security/","trust center",{"text":338,"config":339},"AI Transparency Center",{"href":340,"dataGaName":341,"dataGaLocation":47},"/de-de/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"Newsletter",{"href":345,"dataGaName":346,"dataGaLocation":47},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"Presse",{"href":350,"dataGaName":351,"dataGaLocation":47},"/press/","press",{"text":353,"config":354,"lists":355},"Kontakt",{"dataNavLevelOne":295},[356],{"items":357},[358,361,366],{"text":54,"config":359},{"href":56,"dataGaName":360,"dataGaLocation":47},"talk to sales",{"text":362,"config":363},"Support-Portal",{"href":364,"dataGaName":365,"dataGaLocation":47},"https://support.gitlab.com","support portal",{"text":367,"config":368},"Kundenportal",{"href":369,"dataGaName":370,"dataGaLocation":47},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"Schließen",{"text":374,"link":375},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":376,"config":377},"gitlab.com",{"href":61,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"Vorschläge",[383,385,390,392,397,402],{"text":76,"config":384},{"href":81,"dataGaName":76,"dataGaLocation":379},{"text":386,"config":387},"Code Suggestions (KI)",{"href":388,"dataGaName":389,"dataGaLocation":379},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":110,"config":391},{"href":112,"dataGaName":110,"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":403,"config":404},"Warum GitLab?",{"href":89,"dataGaName":405,"dataGaLocation":379},"Why GitLab?",{"freeTrial":407,"mobileIcon":412,"desktopIcon":417,"secondaryButton":420},{"text":408,"config":409},"Kostenlos testen",{"href":410,"dataGaName":52,"dataGaLocation":411},"https://gitlab.com/-/trials/new/","nav",{"altText":413,"config":414},"GitLab-Symbol",{"src":415,"dataGaName":416,"dataGaLocation":411},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":413,"config":418},{"src":419,"dataGaName":416,"dataGaLocation":411},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":202,"config":421},{"href":422,"dataGaName":423,"dataGaLocation":411},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"Erfahre mehr über GitLab Duo",{"href":81,"dataGaName":428,"dataGaLocation":411},"gitlab duo",{"altText":413,"config":430},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":432},{"src":419,"dataGaName":416,"dataGaLocation":411},{"freeTrial":434,"mobileIcon":439,"desktopIcon":441},{"text":435,"config":436},"Zurück zur Preisübersicht",{"href":190,"dataGaName":437,"dataGaLocation":411,"icon":438},"back to pricing","GoBack",{"altText":413,"config":440},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":442},{"src":419,"dataGaName":416,"dataGaLocation":411},{"title":444,"button":445,"config":450},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":446,"config":447},"GitLab Transcend jetzt ansehen",{"href":448,"dataGaName":449,"dataGaLocation":47},"/de-de/events/transcend/virtual/","transcend event",{"layout":451,"icon":452,"disabled":30},"release","AiStar",{"data":454},{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":650},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":457,"config":458},"Quelltext der Seite anzeigen",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Diese Seite bearbeiten",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Beteilige dich",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,556,583,617],{"title":65,"links":479,"subMenu":484},[480],{"text":481,"config":482},"DevSecOps-Plattform",{"href":74,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":188,"links":486},[487,491,496],{"text":488,"config":489},"Tarife anzeigen",{"href":190,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Vorteile von Premium",{"href":494,"dataGaName":495,"dataGaLocation":461},"/de-de/pricing/premium/","why premium",{"text":497,"config":498},"Vorteile von Ultimate",{"href":499,"dataGaName":500,"dataGaLocation":461},"/de-de/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Lösungen",[504,509,512,514,519,524,528,531,534,539,541,543,546,551],{"text":505,"config":506},"Digitale Transformation",{"href":507,"dataGaName":508,"dataGaLocation":461},"/de-de/topics/digital-transformation/","digital transformation",{"text":510,"config":511},"Sicherheit und Compliance",{"href":130,"dataGaName":137,"dataGaLocation":461},{"text":122,"config":513},{"href":106,"dataGaName":107,"dataGaLocation":461},{"text":515,"config":516},"Agile Entwicklung",{"href":517,"dataGaName":518,"dataGaLocation":461},"/de-de/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Cloud-Transformation",{"href":522,"dataGaName":523,"dataGaLocation":461},"/de-de/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":119,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":110,"config":529},{"href":112,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":160,"config":532},{"href":162,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/de-de/solutions/gitops/","gitops",{"text":173,"config":540},{"href":175,"dataGaName":176,"dataGaLocation":461},{"text":178,"config":542},{"href":180,"dataGaName":181,"dataGaLocation":461},{"text":544,"config":545},"Öffentlicher Sektor",{"href":185,"dataGaName":186,"dataGaLocation":461},{"text":547,"config":548},"Bildungswesen",{"href":549,"dataGaName":550,"dataGaLocation":461},"/de-de/solutions/education/","education",{"text":552,"config":553},"Finanzdienstleistungen",{"href":554,"dataGaName":555,"dataGaLocation":461},"/de-de/solutions/finance/","financial services",{"title":193,"links":557},[558,560,562,564,567,569,571,573,575,577,579,581],{"text":205,"config":559},{"href":207,"dataGaName":208,"dataGaLocation":461},{"text":210,"config":561},{"href":212,"dataGaName":213,"dataGaLocation":461},{"text":215,"config":563},{"href":217,"dataGaName":218,"dataGaLocation":461},{"text":220,"config":565},{"href":222,"dataGaName":566,"dataGaLocation":461},"docs",{"text":242,"config":568},{"href":244,"dataGaName":245,"dataGaLocation":461},{"text":237,"config":570},{"href":239,"dataGaName":240,"dataGaLocation":461},{"text":247,"config":572},{"href":249,"dataGaName":250,"dataGaLocation":461},{"text":255,"config":574},{"href":257,"dataGaName":258,"dataGaLocation":461},{"text":260,"config":576},{"href":262,"dataGaName":263,"dataGaLocation":461},{"text":265,"config":578},{"href":267,"dataGaName":268,"dataGaLocation":461},{"text":270,"config":580},{"href":272,"dataGaName":273,"dataGaLocation":461},{"text":275,"config":582},{"href":277,"dataGaName":278,"dataGaLocation":461},{"title":293,"links":584},[585,587,589,591,593,595,597,601,606,608,610,612],{"text":300,"config":586},{"href":302,"dataGaName":295,"dataGaLocation":461},{"text":305,"config":588},{"href":307,"dataGaName":308,"dataGaLocation":461},{"text":313,"config":590},{"href":315,"dataGaName":316,"dataGaLocation":461},{"text":318,"config":592},{"href":320,"dataGaName":321,"dataGaLocation":461},{"text":323,"config":594},{"href":325,"dataGaName":326,"dataGaLocation":461},{"text":328,"config":596},{"href":330,"dataGaName":331,"dataGaLocation":461},{"text":598,"config":599},"Sustainability",{"href":600,"dataGaName":598,"dataGaLocation":461},"/sustainability/",{"text":602,"config":603},"Vielfalt, Inklusion und Zugehörigkeit",{"href":604,"dataGaName":605,"dataGaLocation":461},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":607},{"href":335,"dataGaName":336,"dataGaLocation":461},{"text":343,"config":609},{"href":345,"dataGaName":346,"dataGaLocation":461},{"text":348,"config":611},{"href":350,"dataGaName":351,"dataGaLocation":461},{"text":613,"config":614},"Transparenzerklärung zu moderner Sklaverei",{"href":615,"dataGaName":616,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":618,"links":619},"Nimm Kontakt auf",[620,623,628,630,635,640,645],{"text":621,"config":622},"Sprich mit einem Experten/einer Expertin",{"href":56,"dataGaName":57,"dataGaLocation":461},{"text":624,"config":625},"Support",{"href":626,"dataGaName":627,"dataGaLocation":461},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":367,"config":629},{"href":369,"dataGaName":370,"dataGaLocation":461},{"text":631,"config":632},"Status",{"href":633,"dataGaName":634,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":636,"config":637},"Nutzungsbedingungen",{"href":638,"dataGaName":639,"dataGaLocation":461},"/terms/","terms of use",{"text":641,"config":642},"Datenschutzerklärung",{"href":643,"dataGaName":644,"dataGaLocation":461},"/de-de/privacy/","privacy statement",{"text":646,"config":647},"Cookie-Einstellungen",{"dataGaName":648,"dataGaLocation":461,"id":649,"isOneTrustButton":30},"cookie preferences","ot-sdk-btn",{"items":651},[652,654,656],{"text":636,"config":653},{"href":638,"dataGaName":639,"dataGaLocation":461},{"text":641,"config":655},{"href":643,"dataGaName":644,"dataGaLocation":461},{"text":646,"config":657},{"dataGaName":648,"dataGaLocation":461,"id":649,"isOneTrustButton":30},[659],{"id":660,"title":18,"body":8,"config":661,"content":663,"description":8,"extension":28,"meta":667,"navigation":30,"path":668,"seo":669,"stem":670,"__hash__":671},"blogAuthors/en-us/blog/authors/michael-friedrich.yml",{"template":662},"BlogAuthor",{"name":18,"config":664},{"headshot":665,"ctfId":666},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659879/Blog/Author%20Headshots/dnsmichi-headshot.jpg","dnsmichi",{},"/en-us/blog/authors/michael-friedrich",{},"en-us/blog/authors/michael-friedrich","lJ-nfRIhdG49Arfrxdn1Vv4UppwD51BB13S3HwIswt4",[673,687,700],{"content":674,"config":685},{"body":675,"title":676,"description":677,"authors":678,"heroImage":680,"date":681,"category":9,"tags":682},"## Abschnitt 1: Das Modell verstehen\n*Für Engineering-Leads und Entscheidungsträger: Konzept, Anwendungsfälle und Architekturprinzipien. Konfigurationsdetails folgen in Abschnitt 2.*\n\nDie meisten CI/CD-Werkzeuge können einen Build ausführen und ein Deployment anstoßen. Der Unterschied zeigt sich erst dann, wenn die Delivery-Anforderungen komplexer werden: ein Monorepo mit einem Dutzend Services, Microservices über mehrere Repositories verteilt, Deployments in Dutzende von Umgebungen gleichzeitig – oder ein Platform-Team, das organisationsweite Standards durchsetzen will, ohne dabei zum Engpass zu werden.\n\nGitLabs Pipeline-Modell wurde für genau diese Komplexität entwickelt. Parent-Child-Pipelines, DAG-Execution, dynamische Pipeline-Generierung, Multi-Project-Trigger, Merge-Request-Pipelines mit Merged-Results-Verarbeitung und CI/CD Components lösen jeweils eine eigene Klasse von Problemen. Da sich diese Bausteine kombinieren lassen, erschließt das vollständige Modell mehr als nur kürzere Pipeline-Laufzeiten.\n\nDieser Artikel beschreibt die fünf Muster, bei denen das Modell seine Stärken deutlich zeigt – jeweils zugeordnet zu einem konkreten Engineering-Szenario. Konfigurationen und Implementierungsdetails folgen in Abschnitt 2.\n\n### 1. Monorepos: Parent-Child-Pipelines und DAG-Execution\n\n**Das Problem:** Ein Monorepo enthält Frontend, Backend und Dokumentation. Jeder Commit löst einen vollständigen Rebuild aller Komponenten aus – auch wenn sich nur eine README-Datei geändert hat.\n\nGitLab kombiniert zwei sich ergänzende Mechanismen: [Parent-Child-Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#parent-child-pipelines) ermöglichen es einer übergeordneten Pipeline, isolierte Child-Pipelines zu starten. [DAG-Execution via `needs`](https://docs.gitlab.com/ci/yaml/#needs) bricht die starre Stage-Reihenfolge auf und startet Jobs, sobald ihre Abhängigkeiten abgeschlossen sind – nicht erst, wenn alle Jobs einer Stage fertig sind.\n\nEine Parent-Pipeline erkennt, welche Teile des Repos sich geändert haben, und löst ausschließlich die betroffenen Child-Pipelines aus. Jeder Service verwaltet seine eigene Pipeline-Konfiguration; Änderungen in einem Service können keine anderen beeinflussen. Damit bleibt die Komplexität beherrschbar, während das Repository und das Team wachsen.\n\nEinen technischen Aspekt gilt es dabei zu kennen: Wenn mehrere Dateien an einen einzelnen `trigger: include:`-Block übergeben werden, fusioniert GitLab sie zu einer einzigen Child-Pipeline-Konfiguration. Jobs aus diesen Dateien teilen denselben Pipeline-Kontext und können sich gegenseitig per `needs:` referenzieren – das ist die Voraussetzung für die DAG-Optimierung. Werden die Dateien stattdessen auf separate Trigger-Jobs aufgeteilt, entsteht jeweils eine isolierte Pipeline, und dateiübergreifende `needs:`-Referenzen funktionieren nicht.\n\nIn großen Monorepos lassen sich Pipeline-Laufzeiten durch DAG-Execution deutlich reduzieren, da Jobs nicht mehr auf unabhängige Arbeitsschritte in derselben Stage warten.\n\n### 2. Microservices: Cross-Repo-Pipelines über mehrere Projekte\n\n**Das Problem:** Frontend und Backend leben in separaten Repositories. Wenn das Frontend-Team eine Änderung ausliefert, ist nicht erkennbar, ob sie die Backend-Integration beeinträchtigt – und umgekehrt.\n\n[Multi-Project-Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#multi-project-pipelines) ermöglichen es, aus einem Projekt heraus eine Pipeline in einem anderen Projekt auszulösen und auf das Ergebnis zu warten. Das auslösende Projekt sieht die verknüpfte Downstream-Pipeline direkt in seiner eigenen Pipeline-Ansicht.\n\nIn der Praxis erstellt die Frontend-Pipeline ein API-Contract-Artifact und veröffentlicht es, bevor die Backend-Pipeline ausgelöst wird. Das Backend ruft dieses Artifact über die [Jobs API](https://docs.gitlab.com/ee/api/jobs.html#download-a-single-artifact-file-from-specific-tag-or-branch) ab und validiert es, bevor weitere Schritte erlaubt sind. Wird eine Breaking Change erkannt, schlägt die Backend-Pipeline fehl – und mit ihr die Frontend-Pipeline. Probleme, die bisher erst in der Produktion sichtbar wurden, werden damit im Pipeline-Prozess abgefangen. Die Abhängigkeit zwischen Services wird sichtbar, nachvollziehbar und aktiv verwaltbar.\n\n![Cross-project pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738762/Blog/Imported/hackathon-fake-blog-post-s/image4_h6mfsb.png \"Cross-project pipelines\") *Cross-project pipelines*\n\n### 3. Multi-Tenant/Matrix-Deployments: Dynamische Child-Pipelines\n\n**Das Problem:** Dieselbe Anwendung wird in 15 Kundenumgebungen, drei Cloud-Regionen oder den Stages Dev/Staging/Prod deployed. Manuelle Anpassungen je Umgebung führen zu Konfigurationsdrift. Eine separate Pipeline pro Umgebung ist von Anfang an nicht wartbar.\n\n[Dynamische Child-Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#dynamic-child-pipelines) generieren die Pipeline-Struktur zur Laufzeit. Ein Job führt ein Skript aus, das eine YAML-Datei erzeugt – und diese YAML-Datei wird zur Pipeline für den nächsten Schritt. Die Pipeline-Struktur selbst wird damit zu Daten.\n\nDas Generierungsskript iteriert über eine `ENVIRONMENTS`-Variable, statt jede Umgebung fest zu kodieren. Eine neue Umgebung lässt sich durch Anpassen der Variable hinzufügen – ohne Änderungen an der Pipeline-Konfiguration selbst. Trigger-Jobs erben mit `extends:` eine gemeinsame Template-Konfiguration, sodass `strategy: depend` einmal definiert und nicht für jeden Trigger-Job wiederholt wird. Ein `when: manual`-Gate für das Produktions-Deployment ist direkt in den Pipeline-Graph integriert.\n\nPlatform-Teams nutzen dieses Muster, um Dutzende von Umgebungen zu verwalten, ohne Pipeline-Logik zu duplizieren.\n\n![Dynamic pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738765/Blog/Imported/hackathon-fake-blog-post-s/image7_wr0kx2.png \"Dynamic pipeline\")\n\n### 4. MR-First-Delivery: Merge-Request-Pipelines, Merged-Results und Workflow-Routing\n\n**Das Problem:** Die Pipeline läuft bei jedem Push auf jeden Branch. Aufwändige Tests werden auf Feature-Branches ausgeführt, die nie gemergt werden. Gleichzeitig gibt es keine Garantie, dass das Getestete dem entspricht, was nach dem Merge auf `main` tatsächlich landet.\n\nGitLab kombiniert drei ineinandergreifende Mechanismen: [Merge-Request-Pipelines](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) laufen ausschließlich dann, wenn ein Merge Request existiert – nicht bei jedem Branch-Push. Allein dadurch entfällt ein erheblicher Anteil unnötiger Compute-Ausführungen. [Merged-Results-Pipelines](https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/) gehen einen Schritt weiter: GitLab erstellt einen temporären Merge-Commit aus dem Branch und dem aktuellen Ziel-Branch und führt die Pipeline dagegen aus. Getestet wird damit das tatsächliche Ergebnis des Merges – nicht der Branch in Isolation. [Workflow-Rules](https://docs.gitlab.com/ci/yaml/workflow/) definieren schließlich, welcher Pipeline-Typ unter welchen Bedingungen ausgeführt wird. Die `$CI_OPEN_MERGE_REQUESTS`-Guard verhindert dabei, dass für einen Branch mit offenem MR doppelte Pipelines ausgelöst werden.\n\nDas Ergebnis ist ein Pipeline-Verhalten, das sich je nach Kontext unterscheidet: Ein Push auf einen Feature-Branch ohne offenen MR führt nur Lint und Unit-Tests aus. Sobald ein MR geöffnet wird, wechseln die Workflow-Rules auf eine MR-Pipeline mit der vollständigen Test-Suite gegen das Merged-Result. Ein Merge auf `main` stellt ein manuelles Produktions-Deployment in die Warteschlange. Der Nightly-Scan läuft einmalig als geplante Pipeline – nicht bei jedem Commit.\n\nMerged-Results-Pipelines fangen dabei die Klasse von Fehlern ab, die erst nach einem Merge sichtbar werden – bevor sie `main` erreichen.\n\n### 5. Governed Pipelines: CI/CD Components\n\n**Das Problem:** Das Platform-Team hat den richtigen Weg für Build, Test und Deploy definiert. Jedes Anwendungsteam pflegt jedoch eine eigene `.gitlab-ci.yml` mit subtilen Abweichungen. Security-Scanning wird übersprungen. Deployment-Standards driften. Audits werden aufwändig.\n\n[CI/CD Components](https://docs.gitlab.com/ci/components/) ermöglichen es Platform-Teams, versionierte, wiederverwendbare Pipeline-Bausteine zu veröffentlichen. Anwendungsteams binden sie mit einer einzigen `include:`-Zeile ein – kein Copy-Paste, kein Drift. Components sind über den [CI/CD Catalog](https://docs.gitlab.com/ci/components/#cicd-catalog) auffindbar, sodass Teams bewährte Bausteine finden und übernehmen können, ohne das Platform-Team direkt einschalten zu müssen.\n\nDrei Zeilen `include:` ersetzen hunderte von duplizierten YAML-Zeilen. Das Platform-Team kann einen Security-Fix in einer neuen Komponentenversion veröffentlichen – Teams steigen auf ihrem eigenen Zeitplan um, oder das Platform-Team fixiert alle auf eine Mindestversion. In beiden Fällen propagiert eine Änderung organisationsweit, statt repo-für-repo angewendet zu werden.\n\nKombiniert mit [Resource Groups](https://docs.gitlab.com/ci/resource_groups/) zur Vermeidung konkurrierender Deployments und [Protected Environments](https://docs.gitlab.com/ci/environments/protected_environments/) für Freigabe-Gates entsteht eine governed Delivery-Plattform, auf der **Compliance der Standard ist, nicht die Ausnahme**. Platform-Teams setzen Vorgaben durch, ohne zum Engpass zu werden.\n\n![Component pipeline (imported jobs)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738776/Blog/Imported/hackathon-fake-blog-post-s/image2_pizuxd.png \"Component pipeline (imported jobs)\")\n\n## Das Modell als Ganzes\n\nKeines dieser Muster existiert isoliert. Der Wert von GitLabs Pipeline-Modell liegt in der Kombinierbarkeit seiner Bausteine:\n\n- Ein Monorepo nutzt Parent-Child-Pipelines, und jede Child-Pipeline nutzt DAG-Execution.\n- Eine Microservices-Plattform nutzt Multi-Project-Pipelines, und jedes Projekt nutzt MR-Pipelines mit Merged-Results.\n- Eine governed Plattform nutzt CI/CD Components, um die obigen Muster organisationsweit zu standardisieren.\n\nDie meisten Teams entdecken eines dieser Muster, wenn sie auf ein konkretes Problem stoßen. Teams, die das vollständige Modell verstehen, entwickeln daraus eine Delivery-Infrastruktur, die tatsächlich abbildet, wie ihre Engineering-Organisation arbeitet – und mit ihr wächst.\n\n## Weitere Muster\n\nDas Pipeline-Modell geht über die fünf vorgestellten Muster hinaus:\n\n- [Review Apps mit dynamischen Umgebungen](https://docs.gitlab.com/ci/environments/) erstellen für jeden Feature-Branch eine Live-Vorschau und räumen sie automatisch auf, wenn der MR geschlossen wird.\n- [Caching- und Artifact-Strategien](https://docs.gitlab.com/ci/caching/) sind nach der strukturellen Arbeit häufig der direkteste Weg zur weiteren Laufzeitoptimierung – ohne die Pipeline-Struktur zu verändern.\n- [Geplante und API-ausgelöste Pipelines](https://docs.gitlab.com/ci/pipelines/schedules/) eignen sich für Workloads, die nicht bei jedem Code-Push laufen sollten: Nightly-Security-Scans, Compliance-Reports und Release-Automatisierung lassen sich als geplante oder [API-ausgelöste](https://docs.gitlab.com/ci/triggers/) Pipelines mit `$CI_PIPELINE_SOURCE`-Routing modellieren.\n\n> [GitLab Ultimate kostenlos testen](https://about.gitlab.com/de-de/free-trial/) und Pipeline-Logik ab heute einsetzen.\n\n## Für deutsche Unternehmen: Regulatorischer Kontext\n\nTeams, die Pipeline-Governance nach Muster 5 einführen, adressieren dabei möglicherweise auch Anforderungen, die regulatorische Frameworks an sichere Softwareentwicklungsprozesse stellen.\n\nCI/CD Components mit erzwungenen Security-Gates könnten Anforderungen an sichere Entwicklungsprozesse betreffen – beispielsweise in Bereichen, die Frameworks wie NIS2, ISO 27001 oder BSI IT-Grundschutz an den Software-Entwicklungslebenszyklus adressieren. Protected Environments und Resource Groups betreffen ähnliche Themen im Bereich Änderungskontrolle und Umgebungstrennung, wie sie in Governance-Frameworks typischerweise explizit formuliert sind.\n\nMulti-Project-Pipelines mit API-Contract-Validierung (Muster 2) schaffen Sichtbarkeit über Service-Abhängigkeiten hinweg – ein Aspekt, den Frameworks zur Lieferkettensicherheit adressieren.\n\nMerged-Results-Pipelines (Muster 4) dokumentieren automatisch, dass das tatsächliche Merge-Ergebnis getestet wurde, nicht nur der Feature-Branch in Isolation. Dies könnte Anforderungen an nachvollziehbare Änderungsprozesse betreffen, wie sie in Change-Management-Kontrollen verschiedener Sicherheitsframeworks formuliert sind.\n\nFür konkrete Compliance-Anforderungen im eigenen regulatorischen Umfeld empfiehlt sich Rücksprache mit entsprechender Fachberatung.\n\n## Abschnitt 2: Konfiguration und Implementierung\n\n*Für Entwicklungsteams und DevOps-Praktiker: ausgewählte Konfigurationsbeispiele zu den Mustern 1, 4 und 5. Für vollständige Konfigurationen aller Muster: [englischer Originalartikel](https://about.gitlab.com/blog/5-ways-gitlab-pipeline-logic-solves-real-engineering-problems/).*\n\nDie folgenden Konfigurationen sind illustrativ aufgebaut. Die Skripte verwenden `echo`-Befehle, um das Wesentliche sichtbar zu halten. Für den produktiven Einsatz werden die `echo`-Befehle durch die tatsächlichen Build-, Test- und Deploy-Schritte ersetzt.\n\n### Muster 1: Parent-Child-Pipelines und DAG-Execution\n\nEine Parent-Pipeline erkennt Änderungen und löst nur die betroffenen Child-Pipelines aus:\n\n```yaml # .gitlab-ci.yml stages:\n  - trigger\n\ntrigger-services:\n  stage: trigger\n  trigger:\n    include:\n      - local: '.gitlab/ci/api-service.yml'\n      - local: '.gitlab/ci/web-service.yml'\n      - local: '.gitlab/ci/worker-service.yml'\n    strategy: depend\n```\n\nInnerhalb der Child-Pipeline ermöglicht `needs:` DAG-Execution – der Test startet, sobald der Build abgeschlossen ist, ohne auf andere Jobs in derselben Stage zu warten:\n\n```yaml # .gitlab/ci/api-service.yml stages:\n  - build\n  - test\n\nbuild-api:\n  stage: build\n  script:\n    - echo \"Building API service\"\n\ntest-api:\n  stage: test\n  needs: [build-api]\n  script:\n    - echo \"Running API tests\"\n```\n\n![Local downstream pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738759/Blog/Imported/hackathon-fake-blog-post-s/image3_vwj3rz.png \"Local downstream pipelines\")\n\n### Muster 4: MR-First-Delivery\n\nWorkflow-Rules, MR-Pipelines und Merged-Results zusammen ergeben ein kontextabhängiges Pipeline-Verhalten:\n\n```yaml # .gitlab-ci.yml workflow:\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS\n      when: never\n    - if: $CI_COMMIT_BRANCH\n    - if: $CI_PIPELINE_SOURCE == \"schedule\"\n\nstages:\n  - fast-checks\n  - expensive-tests\n  - deploy\n\nlint-code:\n  stage: fast-checks\n  script:\n    - echo \"Running linter\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"push\"\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\nunit-tests:\n  stage: fast-checks\n  script:\n    - echo \"Running unit tests\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"push\"\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\nintegration-tests:\n  stage: expensive-tests\n  script:\n    - echo \"Running integration tests (15 min)\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\ne2e-tests:\n  stage: expensive-tests\n  script:\n    - echo \"Running E2E tests (30 min)\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\nnightly-comprehensive-scan:\n  stage: expensive-tests\n  script:\n    - echo \"Running full nightly suite (2 hours)\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"schedule\"\n\ndeploy-production:\n  stage: deploy\n  script:\n    - echo \"Deploying to production\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n      when: manual\n```\n\n![Conditional pipelines (within a branch with no MR)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738768/Blog/Imported/hackathon-fake-blog-post-s/image6_dnfcny.png \"Conditional pipelines (within a branch with no MR)\")\n\n![Conditional pipelines (within an MR)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738772/Blog/Imported/hackathon-fake-blog-post-s/image1_wyiafu.png \"Conditional pipelines (within an MR)\")\n\n![Conditional pipelines (on the main branch)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738774/Blog/Imported/hackathon-fake-blog-post-s/image5_r6lkfd.png \"Conditional pipelines (on the main branch)\")\n\n### Muster 5: CI/CD Components\n\nEine Komponentendefinition aus einer gemeinsamen Bibliothek:\n\n```yaml # templates/deploy.yml spec:\n  inputs:\n    stage:\n      default: deploy\n    environment:\n      default: production\n--- deploy-job:\n  stage: $[[ inputs.stage ]]\n  script:\n    - echo \"Deploying $APP_NAME to $[[ inputs.environment ]]\"\n    - echo \"Deploy URL: $DEPLOY_URL\"\n  environment:\n    name: $[[ inputs.environment ]]\n```\n\nSo bindet ein Anwendungsteam die Komponenten ein:\n\n```yaml # Application repo: .gitlab-ci.yml variables:\n  APP_NAME: \"my-awesome-app\"\n  DEPLOY_URL: \"https://api.example.com\"\n\ninclude:\n  - component: gitlab.com/my-org/component-library/build@v1.0.6\n  - component: gitlab.com/my-org/component-library/test@v1.0.6\n  - component: gitlab.com/my-org/component-library/deploy@v1.0.6\n    inputs:\n      environment: staging\n\nstages:\n  - build\n  - test\n  - deploy\n```\n\n### Orientierung zu den Mustern 2 und 3\n\n**Muster 2 (Multi-Project-Pipelines):** Das Frontend-Repository publiziert ein API-Contract-Artifact und löst anschließend die Backend-Pipeline aus. Das Backend ruft das Artifact über die GitLab Jobs API ab und validiert es. Der `integration-test`-Job läuft dabei nur dann, wenn er von einer Upstream-Pipeline ausgelöst wurde (`$CI_PIPELINE_SOURCE == \"pipeline\"`), nicht bei einem eigenständigen Push. Die Frontend-Projekt-ID wird als CI/CD-Variable gesetzt, um Hardcoding zu vermeiden. Vollständige Konfigurationen beider Repositories: [englischer Originalartikel](https://about.gitlab.com/blog/5-ways-gitlab-pipeline-logic-solves-real-engineering-problems/#2-microservices-cross-repo-multi-project-pipelines).\n\n**Muster 3 (Dynamische Child-Pipelines):** Ein `generate-config`-Job erzeugt zur Laufzeit environment-spezifische YAML-Dateien. Trigger-Jobs nutzen `extends:` für gemeinsam genutzte Konfiguration und `needs:` für sequenzielle Promotion (dev → staging → prod mit manuellem Gate). Vollständige Konfiguration: [englischer Originalartikel](https://about.gitlab.com/blog/5-ways-gitlab-pipeline-logic-solves-real-engineering-problems/#3-multi-tenant--matrix-deployments-dynamic-child-pipelines).\n\n## Weiterführende Artikel\n\n- [Variable and artifact sharing in GitLab parent-child pipelines](https://about.gitlab.com/blog/variable-and-artifact-sharing-in-gitlab-parent-child-pipelines/)\n- [CI/CD inputs: Secure and preferred method to pass parameters to a pipeline](https://about.gitlab.com/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline/)\n- [Tutorial: How to set up your first GitLab CI/CD component](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n- [How to include file references in your CI/CD components](https://about.gitlab.com/blog/how-to-include-file-references-in-your-ci-cd-components/)\n- [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n- [Building a GitLab CI/CD pipeline for a monorepo the easy way](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n- [A CI/CD component builder's journey](https://about.gitlab.com/blog/a-ci-component-builders-journey/)\n- [CI/CD Catalog goes GA: No more building pipelines from scratch](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)","5 GitLab-Pipeline-Muster für komplexe Engineering-Herausforderungen","Wie Parent-Child-Pipelines, DAG-Execution, MR-Pipelines und CI/CD Components komplexe Delivery-Probleme lösen – von Monorepos bis zur governed Plattform.",[679],"Omid Khan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","2026-04-09",[110,683,24,684],"DevOps platform","features",{"featured":30,"template":13,"slug":686},"5-ways-gitlab-pipeline-logic-solves-real-engineering-problems",{"content":688,"config":698},{"title":689,"description":690,"authors":691,"heroImage":693,"date":694,"body":695,"category":9,"tags":696},"GitLab Container Virtual Registry mit Docker Hardened Images einrichten","Mehrere Registries hinter einem Endpunkt – GitLab Container Virtual Registry mit Docker Hardened Images, Caching und Audit-Trail.",[692],"Tim Rizzi","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772111172/mwhgbjawn62kymfwrhle.png","2026-03-12","Wer im Plattformteam arbeitet, kennt solche Gespräche:\n\n*„Security sagt: Wir müssen gehärtete Base-Images verwenden.\"*\n\n*„Prima – wo trage ich jetzt die Credentials für noch eine weitere Registry ein?\"*\n\n*„Und wie stellen wir sicher, dass alle sie auch wirklich nutzen?\"*\n\nOder diese hier:\n\n*„Warum sind unsere Builds so langsam?\"*\n\n*„Wir pullen dasselbe 500-MB-Image in jedem einzelnen Job neu von Docker Hub.\"*\n\n*„Kann man die nicht irgendwo cachen?\"*\n\nIch arbeite bei GitLab an der [Container Virtual Registry](https://docs.gitlab.com/user/packages/virtual_registry/container/) – einem Pull-Through-Cache, der vor den vorgelagerten Registries sitzt: Docker Hub, dhi.io (Docker Hardened Images), MCR und Quay. Teams erhalten einen einzigen Endpunkt zum Pullen. Images werden beim ersten Abruf gecacht; alle nachfolgenden Pulls kommen aus dem Cache. Das Entwicklungsteam muss nicht wissen, aus welchem Upstream ein bestimmtes Image stammt.\n\nDieser Artikel zeigt die Einrichtung der Container Virtual Registry – mit Docker Hardened Images als konkretem Anwendungsfall, da diese Kombination für Teams mit Sicherheitsanforderungen besonders naheliegt.\n\n## Das Problem: Registry-Wildwuchs im Plattformteam\n\nDie Plattformteams, mit denen ich spreche, verwalten Container-Images über drei bis fünf Registries:\n\n- **Docker Hub** für die meisten Base-Images\n- **dhi.io** für Docker Hardened Images (sicherheitskritische Workloads)\n- **MCR** für .NET- und Azure-Tooling\n- **Quay.io** für das Red-Hat-Ökosystem\n- **Interne Registries** für proprietäre Images\n\nJede davon hat eigene Authentifizierungsmechanismen, unterschiedliche Netzwerklatenz und eine eigene Pfadstruktur für Images.\n\nCI/CD-Konfigurationen füllen sich mit registry-spezifischer Logik. Credential-Management wird zum eigenständigen Projekt. Und jeder Pipeline-Job lädt dieselben Base-Images erneut über das Netz – obwohl sie sich seit Wochen nicht geändert haben.\n\nContainer Virtual Registry konsolidiert das: eine Registry-URL, ein Authentifizierungsfluss über GitLab, gecachte Images aus GitLab-Infrastruktur statt wiederholter Internet-Traversierung.\n\n## Funktionsweise\n\nDas Modell ist geradlinig:\n\n```text\n\nPipeline ruft ab:\n  gitlab.com/virtual_registries/container/1000016/python:3.13\n\nVirtual Registry prüft:\n  1. Im Cache vorhanden? → Direkt zurückgeben\n  2. Nein? → Vom Upstream laden, cachen, zurückgeben\n\n\n```\n\nUpstreams werden in Prioritätsreihenfolge konfiguriert. Bei einem eingehenden Pull-Request durchsucht die Virtual Registry die Upstreams der Reihe nach, bis das Image gefunden wird. Das Ergebnis wird für einen konfigurierbaren Zeitraum gecacht – standardmäßig 24 Stunden.\n\n\n```text\n\n┌─────────────────────────────────────────────────────────┐ │                    CI/CD Pipeline                       │ │                          │                              │ │                          ▼                              │ │   gitlab.com/virtual_registries/container/\u003Cid>/image   │ └─────────────────────────────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────┐ │            Container Virtual Registry                   │ │                                                         │ │  Upstream 1: Docker Hub ────────────────┐               │ │  Upstream 2: dhi.io (Hardened) ────────┐│               │ │  Upstream 3: MCR ─────────────────────┐││               │ │  Upstream 4: Quay.io ────────────────┐│││               │ │                                      ││││               │ │                    ┌─────────────────┴┴┴┴──┐            │ │                    │        Cache          │            │ │                    │  (manifests + layers) │            │ │                    └───────────────────────┘            │ └─────────────────────────────────────────────────────────┘\n\n```\n\n## Was das konkret bringt – besonders mit Docker Hardened Images\n\n[Docker Hardened Images](https://docs.docker.com/dhi/) zeichnen sich durch minimale Angriffsfläche, nahezu keine bekannten CVEs, vollständige Software Bills of Materials (SBOMs) und SLSA-Provenance aus. Für Teams, die Base-Images für sicherheitskritische Workloads evaluieren, gehören sie auf die Shortlist.\n\nDer Wechsel zu dhi.io erzeugt jedoch dieselbe operative Reibung wie jede neue Registry:\n\n- **Credential-Verteilung**: Docker-Credentials müssen auf alle Systeme verteilt werden, die Images von dhi.io abrufen.\n- **CI/CD-Anpassungen**: Jede Pipeline muss für die Authentifizierung mit dhi.io aktualisiert werden.\n- **Akzeptanzproblem**: Ohne zentrale Steuerung greifen Teams weiterhin auf reguläre Images zurück.\n- **Fehlende Transparenz**: Ob Teams tatsächlich die gehärteten Varianten nutzen, ist kaum nachvollziehbar.\n\nDie Virtual Registry löst jeden dieser Punkte:\n\n**Einzelne Credential**: Teams authentifizieren sich bei GitLab. Die Virtual Registry übernimmt die Upstream-Authentifizierung. Docker-Credentials werden einmalig auf Registry-Ebene konfiguriert und gelten für alle Pulls.\n\n**Keine per-Team-CI/CD-Änderungen**: Pipelines auf die Virtual Registry zeigen lassen – fertig. Die Upstream-Konfiguration ist zentralisiert.\n\n**Schrittweise Einführung**: Da Images mit ihrem vollständigen Pfad gecacht werden, ist im Cache sichtbar, was tatsächlich abgerufen wird. Wird `library/python:3.11` statt der gehärteten Variante gepullt, ist das erkennbar.\n\n**Audit-Trail**: Der Cache zeigt exakt, welche Images aktiv genutzt werden – nachvollziehbar für Compliance-Zwecke und als Grundlage für das Verständnis der tatsächlichen Infrastruktur-Abhängigkeiten.\n\nWer das Konzept verstanden hat und die Einrichtung zu einem späteren Zeitpunkt in Angriff nimmt: Die wesentlichen Konzepte sind damit abgedeckt. Die technische Konfiguration folgt im nächsten Abschnitt.\n\n## Einrichtung\n\nDie folgende Einrichtung nutzt den Python-Client aus dem Demo-Projekt.\n\n### Virtual Registry erstellen\n\n```python\nfrom virtual_registry_client import VirtualRegistryClient\nclient = VirtualRegistryClient()\nregistry = client.create_virtual_registry(\n    group_id=\"785414\",  # ID der obersten Gruppe\n    name=\"platform-images\",\n    description=\"Cached container images for platform teams\"\n)\nprint(f\"Registry ID: {registry['id']}\") # Diese ID wird für die Pull-URL benötigt\n```\n\n### Docker Hub als Upstream hinzufügen\n\nFür offizielle Images wie Alpine, Python usw.:\n\n```python\n\ndocker_upstream = client.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://registry-1.docker.io\",\n    name=\"Docker Hub\",\n    cache_validity_hours=24\n)\n\n```\n\n### Docker Hardened Images (dhi.io) hinzufügen\n\nDocker Hardened Images werden auf `dhi.io` gehostet – einer separaten Registry mit Authentifizierungspflicht:\n\n```python\n\ndhi_upstream = client.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://dhi.io\",\n    name=\"Docker Hardened Images\",\n    username=\"your-docker-username\",\n    password=\"your-docker-access-token\",\n    cache_validity_hours=24\n)\n\n```\n\n### Weitere Upstreams hinzufügen\n\n```python\n\n# MCR für .NET-Teams client.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://mcr.microsoft.com\",\n    name=\"Microsoft Container Registry\",\n    cache_validity_hours=48\n)\n# Quay für das Red-Hat-Ökosystem client.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://quay.io\",\n    name=\"Quay.io\",\n    cache_validity_hours=24\n)\n\n```\n\n### CI/CD aktualisieren\n\nEine `.gitlab-ci.yml`, die über die Virtual Registry pullt:\n\n```yaml\n\nvariables:\n  VIRTUAL_REGISTRY_ID: \u003Cyour_virtual_registry_ID>\n\n  \nbuild:\n  image: docker:24\n  services:\n    - docker:24-dind\n  before_script:\n    # Authentifizierung bei GitLab – Upstream-Auth wird übernommen\n    - echo \"${CI_JOB_TOKEN}\" | docker login -u gitlab-ci-token --password-stdin gitlab.com\n  script:\n    # Alle Pulls laufen über die zentrale Virtual Registry\n    \n    # Offizielle Docker Hub Images (library/-Präfix erforderlich)\n    - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/library/alpine:latest\n    \n    # Docker Hardened Images von dhi.io (kein Präfix nötig)\n    - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/python:3.13\n    \n    # .NET von MCR\n    - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/dotnet/sdk:8.0\n\n\n```\n\n### Image-Pfadformate\n\nVerschiedene Registries verwenden unterschiedliche Pfadkonventionen:\n\n| Registry | Beispiel-Pull-URL |\n|----------|-------------------|\n| Docker Hub (offiziell) | `.../library/python:3.11-slim` |\n| Docker Hardened Images (dhi.io) | `.../python:3.13` |\n| MCR | `.../dotnet/sdk:8.0` |\n| Quay.io | `.../prometheus/prometheus:latest` |\n\n### Funktionsprüfung\n\nNach einigen Pulls lässt sich der Cache überprüfen:\n\n```python\n\nupstreams = client.list_registry_upstreams(registry['id']) for upstream in upstreams:\n    entries = client.list_cache_entries(upstream['id'])\n    print(f\"{upstream['name']}: {len(entries)} cached entries\")\n\n\n```\n\n## Messergebnisse\n\nTestergebnisse beim Pullen über die Virtual Registry:\n\n| Messgröße | Ohne Cache | Mit warmem Cache |\n|-----------|------------|-----------------|\n| Pull-Zeit (Alpine) | 10,3 s | 4,2 s |\n| Pull-Zeit (Python 3.13 DHI) | 11,6 s | ~4 s |\n| Netzwerk-Roundtrips zum Upstream | Jeder Pull | Nur Cache-Misses |\n\nDer erste Pull hat dieselbe Dauer – das Image muss vom Upstream geladen werden. Jeder weitere Pull innerhalb der Cache-Gültigkeitsdauer kommt direkt aus GitLab-Storage: kein Netzwerk-Hop zu Docker Hub, dhi.io, MCR oder einer anderen Registry.\n\nBei Teams mit vielen Pipeline-Jobs pro Tag summiert sich das zu einem messbaren Gewinn bei den Build-Laufzeiten.\n\n## Praktische Hinweise\n\n### Cache-Gültigkeit\n\nDer Standard sind 24 Stunden. Für sicherheitskritische Images, bei denen Patches schnell verfügbar sein sollen, empfiehlt sich ein kürzeres Intervall:\n\n```python\n\nclient.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://dhi.io\",\n    name=\"Docker Hardened Images\",\n    username=\"your-username\",\n    password=\"your-token\",\n    cache_validity_hours=12\n)\n\n```\n\nFür stabile Images mit fixen Versions-Tags ist ein längeres Intervall problemlos.\n\n### Upstream-Priorität\n\nUpstreams werden der Reihe nach geprüft. Bei gleichnamigen Images in verschiedenen Registries gewinnt der erste passende Upstream.\n\n### Limits\n\n- Maximal 20 Virtual Registries pro Gruppe\n- Maximal 20 Upstreams pro Virtual Registry\n\n## Konfiguration über die Oberfläche\n\nVirtual Registries und Upstreams lassen sich auch direkt in der GitLab-Oberfläche einrichten – ohne API-Aufrufe. Unter **Einstellungen > Pakete und Registries > Virtual Registry** der jeweiligen Gruppe stehen folgende Optionen zur Verfügung:\n\n- Virtual Registries erstellen und verwalten\n- Upstreams hinzufügen, bearbeiten und neu anordnen\n- Cache anzeigen und verwalten\n- Überblick, welche Images abgerufen werden\n\n## Ausblick\n\nIn Entwicklung:\n\n- **Allow/Deny-Listen**: Regex-basierte Steuerung, welche Images aus welchen Upstreams abgerufen werden dürfen.\n\nContainer Virtual Registry befindet sich in der Beta-Phase. Die Funktion wird produktiv eingesetzt und wird weiterentwickelt – Feedback fließt direkt in die Priorisierung ein.\n\n## Feedback\n\nWer als Plattformteam mit Registry-Wildwuchs zu kämpfen hat: Ich möchte verstehen, wie die aktuelle Situation aussieht.\n\n- Wie viele Upstream-Registries werden verwaltet?\n- Wo liegt der größte Schmerzpunkt?\n- Würde ein solcher Ansatz helfen – und falls nicht: Was fehlt?\n\nErfahrungen und Rückmeldungen gerne im [Container Virtual Registry Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/589630) teilen.\n\n## Weiterführende Ressourcen\n\n- [Neue GitLab-Metriken und Registry-Funktionen zur Optimierung von CI/CD-Pipelines](https://about.gitlab.com/de-de/blog/new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks/)\n- [Container Virtual Registry – Dokumentation](https://docs.gitlab.com/user/packages/virtual_registry/container/)\n- [Container Virtual Registry – API](https://docs.gitlab.com/api/container_virtual_registries/)\n\n## Für deutsche Unternehmen könnte dies folgende Themen betreffen\n\nTeams, die sicherheitsgehärtete Base-Images mit vollständigen SBOMs und SLSA-Provenance einsetzen, haben möglicherweise auch Compliance-Überlegungen – beispielsweise in Bereichen wie Sicherheit der Software-Lieferkette, Nachvollziehbarkeit von Image-Abhängigkeiten und zentralem Audit-Trail.\n\nRegulatorische Frameworks wie NIS2 und der Cyber Resilience Act adressieren ähnliche Themen rund um Software-Lieferketten und SBOM-Transparenz. Für konkrete Compliance-Anforderungen empfiehlt sich Rücksprache mit entsprechender Fachberatung.",[24,697,684],"product",{"featured":12,"template":13,"slug":699},"using-gitlab-container-virtual-registry-with-docker-hardened-images",{"content":701,"config":712},{"category":9,"tags":702,"body":704,"date":705,"heroImage":706,"authors":707,"title":710,"description":711},[24,703,110],"git","Enterprise-Migrationen in regulierten Branchen wie Finanzwesen und Automobilindustrie erfordern systematisches Risikomanagement gemäß NIS2-Richtlinie Artikel 21. Die mehrstufige Migrationsstruktur mit Testläufen vor Produktions-Wellen und kontrollierten Change-Freezes demonstriert Business-Continuity-Management in der Praxis. GitLab Professional Services organisiert Migrationen in Wellen von 200-300 Projekten, um Komplexität zu managen und API-Rate-Limits zu respektieren.\n\n## Überblick\n\nGitLab bietet [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintained by GitLab Professional Services) und [eingebauten Git-Repository-Import](https://docs.gitlab.com/user/project/import/repo_by_url/) für Migrationen von Azure DevOps (ADO). Beide Optionen unterstützen Repository-basierte oder Bulk-Migration und erhalten Git-Commit-History, Branches und Tags. Mit Congregate werden zusätzliche Assets wie Wikis, Work Items, CI/CD-Variablen, Container-Images, Packages und Pipelines migriert (siehe [Feature-Matrix](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)).\n\nEnterprises folgen typischerweise einem mehrstufigen Ansatz:\n\n- Repositories von ADO zu GitLab migrieren (Congregate oder eingebauter Import)\n- Pipelines von Azure Pipelines zu GitLab CI/CD migrieren\n- Verbleibende Assets wie Boards, Work Items und Artifacts zu GitLab Issues, Epics und Package/Container Registries migrieren\n\nMehrstufige Migrationsphasen (siehe [Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#overview)):\n\n- Prerequisites (IdP, Runners, Change Management)\n- Migration Phase (Source Code, History, Work Items)\n- Post-Migration (Pipelines, Assets, Security)\n\n## Migration planen\n\n**Zentrale Planungsfragen:**\n\n- Wie schnell muss die Migration abgeschlossen werden?\n- Was genau wird migriert?\n- Wer führt die Migration durch?\n- Welche Organisationsstruktur wird in GitLab benötigt?\n- Welche Einschränkungen, Limitierungen oder Fallstricke müssen berücksichtigt werden?\n\nDie Timeline bestimmt weitgehend den Migrationsansatz. Identifizierung von Champions oder Teams mit ADO- und GitLab-Erfahrung unterstützt Adoption und Guidance.\n\n**Inventar erstellen:**\n\nDas GitLab Professional Services [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)-Tool produziert ein vollständiges Inventar der Azure DevOps Organisation: Repositories, PR-Counts, Contributors, Pipelines, Work Items, CI/CD-Variablen. Bei Professional Services Engagements wird dieser Report mit Engagement Manager oder Technical Architect geteilt für Migrationsplanung.\n\nMigrations-Timing wird primär bestimmt durch Pull-Request-Count, Repository-Größe und Contribution-Menge. Beispiel: 1.000 kleine Repositories mit wenigen PRs migrieren schneller als wenige Repositories mit Zehntausenden PRs. Inventar-Daten ermöglichen Aufwands-Schätzung und Test-Run-Planung.\n\nIn Professional Services Engagements werden Migrationen in Wellen von 200-300 Projekten organisiert, um Komplexität zu managen und API-Rate-Limits zu respektieren (sowohl [GitLab](https://docs.gitlab.com/security/rate_limits/) als auch [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)).\n\n**Tool-Auswahl:**\n\nGitLabs [eingebauter Repository-Importer](https://docs.gitlab.com/user/project/import/repo_by_url/) migriert Git-Repositories (Commits, Branches, Tags) einzeln. Congregate erhält Pull Requests (in GitLab: Merge Requests), Kommentare und Metadata; der eingebaute Import fokussiert auf Git-Daten (History, Branches, Tags).\n\nAssets die typischerweise separate Migration oder manuelle Neuerstellung erfordern:\n\n- Azure Pipelines → GitLab CI/CD Pipelines (siehe [CI/CD YAML](https://docs.gitlab.com/ci/yaml/) oder [CI/CD Components](https://docs.gitlab.com/ci/components/)). Alternativ: AI-basierte Pipeline-Konvertierung in Congregate.\n- Work Items und Boards → GitLab Issues, Epics, Issue Boards\n- Artifacts, Container-Images (ACR) → GitLab Package/Container Registry\n- Service Hooks, externe Integrationen → in GitLab neu erstellen\n\n[Permissions-Modelle](https://docs.gitlab.com/user/permissions/) unterscheiden sich zwischen ADO und GitLab. Permissions-Mapping planen statt exakter Preservation zu erwarten.\n\n**Organisationsstruktur in GitLab:**\n\nEmpfohlener Ansatz: ADO-Organisationen auf GitLab-Groups mappen (nicht viele kleine Groups). Migration als Gelegenheit nutzen, GitLab-Struktur zu rationalisieren (siehe [Struktur-Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#planning-your-migration)):\n\n- **ADO Organization** → GitLab Top-level Group\n- **ADO Project** → GitLab Subgroup (optional)\n- **ADO Repository** → GitLab Project\n\nWeitere Empfehlungen:\n\n- Subgroups und Project-Level-Permissions für verwandte Repositories nutzen\n- Zugriff über GitLab Groups und Group-Membership managen\n- GitLab [Permissions](https://docs.gitlab.com/ee/user/permissions.html) und [SAML Group Links](https://docs.gitlab.com/user/group/saml_sso/group_sync/) für Enterprise-RBAC-Modell evaluieren\n\n**ADO Work Items Migration:**\n\nADO Boards und Work Items mappen zu GitLab Issues, Epics und Issue Boards. ADO Epics und Features werden GitLab Epics. Andere Work-Item-Typen (User Stories, Tasks, Bugs) werden project-scoped Issues. Standard-Felder bleiben erhalten; ausgewählte Custom Fields können migriert werden. Parent-Child-Relationships bleiben erhalten. Links zu Pull Requests werden zu Merge-Request-Links konvertiert.\n\n![Migration eines Work Items zu GitLab Issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\n**Pipelines-Migration:**\n\nCongregate bietet [AI-basierte Konvertierung](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) für multi-stage YAML-Pipelines von Azure DevOps zu GitLab CI/CD. Die automatisierte Konvertierung funktioniert optimal für einfache Single-File-Pipelines und liefert einen funktionalen Ausgangspunkt, nicht ein produktionsreifes `.gitlab-ci.yml`-File. Das Tool generiert funktional äquivalente GitLab-Pipelines zur weiteren Optimierung.\n\n- Konvertiert Azure Pipelines YAML zu `.gitlab-ci.yml` automatisch\n- Geeignet für straightforward Single-File-Pipeline-Konfigurationen\n- Liefert Boilerplate zur Migrations-Beschleunigung, nicht finales Production-Artifact\n- Erfordert Review und Anpassung für komplexe Szenarien, Custom Tasks oder Enterprise-Requirements\n- Unterstützt keine Azure DevOps Classic Release Pipelines\n\nRepository-Owner sollten [GitLab CI/CD Dokumentation](https://docs.gitlab.com/ci/) konsultieren für weitere Pipeline-Optimierung nach initialer Konvertierung.\n\n## Migrationen durchführen\n\nNach der Planung werden Migrationen in Stages durchgeführt, beginnend mit Trial Runs. Trial Migrations identifizieren organisations-spezifische Issues frühzeitig und ermöglichen Duration-Messung, Outcome-Validierung und Approach-Finetuning vor Production.\n\n**Was Trial Migrations validieren:**\n\n- Ob Repository und Assets erfolgreich migrieren (History, Branches, Tags; plus MRs/Comments bei Congregate)\n- Ob Destination sofort nutzbar ist (Permissions, Runners, CI/CD-Variablen, Integrationen)\n- Wie lange jeder Batch benötigt für Schedule- und Stakeholder-Expectations\n\n**Downtime-Guidance:**\n\nGitLabs eingebauter Git-Import und Congregate erfordern inhärent keine Downtime. Für Production-Wellen: Changes in ADO freezen (Branch-Protections oder Read-only), um verpasste Commits, PR-Updates oder mid-migration Work Items zu vermeiden. Trial Runs erfordern keine Freezes.\n\n**Batching-Guidance:**\n\nTrial-Batches back-to-back durchführen für kürzere elapsed Time. Teams validieren Results asynchron. Geplante Group/Subgroup-Struktur für Batch-Definition nutzen und API-Rate-Limits respektieren.\n\n**Empfohlene Schritte:**\n\n1. Test-Destination in GitLab erstellen (GitLab.com: dedicated Group/Namespace; Self-managed: Top-level Group)\n2. Authentication vorbereiten (Azure DevOps PAT, GitLab Personal Access Token mit api und read_repository Scopes)\n3. Trial Migrations durchführen (Repos only: eingebauter Import; Repos + PRs/MRs: Congregate)\n4. Post-Trial Follow-up (Repo-History, Branches, Tags, Merge Requests, Issues/Epics, Labels, Relationships verifizieren)\n5. Permissions/Roles, Protected Branches, Runners/Tags, Variables/Secrets, Integrations/Webhooks prüfen\n6. Pipelines (`.gitlab-ci.yml`) oder konvertierte Pipelines validieren\n7. User-Validierung für Functionality und Data-Fidelity\n8. Production-Migrationen in Waves durchführen (Change-Freezes in ADO erzwingen, Progress und Logs monitoren)\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## Zentrale ADO-zu-GitLab-Mappings\n\nWichtigste Struktur-Mappings für Migrationsplanung:\n\n- **ADO Organization** → GitLab Group (Top-level Namespace)\n- **ADO Project** → GitLab Group oder Subgroup (Permissions-Boundary)\n- **ADO Repository** → GitLab Project (Git-Repo plus Issues, CI/CD, Wiki)\n- **Pull Request** → Merge Request (Code Review, Approvals)\n- **Azure Pipelines** → GitLab CI/CD (`.gitlab-ci.yml`)\n- **Agent Pools** → GitLab Runners (Job-Execution)\n- **Work Items** → GitLab Issues/Epics (Planning-Funktionalität)\n- **Variable Groups** → CI/CD Variables (Project/Group/Instance Level)\n\nFür vollständige Terminologie-Referenztabelle mit allen Mappings siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\n## Professional Services Migrationsmuster\n\nGitLab Professional Services nutzt bewährte Muster für Enterprise-Migrationen:\n\n**Systematische Planung:** Evaluate-Tool liefert vollständiges Inventar (Repositories, PRs, Contributors, Pipelines, Work Items). Klassifikation nach Komplexität (Work Items = Planning-Team-Involvement; Pipelines = Conversion-Requirements) ermöglicht Timeline-Schätzung und Batch-Definition.\n\n**Controlled Execution:** Wellen von 200-300 Projekten managen Komplexität und respektieren API-Rate-Limits. Trial-Migrationen vor Production-Waves identifizieren Issues frühzeitig. Change-Freezes in ADO während Production-Wellen vermeiden mid-migration Updates.\n\n**Risikominimierung:** Multi-Phase-Ansatz (Prerequisites → Migration → Post-migration) mit Validierungs-Checkpoints an jeder Phase. Trial-Runs ermöglichen asynchrone Team-Validierung ohne Production-Impact.\n\n## Praktische Implementierung\n\nFür vollständige Implementierungsdetails, Konfigurationsbeispiele, Pipeline-Konvertierungs-Patterns und detaillierte Post-Migration-Checklisten siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\nWeitere Professional Services Ressourcen:\n\n- [Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)\n- [Congregate Migration Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)\n- [Evaluate Inventory Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate)\n","2025-12-03","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[708,709],"Evgeny Rudinsky","Michael Leopard","Migration von Azure DevOps zu GitLab systematisch planen","Professional Services Migrationsansatz mit mehrstufiger Struktur, 200-300 Projekt-Wellen und systematischem Risikomanagement für Enterprise-Migrationen.",{"featured":30,"template":13,"slug":713},"migration-from-azure-devops-to-gitlab",{"promotions":715},[716,730,741,753],{"id":717,"categories":718,"header":720,"text":721,"button":722,"image":727},"ai-modernization",[719],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":723,"config":724},"Get your AI maturity score",{"href":725,"dataGaName":726,"dataGaLocation":245},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":728},{"src":729},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":731,"categories":732,"header":733,"text":721,"button":734,"image":738},"devops-modernization",[697,38],"Are you just managing tools or shipping innovation?",{"text":735,"config":736},"Get your DevOps maturity score",{"href":737,"dataGaName":726,"dataGaLocation":245},"/assessments/devops-modernization-assessment/",{"config":739},{"src":740},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":742,"categories":743,"header":745,"text":721,"button":746,"image":750},"security-modernization",[744],"security","Are you trading speed for security?",{"text":747,"config":748},"Get your security maturity score",{"href":749,"dataGaName":726,"dataGaLocation":245},"/assessments/security-modernization-assessment/",{"config":751},{"src":752},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":754,"paths":755,"header":757,"text":758,"button":759,"image":764},"github-azure-migration",[713,756],"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":760,"config":761},"See how GitLab compares to GitHub",{"href":762,"dataGaName":763,"dataGaLocation":245},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":765},{"src":740},{"header":767,"blurb":768,"button":769,"secondaryButton":774},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":770,"config":771},"Kostenlosen Test starten",{"href":772,"dataGaName":52,"dataGaLocation":773},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":54,"config":775},{"href":56,"dataGaName":57,"dataGaLocation":773},1776447694079]