[{"data":1,"prerenderedAt":780},["ShallowReactive",2],{"/de-de/blog/what-is-an-ide":3,"navigation-de-de":41,"banner-de-de":444,"footer-de-de":454,"blog-post-authors-de-de-GitLab Germany Team":659,"blog-related-posts-de-de-what-is-an-ide":674,"blog-promotions-de-de":717,"next-steps-de-de":770},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":26,"isFeatured":12,"meta":27,"navigation":28,"path":29,"publishedDate":20,"seo":30,"stem":36,"tagSlugs":37,"__hash__":40},"blogPosts/de-de/blog/what-is-an-ide.yml","What Is An Ide",[7],"gitlab-germany-team",null,"engineering",{"slug":11,"featured":12,"template":13},"what-is-an-ide",false,"BlogPost",{"heroImage":15,"body":16,"authors":17,"updatedDate":19,"date":20,"title":21,"tags":22,"description":25,"category":9},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659768/Blog/Hero%20Images/AdobeStock_271529563.jpg","Entwickler/in ist ein finanziell lukrativer Beruf in einer der derzeit spannendsten Branchen. Zugleich ist es auch ein Job, der mit einer sehr hohen Arbeitsbelastung und einem enormen Leistungsdruck einhergeht. Laut einer Studie leiden bis zu 60 % aller IT-Expert(inn)en unter „Burn-out”. Diese Zahl ist umso bedrückender, wenn man bedenkt, dass sie Studierende miteinschließt. \n\nIntegrierte Entwicklungsumgebungen (IDEs) wurden nicht primär dafür entwickelt, das Coden angenehmer zu machen. Dennoch tragen sie viel dazu bei, die tägliche Arbeit für Entwickler(innen) einfacher zu gestalten. Wer eine gut funktionierende, auf die persönlichen Bedürfnisse zugeschnittene IDE gefunden hat, weiß, wie viel das wert ist.\n\nDie Optimierung des Workflows ist nur ein Aspekt unter vielen, weswegen IDEs einen hohen Stellenwert genießen. Man kann mit gutem Recht behaupten: Modernes Programmieren wäre ohne IDEs nicht denkbar.\n\nWas ist eine IDE? In dieser Übersicht gehen wir ausführlich auf diese Frage ein sowie auf alle Aspekte, die IDEs so begehrt machen. Wenn du noch offene Fragen zum Thema hattest – nach der Lektüre sollten sie beantwortet sein.\n\n## Inhaltsverzeichnis - Was ist eine IDE?\n\n- [Was ist eine IDE?](#was-ist-eine-ide%3F)\n- [IDE vs Code-Editor vs Building-Tools](#ide-vs-code-editor-vs-building-tools)\n- [Was sind die wichtigsten Komponenten einer IDE?](#was-sind-die-wichtigsten-komponenten-einer-ide%3F)\n - [Code-Editor](#code-editor)\n - [Building-Tools](#building-tools)\n - [Debugging](#debugging)\n- [Warum wurden IDEs entwickelt?](#warum-wurden-ides-entwickelt%3F)\n- [Gibt es unterschiedliche IDE-Typen?](#gibt-es-unterschiedliche-ide-typen%3F)\n- [Wonach sollte ich meine IDE auswählen?](#wonach-sollte-ich-meine-ide-auswählen%3F)\n- [Was ist die beste IDE?](#was-ist-die-beste-ide%3F)\n  - [IDE Eclipse](#ide-eclipse)\n  - [Dreamweaver](#dreamweaver)\n  - [IntelliJ](#intellij)\n  - [IDE Visual Studio](#ide-visual-studio)\n  - [GitLab](#gitlab)\n- [IDE-FAQs](#ide-faqs)\n\n## Was ist eine IDE?\n\nDie Abkürzung IDE steht für „Integrated Development Environment”, zu Deutsch „Integrierte Entwicklungsumgebung”. Aus dem Begriff lässt sich eine einfache Definition ableiten:\n\nIDEs unterstützen Entwickler(innen) bei den meisten Aspekten des Codens, beziehungsweise der Programmierung.\nIDEs kombinieren verschiedene Entwicklungstools in einem Paket. So können Anwender(innen) nahtlos zwischen Funktionen hin- und herschalten.\n\nMan kann sich eine IDE wie einen Baukasten vorstellen, der eine zentrale Benutzeroberfläche sowie ein Netzwerk aus Modulen bietet, auf die Benutzer(innen) zugreifen können.\n\n## IDE vs Code-Editor vs Building-Tools\n\nDie ersten IDEs entstanden, als sich das Programmieren aus den Universitäten wegbewegte und Computer in der freien Wirtschaft Fuß zu fassen begannen.\n\nWeil IDEs verschiedene Tools integrieren, folgt ihre Entwicklung somit den Fortschritten, die in Entwicklungsanwendungen im Laufe der Jahre gemacht wurden. Compiler beispielsweise gab es bereits in den 1950ern, Code-Editoren hingegen kamen weitaus später hinzu.\n\nGemeinhin wird der Maestro I, der in München vom Unternehmen Softlab entwickelt wurde, als die erste kommerzielle IDE betrachtet. Der erste Maestro wurde 1977 verkauft und die Marke hatte bis in die frühen 1990er Jahre hinein einen signifikanten Kundenstamm. Insgesamt wurden 22000 Maestros installiert.\n\nSchon dieser Vorläufer vereinte die bis heute relevanten Kernfunktionalitäten eines Coding-Editors, Assemblers und Compilers. \n\n## Was sind die wichtigsten Komponenten einer IDE?\n\nWar der Maestro I wirklich die erste IDE? Dafür müssen wir uns noch weitere Aspekte ansehen, die eine IDE ausmachen. Einige der wichtigsten Bestandteile einer integrierten Entwicklungsumgebung haben wir bereits genannt:\n\nEin Coding-Editor\nBuilding-Tools, einschließlich Compiler und Packer\n\nDarüber hinaus beinhalten IDEs noch Fehlerbeseitigungs-Anwendungen, die für ein Debugging zur Verfügung stehen. \n\nAuch ist es möglich, IDEs in einen DevOps- oder Agile-Management-Prozess einzubinden. Durch diese Verknüpfung üben sie einen positiven Einfluss auf den gesamten Arbeitsprozess aus, der über das Programmieren hinausgeht. So profitiert unter anderem deine agile Planung von der Wahl der für dich und dein Team optimalen IDE.\n\nBetrachten wir diese verschiedenen Teile nun ein wenig genauer.\n\n### Code-Editor \n\nDer Code-Editor ist das Herzstück einer IDE. Auch deshalb ist die Vielfalt an Instrumenten, die Entwickler(innen) als Teil dieser Editoren zur Verfügung stehen, besonders groß.\n\nDazu gehören zum Beispiel:\nIntelligente Code-Vervollständigung: Ähnlich einer Auto-Complete-Funktion beim Smartphone schlagen moderne Coding-Editoren während des Programmierens die nächsten Zeilen vor und korrigieren offensichtliche syntaktische Fehler.\nDie IDE kümmert sich um einen korrekten, auf Lesbarkeit und Struktur optimierten Code. Dazu gehören das Refactoring (Reorganisation des Codes für maximale Effizienz), das farbliche Hervorheben unterschiedlicher Code-Bausteine sowie eine Prüfung für verschiedene Programmiersprachen.\nBegleitende Bug-Prüfung, das heißt, dass die IDE bereits während des Programmierens den gesamten Code auf innere Konsistenz hin untersucht.\nDas Programmieren ist der zentrale Teil der Arbeit an neuen Softwareprojekten. Doch damit eine Anwendung getestet werden kann, muss sie regelmäßig kompiliert werden.\n\nHierfür existieren spezialisierte Anwendungen, die sogenannten Compiler und Packer. Integrierte Entwicklungsumgebungen bieten diese in der Regel als Teil ihrer Basisfunktionalität an.\n\n### Building-Tools\n\nSogar Programmiersprachen mit einem hohen Abstraktionsgrad sind immer noch für Menschen ausgelegt. Damit Maschinen einen Code in einer Programmiersprache ausführen können, müssen die Daten in eine von Maschinen lesbare binäre Sprache übertragen werden.\n\nDie damit verbundenen Aufgaben werden von Compilern und Packern übernommen. Diese Anwendungen werden unter dem Oberbegriff „Building-Tools” zusammengefasst. Building-Tools vereinfachen den Prozess der Übersetzung, indem sie ihn automatisieren.\n\nBuilding-Tools sind heute ein integraler Teil von IDEs und erlauben es Teams, den gesamten Prozess des Programmierens über die Durchführung von Tests bis hin zur finalen Delivery innerhalb derselben Entwicklung durchzuführen und zu steuern.\n\n### Debugging\n\nHistorisch gesehen sind Debugger einer der Hauptgründe, warum Integrated Development Systems sich auf breiter Front durchgesetzt haben: Gerade beim Coden kann sich die Suche nach Fehlern als sehr aufwändig erweisen.\n\nDas ist zum einen ein Problem, wenn du auf kontinuierliche Verbesserung setzt und dazu das Produkt regelmäßig und oft testen möchtest. Wenn zu viele Fehler verhindern, dass du ein testfähiges Stadium erreichst, hemmt dies den gesamten Prozess und macht agiles Management unmöglich.\n\nNoch schwerwiegender wird es, wenn das Endprodukt von Fehlern betroffen ist, die seinen Nutzen für Kund(innen) reduzieren. Hier können effektive Debugger einen entscheidenden Beitrag leisten.\n\n## Warum wurden IDEs entwickelt? \n\nAn sich fällt die Beantwortung dieser Frage nicht schwer. Gemäß ihrer Definition schnüren IDEs Pakete aus miteinander verbundenen Anwendungen, die sich gegenseitig ergänzen.\n\nZusammen erlauben sie:\n\n- Fokussiertes Arbeiten und einen „sauberen” Code, der den Regeln der jeweiligen Programmiersprache folgt und optimal auf Lesbarkeit und Effizienz hin strukturiert ist.\n- Flexibilität im Hinblick einerseits auf die zu wählende Programmiersprache und andererseits für eine Vielzahl verschiedener Projekte.\n- Eine Reduzierung des Aufwands und der Kosten für einzelne Lizenzen. Gerade wenn Anwendungen auf einer SaaS-Basis erworben werden, häufen sich die Abonnements an.\n- Eine nahezu garantierte Kompatibilität der Anwendungen. Alles innerhalb einer IDE ist optimal aufeinander abgestimmt.\n- Ein nahtloses Springen zwischen verschiedenen Anwendungen, statt für jeden neuen Schritt im Arbeitsprozess die Aktivität unterbrechen zu müssen.\n\nZusammengefasst addieren sich die Punkte zu einer beträchtlichen Zeitersparnis. Darüber hinaus sorgen IDEs gerade in großen Teams oder Netzwerken aus Teams dafür, dass alle Beteiligten mit denselben Mitteln arbeiten und es nicht zu Kompatibilitätskonflikten kommt.\n\n## Gibt es unterschiedliche IDE-Typen?\n\nMan unterscheidet grundsätzlich drei verschiedene Formen von IDEs.\nCloudbasierte IDEs werden von allen Teammitgliedern geteilt und laufen oftmals über einen Browser. Sie bieten den großen Vorteil, dass der Zugriff von nahezu überall möglich ist und Teams dezentral an einem Projekt arbeiten können.\n\nLokale IDEs werden auf dem Rechner von  Mitarbeiter(inne)n gespeichert. Diese Form verliert zunehmend an Beliebtheit. Trotzdem haben sich Cloud-Lösungen noch nicht so durchgesetzt wie in anderen Bereichen der IT-Branche. Auf die Gründe dafür gehen wir gleich ein.\nStandardized Development Environments: Jedes Unternehmen hat seine eigenen Bedürfnisse. \n\nCloudbasierte und lokale Anwendungen mögen umfangreich und flexibel sein, doch bleiben sie letzten Endes generisch. Wenn du eine personalisierte Lösung für deine Teams bevorzugst, kann eine aus einzelnen Bausteinen zusammengesetzte, modulare IDE Sinn ergeben. Mit einer solchen SDE definierst du für dein Unternehmen einen eigenen Standard.\nFür manche Entwickler(innen) kommt noch eine vierte Variante hinzu: Eine komplett selbst zusammengestellte, personalisierte IDE. In besonders anspruchsvollen Projekten kann das Sinn ergeben. Für die meisten Unternehmen jedoch ergeben sich aus einer Vielzahl individueller Umgebungen zu viele Abstimmungsprobleme.\n\n## Wonach sollte ich meine IDE auswählen?\n\nDer Markt für IDEs ist inzwischen sogar für erfahrene Entwickler(innen) unübersichtlich geworden. Und so finden sich zahlreiche Foren, in denen man sich austauscht und berät, welche IDE für die eigenen Ziele am besten geeignet ist.\n\nNatürlich hängt diese Entscheidung unter anderem auch von dem Projekt ab, an dem du arbeitest. Darüber hinaus gibt es einige Aspekte, die du ebenfalls berücksichtigen solltest.\n\nDer erste ist, mit welcher Programmiersprache du vorhast, zu arbeiten. IDEs unterstützen eine Vielzahl von Sprachen, dennoch sind manche IDEs schlicht besser auf bestimmte Sprachen abgestimmt als auf andere.\n\nDas gleiche gilt für die Funktionalität. Die meisten Bausteine wirst du in jeder IDE finden. Trotzdem lohnt es sich, im Team nachzufragen, ob Wünsche bestehen, die eventuell nicht von jeder gängigen IDE abgedeckt werden.\n\nDie beiden wichtigsten Punkte bei der Auswahl der IDE sind aber zweifelsfrei Performance und Community Support. Da integrierte Entwicklungsebenen heutzutage so umfangreich sind, stellen sie oftmals auch eine Performance-Belastung für das System dar. Dies wiegt umso schwerer bei cloudbasierten IDEs. Communities wiederum bieten Unterstützung bei Problemen und treiben die Entwicklung der Software organisch voran. \n\n## Was ist die beste IDE?\n\nJeder Artikel, welcher dieser Frage nachgeht, fängt mit der Feststellung an, dass es keine beste IDE geben kann, da jede Aufgabe und jedes Team sehr spezifische Anforderungen und Präferenzen hat. Die Bewertung einer IDE ist somit unmittelbar mit der Definition der Aufgaben verbunden. \n\nDas ist ganz gewiss richtig. Dennoch fällt auf, dass, unabhängig von der Plattform oder dem Projekt, bestimmte IDEs von Experten weitaus öfter genannt werden als andere. Offenbar erfüllen manche integrierte Entwicklungsumgebungen die Bedürfnisse von breiten Anwender(innen)gruppen.\n\nUm dir einen besseren Überblick zu verschaffen, haben wir das Netz durchkämmt und die wichtigsten englischsprachigen Artikel sowie die am höchsten rankenden deutschen Artikel zu diesem Thema analysiert. \n\nAus diesen haben wir eine Rangliste erstellt. In den Klammern findest du die Zahl der Nennungen dieser IDE als eine der besten:\n\n1. Visual Studio (10x)\n2. Eclipse (8x)\n    IntelliJ (8x)\n    NetBeans (8x)\n5. Android (6x)\n    Code::Blocks (6x)\n7. Atom (5x)\n    PyCharm (5x)\n9. AWS Cloud 9 (4x)\n    RubyMine (4x)\n    WebStorm (4x)\n    Xcode (4x)\n    Zend (4x)\n\nAuch wenn jedes dieser Programme die Anforderungen an eine zeitgemäße IDE erfüllt, bestehen zwischen ihnen teilweise erhebliche Unterschiede. Werfen wir deswegen einen genaueren Blick auf einige IDE-Beispiele, um dies zu verdeutlichen.\n\n### IDE Eclipse\n\nWer sich mit der Geschichte von IDEs auseinandersetzt, wird zwangsläufig auf Eclipse IDE stoßen. Hierbei handelt es sich um eine integrierte Entwicklungsumgebung, die ursprünglich von IBM entwickelt wurde und nun als Freeware zur Verfügung steht. In einer schnelllebigen Branche ist Eclipse eine nahezu unvorstellbare Erfolgsgeschichte: Seit fast einem Vierteljahrhundert nutzen Entwickler(innen) diese Software, um an Projekten zu arbeiten.\n\nMan muss offen zugeben, dass der Zahn der Zeit nicht spurlos an Eclipse vorbeigegangen ist. Im direkten Vergleich zu aktuellen Alternativen hat die Oberfläche einen deutlichen Retro-Touch. Die Anwendung ist eher langsam und von gelegentlichen Abstürzen geplagt.\n\nDem steht allerdings ein umfangreicher Erfahrungsschatz gegenüber und eine nahezu endlose Palette an Erweiterungen und Plug-ins. Für manche Entwickler(innen) bietet Eclipse einen guten Workflow, den vermeintlich innovativere neue Lösungen immer noch nicht erreichen.\n\n### Dreamweaver\n\nDreamweaver ist ein interessantes Beispiel für eine spezialisierte IDE. Zwar verfügt die von Adobe vertriebene Anwendung auch über eine Code-Editor, der Dreamweaver zu einer vollwertigen IDE aufwertet, ihr Haupteinsatzgebiet aber ist die Website-Programmierung.\n\nViele Jahre lang war Dreamweaver in diesem Bereich der globale Führer. Für das Programm sprechen auch weiterhin seine Robustheit und die große User-Community, die gerne bei Problemen und Fragen behilflich ist. Der Editor erlaubt eine direkte Sicht auf die fertige Website, was vielen Entwicklern entgegenkommt.\n\nNachteilig aber ist, dass Dreamweaver sich in den letzten Jahren wenig weiterentwickelt hat und aus Sicht vieler professioneller Anwender(innen) nicht mehr sinnvoll für große kommerzielle Websites verwendet werden kann. Die Performance ist zudem nicht optimal und der von Dreamweaver generierte Code ein wenig „aufgebläht”.\n\nFür einfache Projekte aber kann Dreamweaver auch weiterhin eine hervorragende Lösung darstellen.\n\n### IntelliJ\n\nIntelliJ gilt bei vielen als die derzeit beste IDE.\n\nIn dieser Anwendung verbinden sich traditionelle Tugenden – ein großer Funktionsumfang, kostenlose Einstiegsversion – mit innovativen neuen Features und einer großen, umtriebigen Community. Zwar ist die kostenpflichtige Ultimate Edition mit einem Jahresbeitrag von knapp 560 Euro im Jahr nicht günstig, für viele Unternehmen ist die Investition ihr Geld aber wert.\n\nWer im Netz nach Erfahrungen mit der IntelliJ IDE sucht, wird gelegentlich Beschwerden finden, diese Integrated Development Environment sei langsam und die Ladezeiten seien recht hoch. Gemeinhin fallen die Ladezeiten aber nur beim Neustart negativ auf. Gegenüber der direkten Konkurrenz und vor allem gegenüber älteren Alternativen wie Eclipse fällt IntelliJ hier keineswegs ab.\n\nMan kann sagen, dass diese Beschwerden daher rühren, dass Anwender(innen) von IntelliJ besonders fortschrittlich denken und hohe Ansprüche haben. Bis jetzt hat sich das dahinterstehende Unternehmen Jetbrains mit seinen neuen Versionen immer wieder die Treue seiner Nutzer(innen) gesichert.\n\nIntelliJ mag nicht perfekt sein, derzeit aber kommt diese IDE dem Ideal einer IDE recht nahe. Überboten wird sie aus der Sicht von Entwickler(inne)n und Expert(inn)en, wenn überhaupt, nur von einem einzigen Konkurrenzprodukt:\n\n### IDE Visual Studio\n\nEs überrascht kaum, dass auf einem so begehrten Markt wie dem für integrierte Entwicklungsumgebungen auch die großen Global Players mitmischen wollen. So bietet Apple Xcode an, Google's Cloud Workstations beinhaltet eine webbasierte IDE und Amazon geht mit seiner AWS Cloud9 an den Start.\n\nKeine dieser IDEs aber erreicht den Stellenwert von Microsofts IDE Visual Studio. Eine der stärksten Funktionen dieser IDE liegt in ihrer nahtlosen, organischen und äußerst funktionalen Einbindung von KI. Aber ganz allgemein ist der Funktionsumfang der Software bemerkenswert. Es bleiben hier wahrhaft kaum Wünsche offen.\n\nAls die Website Onlinekurse das Visual Studio bewertete, fiel ihr nur ein einziger ernstzunehmender Einwand ein, der eher nach einem versteckten Kompliment als einer Kritik klingt: „[Die] Vielfalt an Optionen macht die Ersteinrichtung und Konfiguration schwierig.” \n\n### GitLab\n\nAuch GitLab hat eine eigene cloudbasierte IDE. Das ergibt Sinn, weil die direkte Einbindung in das Projektmanagement eine noch bessere Umsetzung agiler Methoden ermöglicht.\n\nMit der GitLab-IDE steht dir ein voll funktionsfähige integrierte Entwicklungsumgebung zur Verfügung. In einer ausführlichen Einführung und Übersicht in die GitLab-IDE kannst du dich informieren, ob sie für dich und dein Team eine gelungene Alternative zu den oben genannten Angeboten darstellt.\n\nWenn du die GitLab-IDE in der Praxis testen möchtest, nutze unsere GitLab-Testversion und arbeite 30 Tage kostenlos damit. \n\n## IDE-FAQs\n\n### Was ist die beste Einsteiger-IDE? Was ist die beste IDE für erfahrene Entwickler(innen)?\n\nDie Ansprüche von erfahrenen Entwickler(inne)n und Anfänger(inne)n an eine IDE unterscheiden sich erheblich.\n\nFür Anfänger(innen) ist es entscheidend, dass die Anwendung stabil läuft, eine klar strukturierte Oberfläche aufweist und die Basisfunktionen intuitiv zu bedienen sind. Eine allzu umfangreiche Palette an Möglichkeiten kann hier sogar einen Nachteil darstellen.\n\nFür professionelle, erfahrene Programmierer(innen) hingegen sind oftmals Performance und Individualisierungsfähigkeit wichtigere Faktoren. Für sie sind gelegentlich sogar Cloud-IDEs keine gute Option, da sie langsamer als lokale IDEs sind. Auch kann eine innovative Produktweiterentwicklung für sie einen höheren Stellenwert einnehmen als Stabilität.\nWährend IDEs als Alles-in-einem-Paketlösungen für Einsteiger(innen) ein hervorragendes Konzept bieten, präferieren manche Entwickler(innen) es, in einem einfachen Code-Editor zu arbeiten und für die darüber hinaus anfallenden Schritte jeweils individuelle Apps zu nutzen.\n\nVon den genannten IDEs bietet wohl das Visual Studio den besten Kompromiss, da es sowohl umfangreich und innovativ als auch einfach zu bedienen ist.\n\n### Hat die Verwendung von IDEs auch Nachteile?\n\nDie meisten IDEs funktionieren hervorragend und machen die Arbeit an einem Projekt deutlich einfacher. Trotzdem solltest du bei der Verwendung einer integrierten Entwicklungsumgebung stets beachten, dass es auch gewisse Nachteile gibt:\n\nPaketlösungen bieten in der Regel eine sehr gute Qualität ihrer Einzelanwendungen, die Komponenten erreichen aber eher selten Spitzenwerte. So ist es durchaus denkbar, dass bestimmte Individuallösungen besser sind als die entsprechenden Komponenten einer IDE.\nJede IDE wird die Performance einschränken, da bei ihr mehr Komponenten in den Speicher geladen werden als bei Einzelanwendungen. \n\nWer sich zu sehr auf ein bestimmtes System verlässt, bewegt sich zwangsläufig in Richtung eines „Lock-Ins”. Dieses Risiko ist natürlich auch bei IDEs gegeben. Allerdings ist es in den letzten Jahren gesunken, da IDEs zunehmend mit allgemeinen Standards arbeiten. So fällt der Wechsel von einer IDE zur anderen oftmals sehr undramatisch aus.\n",[18],"GitLab Germany Team","2025-05-14","2024-11-13","Was ist eine integrierte Entwicklungsumgebung (IDE)?",[23,24],"solutions architecture","embedded DevOps","Der ultimative Guide: Alles, was du über Integrierte Entwicklungsumgebungen wissen musst.","yml",{},true,"/de-de/blog/what-is-an-ide",{"ogTitle":31,"ogImage":15,"ogDescription":32,"ogSiteName":33,"noIndex":12,"ogType":34,"ogUrl":35,"title":31,"canonicalUrls":35,"description":32},"IDE: Integrierte Entwicklungsumgebung einfach erklärt ","Wir zeigen dir, was eine integrierte Entwicklungsumgebung (IDE) ist. ✓ Definition ✓ Unterschiede ✓ Komponenten ✓ Auswahl ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com","article","https://about.gitlab.com/blog/what-is-an-ide","de-de/blog/what-is-an-ide",[38,39],"solutions-architecture","embedded-devops","itL7DAVJBYytOZdLxV8lZt9RmGigc5G1VfBPezktJYg",{"data":42},{"logo":43,"freeTrial":48,"sales":53,"login":58,"items":63,"search":372,"minimal":407,"duo":425,"pricingDeployment":434},{"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,293,353],{"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":28,"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":280},"Ressourcen",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"Alle Ressourcen anzeigen",{"href":199,"dataGaName":195,"dataGaLocation":47},"/de-de/resources/",[201,234,252],{"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":233,"dataGaLocation":47},"/de-de/integrations/","integrations",{"title":235,"items":236},"Entdecken",[237,242,247],{"text":238,"config":239},"Kundenerfolge",{"href":240,"dataGaName":241,"dataGaLocation":47},"/de-de/customers/","customer success stories",{"text":243,"config":244},"Blog",{"href":245,"dataGaName":246,"dataGaLocation":47},"/de-de/blog/","blog",{"text":248,"config":249},"Remote",{"href":250,"dataGaName":251,"dataGaLocation":47},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":253,"items":254},"Vernetzen",[255,260,265,270,275],{"text":256,"config":257},"GitLab-Services",{"href":258,"dataGaName":259,"dataGaLocation":47},"/de-de/services/","services",{"text":261,"config":262},"Community",{"href":263,"dataGaName":264,"dataGaLocation":47},"/community/","community",{"text":266,"config":267},"Forum",{"href":268,"dataGaName":269,"dataGaLocation":47},"https://forum.gitlab.com/","forum",{"text":271,"config":272},"Veranstaltungen",{"href":273,"dataGaName":274,"dataGaLocation":47},"/events/","events",{"text":276,"config":277},"Partner",{"href":278,"dataGaName":279,"dataGaLocation":47},"/de-de/partners/","partners",{"backgroundColor":281,"textColor":282,"text":283,"image":284,"link":288},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":285,"config":286},"the source promo card",{"src":287},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":289,"config":290},"Lies die News",{"href":291,"dataGaName":292,"dataGaLocation":47},"/de-de/the-source/","the source",{"text":294,"config":295,"lists":297},"Unternehmen",{"dataNavLevelOne":296},"company",[298],{"items":299},[300,305,311,313,318,323,328,333,338,343,348],{"text":301,"config":302},"Über",{"href":303,"dataGaName":304,"dataGaLocation":47},"/de-de/company/","about",{"text":306,"config":307,"footerGa":310},"Karriere",{"href":308,"dataGaName":309,"dataGaLocation":47},"/jobs/","jobs",{"dataGaName":309},{"text":271,"config":312},{"href":273,"dataGaName":274,"dataGaLocation":47},{"text":314,"config":315},"Geschäftsführung",{"href":316,"dataGaName":317,"dataGaLocation":47},"/company/team/e-group/","leadership",{"text":319,"config":320},"Team",{"href":321,"dataGaName":322,"dataGaLocation":47},"/company/team/","team",{"text":324,"config":325},"Handbuch",{"href":326,"dataGaName":327,"dataGaLocation":47},"https://handbook.gitlab.com/","handbook",{"text":329,"config":330},"Investor Relations",{"href":331,"dataGaName":332,"dataGaLocation":47},"https://ir.gitlab.com/","investor relations",{"text":334,"config":335},"Trust Center",{"href":336,"dataGaName":337,"dataGaLocation":47},"/de-de/security/","trust center",{"text":339,"config":340},"AI Transparency Center",{"href":341,"dataGaName":342,"dataGaLocation":47},"/de-de/ai-transparency-center/","ai transparency center",{"text":344,"config":345},"Newsletter",{"href":346,"dataGaName":347,"dataGaLocation":47},"/company/contact/#contact-forms","newsletter",{"text":349,"config":350},"Presse",{"href":351,"dataGaName":352,"dataGaLocation":47},"/press/","press",{"text":354,"config":355,"lists":356},"Kontakt",{"dataNavLevelOne":296},[357],{"items":358},[359,362,367],{"text":54,"config":360},{"href":56,"dataGaName":361,"dataGaLocation":47},"talk to sales",{"text":363,"config":364},"Support-Portal",{"href":365,"dataGaName":366,"dataGaLocation":47},"https://support.gitlab.com","support portal",{"text":368,"config":369},"Kundenportal",{"href":370,"dataGaName":371,"dataGaLocation":47},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":373,"login":374,"suggestions":381},"Schließen",{"text":375,"link":376},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":377,"config":378},"gitlab.com",{"href":61,"dataGaName":379,"dataGaLocation":380},"search login","search",{"text":382,"default":383},"Vorschläge",[384,386,391,393,398,403],{"text":76,"config":385},{"href":81,"dataGaName":76,"dataGaLocation":380},{"text":387,"config":388},"Code Suggestions (KI)",{"href":389,"dataGaName":390,"dataGaLocation":380},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":110,"config":392},{"href":112,"dataGaName":110,"dataGaLocation":380},{"text":394,"config":395},"GitLab auf AWS",{"href":396,"dataGaName":397,"dataGaLocation":380},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":399,"config":400},"GitLab auf Google Cloud",{"href":401,"dataGaName":402,"dataGaLocation":380},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":404,"config":405},"Warum GitLab?",{"href":89,"dataGaName":406,"dataGaLocation":380},"Why GitLab?",{"freeTrial":408,"mobileIcon":413,"desktopIcon":418,"secondaryButton":421},{"text":409,"config":410},"Kostenlos testen",{"href":411,"dataGaName":52,"dataGaLocation":412},"https://gitlab.com/-/trials/new/","nav",{"altText":414,"config":415},"GitLab-Symbol",{"src":416,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":414,"config":419},{"src":420,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":202,"config":422},{"href":423,"dataGaName":424,"dataGaLocation":412},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":426,"mobileIcon":430,"desktopIcon":432},{"text":427,"config":428},"Erfahre mehr über GitLab Duo",{"href":81,"dataGaName":429,"dataGaLocation":412},"gitlab duo",{"altText":414,"config":431},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":433},{"src":420,"dataGaName":417,"dataGaLocation":412},{"freeTrial":435,"mobileIcon":440,"desktopIcon":442},{"text":436,"config":437},"Zurück zur Preisübersicht",{"href":190,"dataGaName":438,"dataGaLocation":412,"icon":439},"back to pricing","GoBack",{"altText":414,"config":441},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":443},{"src":420,"dataGaName":417,"dataGaLocation":412},{"title":445,"button":446,"config":451},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":447,"config":448},"GitLab Transcend jetzt ansehen",{"href":449,"dataGaName":450,"dataGaLocation":47},"/de-de/events/transcend/virtual/","transcend event",{"layout":452,"icon":453,"disabled":28},"release","AiStar",{"data":455},{"text":456,"source":457,"edit":463,"contribute":468,"config":473,"items":478,"minimal":651},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":458,"config":459},"Quelltext der Seite anzeigen",{"href":460,"dataGaName":461,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":464,"config":465},"Diese Seite bearbeiten",{"href":466,"dataGaName":467,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":469,"config":470},"Beteilige dich",{"href":471,"dataGaName":472,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":474,"facebook":475,"youtube":476,"linkedin":477},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[479,502,557,584,618],{"title":65,"links":480,"subMenu":485},[481],{"text":482,"config":483},"DevSecOps-Plattform",{"href":74,"dataGaName":484,"dataGaLocation":462},"devsecops platform",[486],{"title":188,"links":487},[488,492,497],{"text":489,"config":490},"Tarife anzeigen",{"href":190,"dataGaName":491,"dataGaLocation":462},"view plans",{"text":493,"config":494},"Vorteile von Premium",{"href":495,"dataGaName":496,"dataGaLocation":462},"/de-de/pricing/premium/","why premium",{"text":498,"config":499},"Vorteile von Ultimate",{"href":500,"dataGaName":501,"dataGaLocation":462},"/de-de/pricing/ultimate/","why ultimate",{"title":503,"links":504},"Lösungen",[505,510,513,515,520,525,529,532,535,540,542,544,547,552],{"text":506,"config":507},"Digitale Transformation",{"href":508,"dataGaName":509,"dataGaLocation":462},"/de-de/topics/digital-transformation/","digital transformation",{"text":511,"config":512},"Sicherheit und Compliance",{"href":130,"dataGaName":137,"dataGaLocation":462},{"text":122,"config":514},{"href":106,"dataGaName":107,"dataGaLocation":462},{"text":516,"config":517},"Agile Entwicklung",{"href":518,"dataGaName":519,"dataGaLocation":462},"/de-de/solutions/agile-delivery/","agile delivery",{"text":521,"config":522},"Cloud-Transformation",{"href":523,"dataGaName":524,"dataGaLocation":462},"/de-de/topics/cloud-native/","cloud transformation",{"text":526,"config":527},"SCM",{"href":119,"dataGaName":528,"dataGaLocation":462},"source code management",{"text":110,"config":530},{"href":112,"dataGaName":531,"dataGaLocation":462},"continuous integration & delivery",{"text":160,"config":533},{"href":162,"dataGaName":534,"dataGaLocation":462},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":462},"/de-de/solutions/gitops/","gitops",{"text":173,"config":541},{"href":175,"dataGaName":176,"dataGaLocation":462},{"text":178,"config":543},{"href":180,"dataGaName":181,"dataGaLocation":462},{"text":545,"config":546},"Öffentlicher Sektor",{"href":185,"dataGaName":186,"dataGaLocation":462},{"text":548,"config":549},"Bildungswesen",{"href":550,"dataGaName":551,"dataGaLocation":462},"/de-de/solutions/education/","education",{"text":553,"config":554},"Finanzdienstleistungen",{"href":555,"dataGaName":556,"dataGaLocation":462},"/de-de/solutions/finance/","financial services",{"title":193,"links":558},[559,561,563,565,568,570,572,574,576,578,580,582],{"text":205,"config":560},{"href":207,"dataGaName":208,"dataGaLocation":462},{"text":210,"config":562},{"href":212,"dataGaName":213,"dataGaLocation":462},{"text":215,"config":564},{"href":217,"dataGaName":218,"dataGaLocation":462},{"text":220,"config":566},{"href":222,"dataGaName":567,"dataGaLocation":462},"docs",{"text":243,"config":569},{"href":245,"dataGaName":246,"dataGaLocation":462},{"text":238,"config":571},{"href":240,"dataGaName":241,"dataGaLocation":462},{"text":248,"config":573},{"href":250,"dataGaName":251,"dataGaLocation":462},{"text":256,"config":575},{"href":258,"dataGaName":259,"dataGaLocation":462},{"text":261,"config":577},{"href":263,"dataGaName":264,"dataGaLocation":462},{"text":266,"config":579},{"href":268,"dataGaName":269,"dataGaLocation":462},{"text":271,"config":581},{"href":273,"dataGaName":274,"dataGaLocation":462},{"text":276,"config":583},{"href":278,"dataGaName":279,"dataGaLocation":462},{"title":294,"links":585},[586,588,590,592,594,596,598,602,607,609,611,613],{"text":301,"config":587},{"href":303,"dataGaName":296,"dataGaLocation":462},{"text":306,"config":589},{"href":308,"dataGaName":309,"dataGaLocation":462},{"text":314,"config":591},{"href":316,"dataGaName":317,"dataGaLocation":462},{"text":319,"config":593},{"href":321,"dataGaName":322,"dataGaLocation":462},{"text":324,"config":595},{"href":326,"dataGaName":327,"dataGaLocation":462},{"text":329,"config":597},{"href":331,"dataGaName":332,"dataGaLocation":462},{"text":599,"config":600},"Sustainability",{"href":601,"dataGaName":599,"dataGaLocation":462},"/sustainability/",{"text":603,"config":604},"Vielfalt, Inklusion und Zugehörigkeit",{"href":605,"dataGaName":606,"dataGaLocation":462},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":334,"config":608},{"href":336,"dataGaName":337,"dataGaLocation":462},{"text":344,"config":610},{"href":346,"dataGaName":347,"dataGaLocation":462},{"text":349,"config":612},{"href":351,"dataGaName":352,"dataGaLocation":462},{"text":614,"config":615},"Transparenzerklärung zu moderner Sklaverei",{"href":616,"dataGaName":617,"dataGaLocation":462},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":619,"links":620},"Nimm Kontakt auf",[621,624,629,631,636,641,646],{"text":622,"config":623},"Sprich mit einem Experten/einer Expertin",{"href":56,"dataGaName":57,"dataGaLocation":462},{"text":625,"config":626},"Support",{"href":627,"dataGaName":628,"dataGaLocation":462},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":368,"config":630},{"href":370,"dataGaName":371,"dataGaLocation":462},{"text":632,"config":633},"Status",{"href":634,"dataGaName":635,"dataGaLocation":462},"https://status.gitlab.com/","status",{"text":637,"config":638},"Nutzungsbedingungen",{"href":639,"dataGaName":640,"dataGaLocation":462},"/terms/","terms of use",{"text":642,"config":643},"Datenschutzerklärung",{"href":644,"dataGaName":645,"dataGaLocation":462},"/de-de/privacy/","privacy statement",{"text":647,"config":648},"Cookie-Einstellungen",{"dataGaName":649,"dataGaLocation":462,"id":650,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":462},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":462},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":462,"id":650,"isOneTrustButton":28},[660],{"id":661,"title":662,"body":8,"config":663,"content":665,"description":8,"extension":26,"meta":669,"navigation":28,"path":670,"seo":671,"stem":672,"__hash__":673},"blogAuthors/en-us/blog/authors/gitlab-germany-team.yml","Gitlab Germany Team",{"template":664},"BlogAuthor",{"name":18,"config":666},{"headshot":667,"ctfId":668},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","6tNquF8jQeRRRi8k3ZXpvS",{},"/en-us/blog/authors/gitlab-germany-team",{},"en-us/blog/authors/gitlab-germany-team","vGs9BT_ji6dORS29vl80DKX6mSputlQV2W7-4vW2hL8",[675,690,703],{"content":676,"config":688},{"body":677,"title":678,"description":679,"authors":680,"heroImage":682,"date":683,"category":9,"tags":684},"## 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.",[681],"Omid Khan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","2026-04-09",[110,685,686,687],"DevOps platform","tutorial","features",{"featured":28,"template":13,"slug":689},"5-ways-gitlab-pipeline-logic-solves-real-engineering-problems",{"content":691,"config":701},{"title":692,"description":693,"authors":694,"heroImage":696,"date":697,"body":698,"category":9,"tags":699},"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.",[695],"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.",[686,700,687],"product",{"featured":12,"template":13,"slug":702},"using-gitlab-container-virtual-registry-with-docker-hardened-images",{"content":704,"config":715},{"category":9,"tags":705,"body":707,"date":708,"heroImage":709,"authors":710,"title":713,"description":714},[686,706,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",[711,712],"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":28,"template":13,"slug":716},"migration-from-azure-devops-to-gitlab",{"promotions":718},[719,733,745,757],{"id":720,"categories":721,"header":723,"text":724,"button":725,"image":730},"ai-modernization",[722],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":726,"config":727},"Get your AI maturity score",{"href":728,"dataGaName":729,"dataGaLocation":246},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":731},{"src":732},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":734,"categories":735,"header":737,"text":724,"button":738,"image":742},"devops-modernization",[700,736],"devsecops","Are you just managing tools or shipping innovation?",{"text":739,"config":740},"Get your DevOps maturity score",{"href":741,"dataGaName":729,"dataGaLocation":246},"/assessments/devops-modernization-assessment/",{"config":743},{"src":744},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":746,"categories":747,"header":749,"text":724,"button":750,"image":754},"security-modernization",[748],"security","Are you trading speed for security?",{"text":751,"config":752},"Get your security maturity score",{"href":753,"dataGaName":729,"dataGaLocation":246},"/assessments/security-modernization-assessment/",{"config":755},{"src":756},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":758,"paths":759,"header":761,"text":762,"button":763,"image":768},"github-azure-migration",[716,760],"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":764,"config":765},"See how GitLab compares to GitHub",{"href":766,"dataGaName":767,"dataGaLocation":246},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":769},{"src":744},{"header":771,"blurb":772,"button":773,"secondaryButton":778},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":774,"config":775},"Kostenlosen Test starten",{"href":776,"dataGaName":52,"dataGaLocation":777},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":54,"config":779},{"href":56,"dataGaName":57,"dataGaLocation":777},1776449937186]