[{"data":1,"prerenderedAt":787},["ShallowReactive",2],{"/en-us/blog/tags/solutions-architecture/":3,"navigation-de-de":20,"banner-de-de":441,"footer-de-de":454,"solutions architecture-tag-page-de-de":663},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/solutions-architecture","tags",false,"",{"tag":9,"tagSlug":10},"solutions architecture","solutions-architecture",{"template":12},"BlogTag","content:en-us:blog:tags:solutions-architecture.yml","yaml","Solutions Architecture","content","en-us/blog/tags/solutions-architecture.yml","en-us/blog/tags/solutions-architecture","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":437,"_type":14,"title":438,"_source":16,"_file":439,"_stem":440,"_extension":19},"/shared/de-de/main-navigation","de-de",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":378,"minimal":414,"duo":428},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/de-de/","gitlab logo","header",{"text":30,"config":31},"Kostenlose Testversion anfordern",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Vertrieb kontaktieren",{"href":37,"dataGaName":38,"dataGaLocation":28},"/de-de/sales/","sales",{"text":40,"config":41},"Anmelden",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,299,359],{"text":46,"config":47,"cards":49,"footer":72},"Plattform",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":53,"config":54},"Erkunde unsere Plattform",{"href":55,"dataGaName":48,"dataGaLocation":28},"/de-de/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":60,"config":61},"Lerne GitLab Duo kennen",{"href":62,"dataGaName":63,"dataGaLocation":28},"/de-de/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":68,"config":69},"Mehr erfahren",{"href":70,"dataGaName":71,"dataGaLocation":28},"/de-de/why-gitlab/","why gitlab",{"title":73,"items":74},"Erste Schritte mit",[75,80,85],{"text":76,"config":77},"Platform Engineering",{"href":78,"dataGaName":79,"dataGaLocation":28},"/de-de/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Entwicklererfahrung",{"href":83,"dataGaName":84,"dataGaLocation":28},"/de-de/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"Produkt",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Alle Lösungen anzeigen",{"href":97,"dataGaName":93,"dataGaLocation":28},"/de-de/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/de-de/solutions/continuous-integration/",{"text":113,"config":114},"KI-unterstützte Entwicklung",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Quellcodeverwaltung",{"href":119,"dataGaLocation":28,"dataGaName":120},"/de-de/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Automatisierte Softwarebereitstellung",{"href":105,"dataGaLocation":28,"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":28,"icon":132},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":28,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"Bewertung",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Sichtbarkeit und Bewertung",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Wertstrommanagement",{"href":163,"dataGaLocation":28,"dataGaName":164},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Analysen und Einblicke",{"href":168,"dataGaLocation":28,"dataGaName":169},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab für",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":28,"dataGaName":177},"/de-de/enterprise/","enterprise",{"text":179,"config":180},"Kleinunternehmen",{"href":181,"dataGaLocation":28,"dataGaName":182},"/de-de/small-business/","small business",{"text":184,"config":185},"den öffentlichen Sektor",{"href":186,"dataGaLocation":28,"dataGaName":187},"/de-de/solutions/public-sector/","public sector",{"text":189,"config":190},"Preise",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/de-de/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"Ressourcen",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Alle Ressourcen anzeigen",{"href":200,"dataGaName":196,"dataGaLocation":28},"/de-de/resources/",[202,235,258],{"title":203,"items":204},"Erste Schritte",[205,210,215,220,225,230],{"text":206,"config":207},"Installieren",{"href":208,"dataGaName":209,"dataGaLocation":28},"/de-de/install/","install",{"text":211,"config":212},"Kurzanleitungen",{"href":213,"dataGaName":214,"dataGaLocation":28},"/de-de/get-started/","quick setup checklists",{"text":216,"config":217},"Lernen",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Produktdokumentation",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Best-Practice-Videos",{"href":228,"dataGaName":229,"dataGaLocation":28},"/de-de/getting-started-videos/","best practice videos",{"text":231,"config":232},"Integrationen",{"href":233,"dataGaName":234,"dataGaLocation":28},"/de-de/integrations/","integrations",{"title":236,"items":237},"Entdecken",[238,243,248,253],{"text":239,"config":240},"Kundenerfolge",{"href":241,"dataGaName":242,"dataGaLocation":28},"/de-de/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":28},"/de-de/blog/","blog",{"text":249,"config":250},"Remote",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/de-de/teamops/","teamops",{"title":259,"items":260},"Vernetzen",[261,266,271,276,281],{"text":262,"config":263},"GitLab-Services",{"href":264,"dataGaName":265,"dataGaLocation":28},"/de-de/services/","services",{"text":267,"config":268},"Community",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Veranstaltungen",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"Partner",{"href":284,"dataGaName":285,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":291,"config":292},"the source promo card",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"Lies die News",{"href":297,"dataGaName":298,"dataGaLocation":28},"/de-de/the-source/","the source",{"text":300,"config":301,"lists":303},"Unternehmen",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"Über",{"href":309,"dataGaName":310,"dataGaLocation":28},"/de-de/company/","about",{"text":312,"config":313,"footerGa":316},"Karriere",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"Geschäftsführung",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"Team",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"Handbuch",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Investor Relations",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Trust Center",{"href":342,"dataGaName":343,"dataGaLocation":28},"/de-de/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":28},"/de-de/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"Presse",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":360,"config":361,"lists":362},"Kontakt",{"dataNavLevelOne":302},[363],{"items":364},[365,368,373],{"text":35,"config":366},{"href":37,"dataGaName":367,"dataGaLocation":28},"talk to sales",{"text":369,"config":370},"Support",{"href":371,"dataGaName":372,"dataGaLocation":28},"/support/","get help",{"text":374,"config":375},"Kundenportal",{"href":376,"dataGaName":377,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":379,"login":380,"suggestions":387},"Schließen",{"text":381,"link":382},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":383,"config":384},"gitlab.com",{"href":42,"dataGaName":385,"dataGaLocation":386},"search login","search",{"text":388,"default":389},"Vorschläge",[390,393,398,400,405,410],{"text":57,"config":391},{"href":62,"dataGaName":392,"dataGaLocation":386},"GitLab Duo (AI)",{"text":394,"config":395},"Code Suggestions (KI)",{"href":396,"dataGaName":397,"dataGaLocation":386},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":399},{"href":111,"dataGaName":109,"dataGaLocation":386},{"text":401,"config":402},"GitLab auf AWS",{"href":403,"dataGaName":404,"dataGaLocation":386},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":406,"config":407},"GitLab auf Google Cloud",{"href":408,"dataGaName":409,"dataGaLocation":386},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":411,"config":412},"Warum GitLab?",{"href":70,"dataGaName":413,"dataGaLocation":386},"Why GitLab?",{"freeTrial":415,"mobileIcon":420,"desktopIcon":425},{"text":416,"config":417},"Kostenlos testen",{"href":418,"dataGaName":33,"dataGaLocation":419},"https://gitlab.com/-/trials/new/","nav",{"altText":421,"config":422},"GitLab-Symbol",{"src":423,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":421,"config":426},{"src":427,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"Erfahre mehr über GitLab Duo",{"href":62,"dataGaName":432,"dataGaLocation":419},"gitlab duo",{"altText":421,"config":434},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":436},{"src":427,"dataGaName":424,"dataGaLocation":419},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":442,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":443,"button":444,"config":449,"_id":451,"_type":14,"_source":16,"_file":452,"_stem":453,"_extension":19},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":445,"config":446},"Beta testen",{"href":447,"dataGaName":448,"dataGaLocation":28},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":450},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":455,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":456,"_id":659,"_type":14,"title":660,"_source":16,"_file":661,"_stem":662,"_extension":19},"/shared/de-de/main-footer",{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":651},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":459,"config":460},"Quelltext der Seite anzeigen",{"href":461,"dataGaName":462,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":465,"config":466},"Diese Seite bearbeiten",{"href":467,"dataGaName":468,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":470,"config":471},"Beteilige dich",{"href":472,"dataGaName":473,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":475,"facebook":476,"youtube":477,"linkedin":478},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[480,503,558,587,621],{"title":46,"links":481,"subMenu":486},[482],{"text":483,"config":484},"DevSecOps-Plattform",{"href":55,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":189,"links":488},[489,493,498],{"text":490,"config":491},"Tarife anzeigen",{"href":191,"dataGaName":492,"dataGaLocation":463},"view plans",{"text":494,"config":495},"Vorteile von Premium",{"href":496,"dataGaName":497,"dataGaLocation":463},"/de-de/pricing/premium/","why premium",{"text":499,"config":500},"Vorteile von Ultimate",{"href":501,"dataGaName":502,"dataGaLocation":463},"/de-de/pricing/ultimate/","why ultimate",{"title":504,"links":505},"Lösungen",[506,511,514,516,521,526,530,533,536,541,543,545,548,553],{"text":507,"config":508},"Digitale Transformation",{"href":509,"dataGaName":510,"dataGaLocation":463},"/de-de/topics/digital-transformation/","digital transformation",{"text":512,"config":513},"Sicherheit und Compliance",{"href":137,"dataGaName":138,"dataGaLocation":463},{"text":122,"config":515},{"href":105,"dataGaName":106,"dataGaLocation":463},{"text":517,"config":518},"Agile Entwicklung",{"href":519,"dataGaName":520,"dataGaLocation":463},"/de-de/solutions/agile-delivery/","agile delivery",{"text":522,"config":523},"Cloud-Transformation",{"href":524,"dataGaName":525,"dataGaLocation":463},"/de-de/topics/cloud-native/","cloud transformation",{"text":527,"config":528},"SCM",{"href":119,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":109,"config":531},{"href":111,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":161,"config":534},{"href":163,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/de-de/solutions/gitops/","gitops",{"text":174,"config":542},{"href":176,"dataGaName":177,"dataGaLocation":463},{"text":179,"config":544},{"href":181,"dataGaName":182,"dataGaLocation":463},{"text":546,"config":547},"Öffentlicher Sektor",{"href":186,"dataGaName":187,"dataGaLocation":463},{"text":549,"config":550},"Bildungswesen",{"href":551,"dataGaName":552,"dataGaLocation":463},"/de-de/solutions/education/","education",{"text":554,"config":555},"Finanzdienstleistungen",{"href":556,"dataGaName":557,"dataGaLocation":463},"/de-de/solutions/finance/","financial services",{"title":194,"links":559},[560,562,564,566,569,571,573,575,577,579,581,583,585],{"text":206,"config":561},{"href":208,"dataGaName":209,"dataGaLocation":463},{"text":211,"config":563},{"href":213,"dataGaName":214,"dataGaLocation":463},{"text":216,"config":565},{"href":218,"dataGaName":219,"dataGaLocation":463},{"text":221,"config":567},{"href":223,"dataGaName":568,"dataGaLocation":463},"docs",{"text":244,"config":570},{"href":246,"dataGaName":247,"dataGaLocation":463},{"text":239,"config":572},{"href":241,"dataGaName":242,"dataGaLocation":463},{"text":249,"config":574},{"href":251,"dataGaName":252,"dataGaLocation":463},{"text":262,"config":576},{"href":264,"dataGaName":265,"dataGaLocation":463},{"text":254,"config":578},{"href":256,"dataGaName":257,"dataGaLocation":463},{"text":267,"config":580},{"href":269,"dataGaName":270,"dataGaLocation":463},{"text":272,"config":582},{"href":274,"dataGaName":275,"dataGaLocation":463},{"text":277,"config":584},{"href":279,"dataGaName":280,"dataGaLocation":463},{"text":282,"config":586},{"href":284,"dataGaName":285,"dataGaLocation":463},{"title":300,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":307,"config":590},{"href":309,"dataGaName":302,"dataGaLocation":463},{"text":312,"config":592},{"href":314,"dataGaName":315,"dataGaLocation":463},{"text":320,"config":594},{"href":322,"dataGaName":323,"dataGaLocation":463},{"text":325,"config":596},{"href":327,"dataGaName":328,"dataGaLocation":463},{"text":330,"config":598},{"href":332,"dataGaName":333,"dataGaLocation":463},{"text":335,"config":600},{"href":337,"dataGaName":338,"dataGaLocation":463},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":463},"/sustainability/",{"text":606,"config":607},"Vielfalt, Inklusion und Zugehörigkeit",{"href":608,"dataGaName":609,"dataGaLocation":463},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":611},{"href":342,"dataGaName":343,"dataGaLocation":463},{"text":350,"config":613},{"href":352,"dataGaName":353,"dataGaLocation":463},{"text":355,"config":615},{"href":357,"dataGaName":358,"dataGaLocation":463},{"text":617,"config":618},"Transparenzerklärung zu moderner Sklaverei",{"href":619,"dataGaName":620,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":622,"links":623},"Nimm Kontakt auf",[624,627,629,631,636,641,646],{"text":625,"config":626},"Sprich mit einem Experten/einer Expertin",{"href":37,"dataGaName":38,"dataGaLocation":463},{"text":369,"config":628},{"href":371,"dataGaName":372,"dataGaLocation":463},{"text":374,"config":630},{"href":376,"dataGaName":377,"dataGaLocation":463},{"text":632,"config":633},"Status",{"href":634,"dataGaName":635,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":637,"config":638},"Nutzungsbedingungen",{"href":639,"dataGaName":640,"dataGaLocation":463},"/terms/","terms of use",{"text":642,"config":643},"Datenschutzerklärung",{"href":644,"dataGaName":645,"dataGaLocation":463},"/de-de/privacy/","privacy statement",{"text":647,"config":648},"Cookie-Einstellungen",{"dataGaName":649,"dataGaLocation":463,"id":650,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":463},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":463},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":463,"id":650,"isOneTrustButton":91},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"allPosts":664,"featuredPost":765,"totalPagesCount":785,"initialPosts":786},[665,693,715,740],{"_path":666,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":667,"content":675,"config":686,"_id":689,"_type":14,"title":690,"_source":16,"_file":691,"_stem":692,"_extension":19},"/de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"title":668,"description":669,"ogTitle":668,"ogDescription":669,"noIndex":6,"ogImage":670,"ogUrl":671,"ogSiteName":672,"ogType":673,"canonicalUrls":671,"schema":674},"Datengesteuerte DevSecOps: Entdecke die Dashboards von GitLab Insights","Erfahre, wie du die Dashboards von GitLab Insights nutzen kannst, um wichtige Metriken zu visualisieren, Projekte nachzuverfolgen und die Produktivität deines Teams zu steigern.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097210/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097210214.png","https://about.gitlab.com/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Datengesteuerte DevSecOps: Entdecke die Dashboards von GitLab Insights\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ricardo Amarilla Villalba\"}],\n        \"datePublished\": \"2024-11-20\",\n      }\n                  ",{"title":668,"description":669,"authors":676,"heroImage":670,"date":678,"body":679,"category":680,"tags":681,"updatedDate":685},[677],"Ricardo Amarilla Villalba","2024-11-20","Metriken und Analysen spielen eine entscheidende Rolle, wenn es darum geht, Produktivität, Qualität und Erfolg zu steigern. [GitLab](https://about.gitlab.com/de-de/platform/) ist eine umfassende DevSecOps-Plattform und bietet leistungsstarke Tools, um diese wichtigen Metriken über die Insights-Dashboards zu verfolgen und zu visualisieren. In diesem Artikel erfährst du, wie du die Insights-Dashboards in deiner Umgebung verwenden kannst.\n\n## Inhaltsverzeichnis\n\n- [Einführungen in GitLab-Metriken und Analysen](#einführungen-in-gitlab-metriken-und-analysen)\n- [Nutze Labels für bestimmte Metriken](#nutze-labels-für-bestimmte-metriken)\n- [So konfigurierst du GitLab Insights](#so-konfigurierst-du-gitlab-insights)\n- [Einblicke in Merge Requests anpassen](#einblicke-in-merge-requests-anpassen)\n- [Merge-Request-Einblicke für jede Squad und jeden Anforderungstyp](#merge-request-einblicke-für-jede-squad-und-jeden-anforderungstyp)\n  - [Richte Squad-basierte Metriken ein](#richte-squad-basierte-metriken-ein)\n- [Lege jetzt los](#lege-jetzt-los)\n- [Mehr erfahren](#mehr-erfahren)\n\n## Einführungen in GitLab-Metriken und Analysen\n\nGitLab stellt verschiedenste Metriken und Analysetools für unterschiedliche Aspekte des DevSecOps-Lebenszyklus bereit:\n\n1. [Produktivitätsanalyse (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html): Damit kannst du die Geschwindigkeit deines Teams, Bearbeitungszeiten und Abarbeitungsdauer nachverfolgen.\n2. [Code-Review-Analysen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html): Damit kannst du die Codequalität, die Testabdeckung und die Effizienz der Überprüfung messen.\n3. [CI/CD-Analyse (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html): Damit kannst du die Pipeline-Performance und die Bereitstellungshäufigkeit überwachen.\n4. [Wertstromanalyse (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/group/value_stream_analytics/): Damit kannst du den Arbeitsfluss von der Idee bis zur Produktion visualisieren.\n5. [Einblicke (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/insights/): Entdecke und visualisiere Daten über deine Projekte und Gruppen.\n\nDiese Metriken bieten wertvolle Einblicke in deinen Entwicklungsprozess und helfen Teams dabei, Engpässe zu identifizieren, Workflows zu optimieren und datengestützte Entscheidungen zu treffen.\n\n## Nutze Labels für bestimmte Metriken\n\nEine der leistungsstärksten und doch unterschätztesten Funktionen von GitLab sind Labels, mit denen du Metriken mit absoluter Präzision filtern kannst. Wenn du Labels strategisch Tickets, Merge Requests und Epics zuweist, kannst du individuelle Ansichten erstellen, die zielgenaue Einblicke in die Leistung und den Fortschritt deines Projekts bieten.\n\nLabels fungieren in GitLab als vielseitige Kennungen, mit denen du deine Workitems flexibel kategorisieren und organisieren kannst. Egal, ob du die Entwicklung von Funktionen, Bug Fixes oder teamspezifische Aufgaben nachverfolgst: Mit Labels kannst du deine Projektdaten aufschlüsseln und erkenntnisreiche Muster und Entwicklungen aufdecken. \n\nDas Konzept ist ähnlich wie Tags in Cloud-Bereitstellungen, wo die Ressourcen gekennzeichnet werden, um sie einfacher verwalten, die Kosten zuordnen und betriebliche Einblicke gewinnen zu können. Indem du deine Workitems sorgfältig mit Labels kennzeichnest, baust du ein cleveres Label-System auf, mit dem du ganz einfach individuelle Dashboards und Berichte erstellen kannst. Durch diesen Ansatz kannst du dich auf die Metriken konzentrieren, die für dein Team oder deine Stakeholder am wichtigsten sind. So erhältst du eine klare Fokusansicht des Zustands und der Dynamik deines Projekts.\n\n## So konfigurierst du GitLab Insights\n\nMit GitLab Insights kannst du Daten über deine Projekte und Gruppen untersuchen und visualisieren. Sie bieten wichtige Analysen zu verschiedensten Aspekten, wie etwa den in einem bestimmten Zeitraum erstellten und geschlossenen Tickets, die durchschnittliche Zeit, die es bis zur Zusammenführung eines Merge Request dauert, sowie die Qualität der Priorisierung. Einblicke können sowohl für Projekte als auch für Gruppen konfiguriert werden.\n\n**So konfigurierst du Insights:**\n\n1. Für Projekteinblicke:\n   * Erstelle eine Datei mit dem Namen `.gitlab/insights.yml` im Stammverzeichnis deines Projekts.\n2. Für Gruppeneinblicke:\n   * Erstelle die Datei `.gitlab/insights.yml` in einem Projekt, das zu deiner Gruppe gehört.\n * Gehe zu **Einstellungen > Allgemein** deiner Gruppe.\n * Klappe den Abschnitt **Analyse** aus und suche den Abschnitt **Insights**.\n * Wähle das Projekt aus, das die Konfigurationsdatei enthält, und speichere die Änderungen.\n\nDie Datei `.gitlab/insights.yml` ist eine YAML-Datei, in der du die Struktur und Reihenfolge der Diagramme in einem Bericht sowie den Stil der anzuzeigenden Diagramme definieren kannst. Jede Diagrammdefinition enthält Parameter wie Titel, Beschreibung, Typ und Abfrage, um die Datenquelle und die Filterbedingungen anzugeben.\n\nUm Einblicke anzuzeigen, gehe in deinem Projekt oder deiner Gruppe zu **Analysieren > Insights**.\n\n![Standard-Dashboard für Insights anzeigen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378202/Blog/oqek65jmi5kclpbaqsca.png)\n\n## Einblicke in Merge Requests anpassen\n\nWährend die Standardansicht wertvolle Rohinformationen liefert, können wir das Insights-Dashboard anpassen, um zusätzliche Informationsebenen anzuzeigen, z. B. welches Team für welchen Merge Request verantwortlich war und welche Art von Problem gelöst wurde.\n\n## Merge-Request-Einblicke für jede Squad und jeden Anforderungstyp\n\nEs kann herausfordernd sein, die Produktivität einer Squad in GitLab zu messen, vor allem wenn die Gruppen- und Untergruppenstruktur in GitLab nicht perfekt mit der Organisation deines Squad übereinstimmt. So kannst du diese Herausforderungen meistern und die Produktivität deiner Squads effektiv verfolgen:\n\n### Richte Squad-basierte Metriken ein\n\n1. **Erstelle Labels:** Erstelle eindeutige Labels mit begrenztem Geltungsbereich für jede Squad (z. B. `squad::alpha`, `squad::beta`) und jeden Anforderungstyp (z. B. `type::bug`, `type::feature`, `type::maintenance`).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZUOzORIUJeU?si=T8eHeGizS3blYFHB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n2. **Weise Labels zu:** Weise diese Squad-Labels konsequent allen Tickets und Merge Requests zu, die von der jeweiligen Squad bearbeitet werden, egal in welchem Projekt oder welcher Gruppe sie sind.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/fJ9entEBZG8?si=MlM6mKirEdkmwDDJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Tipps:**\n   * Verwende die GitLab-API, um Labels gesammelt an bestehende geöffnete, zusammengeführte und geschlossene MRs zuzuweisen.\n   * Du kannst Labels im Rahmen deiner GitLab-CI-Pipeline hinzufügen/entfernen/aktualisieren.\n * Nutze den GitLab Triage Bot, um den Label-Prozess zu automatisieren.\n\n3. Richte ein Dashboard ein: Erstelle die Datei `.gitlab/insights.yml` in deinem Projekt-Repository mit benutzerdefinierten Diagrammen für teamspezifische und typspezifische Einblicke in Merge Requests.\n\n```\n\n## Default Merge Requests insights.yml \nmergeRequests:\n  title: Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week \n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month\n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n\n## Per-teams Merge Requests insights.yml\nmergeRequestsTeams:\n  title: Merge requests dashboard per teams\n  charts:\n    - title: Merge requests merged per week \n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n    - title: Merge requests merged per month\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n\n## Per-teams and Type Merge Requests insights.yml\nmergeRequestsTeamsAndType:\n  title: Per Teams and Type - Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n    - title: Merge requests merged per week - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n\n```\n\nIndem du diese Anpassungen implementierst, kannst du sinnvolle Dashboards erstellen, in denen du einen klaren Überblick über die Merge-Request-Aktivitäten pro Team und Anforderungstyp erhältst. So kannst du Trends im Zeitverlauf visualisieren, die Leistung zwischen Squads vergleichen und die Verteilung der verschiedenen Arbeiten für jede Squad analysieren.\n\n![Dashboards mit Ansicht der MR-Aktivität pro Team und Anforderungstyp](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097217972.png)\n\n![Dashboard zum Vergleich der Leistung zwischen Squads](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097217972.png)\n\n## Lege jetzt los\n\nGitLab Insights ist nur die Spitze des Eisbergs, wenn es um Indikatoren und Analysen geht. Um die gesamte Palette der leistungsstarken Analysefunktionen von GitLab wie Wertstromanalyse, CI/CD-Analyse und Code-Review-Metriken zu entdecken, sieh dir unsere Produkttour zum Wertstrommanagement an:\n\n[![Produkttour zum Wertstrommanagement](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097217974.png)]( https://gitlab.navattic.com/vsm)\n\n> Bist du bereit, jetzt selbst Metriken zu nutzen? Melde dich jetzt für eine [kostenlose Testversion von GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F) an und schöpfe das volle Potenzial von datengestützten DevSecOps aus.\n\n## Mehr erfahren\n- [Tool zur Erstellung geplanter Berichte vereinfacht das Wertstrommanagement (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n- [Erste Schritte mit dem neuen Wertstrom-Dashboard von GitLab (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/)\n- [KI-Impact-Analyse-Dashboard misst den ROI von KI](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n","product",[109,682,680,683,684,9],"DevSecOps platform","features","tutorial","2025-06-06",{"slug":687,"featured":91,"template":688},"data-driven-devsecops-exploring-gitlab-insights-dashboards","BlogPost","content:de-de:blog:data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","Data Driven Devsecops Exploring Gitlab Insights Dashboards","de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"_path":694,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":695,"content":701,"config":709,"_id":711,"_type":14,"title":712,"_source":16,"_file":713,"_stem":714,"_extension":19},"/de-de/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":696,"description":697,"ogTitle":696,"ogDescription":697,"noIndex":6,"ogImage":698,"ogUrl":699,"ogSiteName":672,"ogType":673,"canonicalUrls":699,"schema":700},"Strukturierung der GitLab-Paket-Registry für Unternehmen","Wie du projektbasierte Modelle zur Veröffentlichung von Softwarepaketen von GitLab mit Nutzung auf Root-Gruppen-Ebene kombinierst, um eine Strategie für Paketverwaltung aufzubauen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662332/Blog/Hero%20Images/blog-image-template-1800x945__23_.png","https://about.gitlab.com/blog/structuring-the-gitlab-package-registry-for-enterprise-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Strukturierung der GitLab-Paket-Registry für Unternehmen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":696,"description":697,"authors":702,"heroImage":698,"date":704,"body":705,"category":680,"tags":706,"updatedDate":708},[703],"Tim Rizzi","2025-02-19","Je größer Unternehmen werden, desto komplexer wird es, interne Pakete zu verwalten. Während herkömmliche Paketmanager wie JFrog Artifactory und Sonatype Nexus ein zentralisiertes Repository nutzen, geht [GitLab](https://about.gitlab.com/de-de/) einen anderen Weg, der der Arbeitsweise moderner Entwicklungsteams besser entspricht. In diesem Beitrag erfährst du, wie du deine GitLab-Paket-Registry auf Unternehmensniveau effektiv strukturierst. Dabie ziehen wir Maven- und npm-Pakete als Beispiele heran.\n\n## Das Modell der GitLab-Paket-Registry verstehen\n\nWenn du bisher einen herkömmlichen Paketmanager verwendet hast, mutet der Ansatz von GitLab vielleicht erst einmal ungewohnt an. Anstatt eines einzigen, zentralisierten Repositorys integriert GitLab die Paketverwaltung direkt in deine bestehende Projekt- und Gruppenstruktur. Das bedeutet Folgendes:\n\n- Teams veröffentlichen Pakete in bestimmten Projekten, in denen sich der Code befindet\n- Teams verwenden Pakete von Root-Gruppen-Registries, die alle untergeordneten Pakete aggregieren\n- Die Zugriffskontrolle wird durch deine bestehenden GitLab-Berechtigungen festgelegt\n\nDieses Modell bietet mehrere Vorteile:\n\n- Klare Inhaberschaft von Paketen neben deren Quellcode\n- Granulare Zugriffskontrolle ohne zusätzliche Konfiguration\n- Vereinfachte CI/CD-Integration\n- Natürliche Anpassung an die Teamstrukturen\n- Eine einzige URL für alle Pakete des Unternehmens durch Root-Gruppen-Nutzung\n\n### Die Vorteile der Paket-Registry auf Root-Gruppen-Ebene\n\nGitLab unterstützt zwar die Paketnutzung auf verschiedenen Gruppenebenen, aber die Root-Gruppen-Ebene hat sich bei unseren Benutzer(inne)n als bewährte Vorgehensweise etabliert. Das liegt an folgenden Gründen:\n\n- **Einziger Zugriffspunkt:** Eine URL bietet Zugriff auf alle privaten Pakete im gesamten Unternehmen\n- **Konsistente Benennung von Paketen:** Mit Endpunkten auf Gruppenebene können Teams ihre bevorzugten Benennungskonventionen ohne Konflikte weiter nutzen\n- **Vereinfachte Konfiguration:** Alle Entwickler(innen) können dieselbe Konfiguration nutzen, um auf Pakete zuzugreifen\n- **Sicheres Zugriffsmanagement:** Kombiniert mit Bereitstellungstokens für einfache Rotation und Zugriffskontrolle\n- **Hierarchische Organisation**: Bildet deine Unternehmensstrukturen natürlich ab und bietet gleichzeitig vereinheitlichten Zugriff\n\n## Praxisbeispiel: Unternehmensstruktur\n\nSehen wir uns am Beispiel eines größeren Unternehmens an, wie das Ganze in der Praxis aussehen kann:\n\n```\ncompany/ (root group)\n├── retail-division/\n│   ├── shared-libraries/     # Division-specific shared code\n│   └── teams/\n│       ├── checkout/        # Team publishes packages here\n│       └── inventory/       # Team publishes packages here\n├── banking-division/\n│   ├── shared-libraries/    # Division-specific shared code\n│   └── teams/\n│       ├── payments/       # Team publishes packages here\n│       └── fraud/         # Team publishes packages here\n└── shared-platform/        # Enterprise-wide shared code\n    ├── java-commons/      # Shared Java libraries\n    └── ui-components/     # Shared UI components\n```\n\n### Veröffentlichungskonfiguration\n\nTeams veröffentlichen Pakete in ihre jeweiligen Projekt-Registries und behalten dabei eine klare Inhaberschaft bei:\n\n1. Beispiel: Maven\n\n```xml\n\u003C!-- checkout/pom.xml -->\n\u003CdistributionManagement>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/distributionManagement>\n```\n\n2. Beispiel: npm\n\n```json\n// ui-components/package.json\n{\n  \"name\": \"@company/ui-components\",\n  \"publishConfig\": {\n    \"registry\": \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/\"\n  }\n}\n```\n\n### Nutzungskonfiguration\n\nHier zeigt sich wirklich, wie vorteilhaft die Nutzung in der Root-Gruppe ist. Alle Teams konfigurieren einen einzigen Endpunkt für den Paketzugriff:\n\n1. Beispiel: Maven\n\n```xml\n\u003C!-- Any project's pom.xml -->\n\u003Crepositories>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>https://gitlab.example.com/api/v4/groups/company/-/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/repositories>\n```\n\n2. Beispiel: npm\n\n```\n# Any project's .npmrc\n@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/\n```\n\nDiese Konfiguration bietet automatisch Zugriff auf alle Pakete in deine Unternehmen und gleichzeitig alle Vorteile der projektbasierten Veröffentlichung.\n\n## Authentifizierung und Zugriffskontrolle\n\nDas Modell von GitLab vereinfacht die Authentifizierung durch Bereitstellungstoken und CI/CD-Integration.\n\n### Für CI/CD-Pipelines\n\nGitLab übernimmt automatisch die Authentifizierung mit `CI_JOB_TOKEN`:\n\n```yaml\n# .gitlab-ci.yml\npublish:\n  script:\n    - mvn deploy  # or npm publish\n  # CI_JOB_TOKEN provides automatic authentication\n```\n\n### Für die Entwicklung\n\nNutze Gruppen-Bereitstellungstoken für die Paketnutzung:\n\n- Erstelle auf Root-Gruppen-Ebene Bereitstellungstoken mit Lesezugriff\n- Rotiere Tokens aus Sicherheitsgründen in regelmäßigen Abständen\n- Teile eine einzige Konfiguration für alle Entwickler(innen)\n\n## Vorteile eines Root-Gruppen-Paket-Registrys:\n\n1. Vereinfachte Konfiguration\n   - Eine URL für den gesamten Paketzugriff\n   - Konsistente Einrichtung für alle Teams\n   - Einfache Rotation von Tokens\n2. Klare Inhaberschaft\n   - Pakete bleiben bei ihrem Quellcode\n   - Teams haben Kontrolle über die Veröffentlichung\n   - Der Versionsverlauf korreliert mit der Projektaktivität\n3. Natürliche Organisation\n   - Entspricht deiner Unternehmensstruktur\n   - Fördert die Autonomie der Teams\n   - Ermöglicht teamübergreifende Zusammenarbeit\n\n## Erste Schritte\n\n1. Richte deine Root-Gruppe ein\n   - Erstelle eine klare Gruppenstruktur\n   - Konfiguriere die entsprechenden Zugriffskontrollen\n   - Erstelle Gruppen-Bereitstellungstoken\n2. Konfiguriere Teamprojekte\n   - Richte die Veröffentlichung auf Projektebene ein\n   - Implementiere CI/CD-Pipelines\n   - Dokumentiere die Benennungskonventionen für Pakete\n3. Standardisiere die Nutzung\n   - Konfiguriere den Registry-Zugriff für die Root-Gruppe\n   - Teile Bereitstellungstoken auf sichere Art und Weise\n   - Dokumentiere den Entdeckungsprozess der Pakete\n\n## Zusammenfassung\n\nDas Paket-Registry-Modell von GitLab ist – insbesondere dann, wenn es auf Root-Gruppen-Ebene genutzt wird – eine leistungsstarke Lösung für die Paketverwaltung im Unternehmen. Durch die Kombination aus projektbasierter Veröffentlichung mit Nutzung auf Root-Gruppen-Ebene erhalten Unternehmen das Beste aus beiden Welten: klare Inhaberschaft und vereinfachten Zugriff. Dieser Ansatz lässt sich natürlich mit deinem Unternehmen skalieren, ohne dass Sicherheit und Benutzerfreundlichkeit vernachlässigt werden.\n\nDu kannst dieses Modell zunächst in einzelnen Teams oder Abteilungen einführen und dann ausweiten, wenn dich die Vorteile dieses integrierten Ansatzes überzeugt haben. Auch wenn wir uns in diesem Beitrag auf Maven und npm konzentriert haben, gelten dieselben Prinzipien für alle Pakettypen, die von GitLab unterstützt werden.\n\n> Lege jetzt mit Paket-Registries los! Melde dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) an.\n",[707,684,9],"DevSecOps","2025-05-13",{"slug":710,"featured":91,"template":688},"structuring-the-gitlab-package-registry-for-enterprise-scale","content:de-de:blog:structuring-the-gitlab-package-registry-for-enterprise-scale.yml","Structuring The Gitlab Package Registry For Enterprise Scale","de-de/blog/structuring-the-gitlab-package-registry-for-enterprise-scale.yml","de-de/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"_path":716,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":717,"content":723,"config":734,"_id":736,"_type":14,"title":737,"_source":16,"_file":738,"_stem":739,"_extension":19},"/de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"title":718,"description":719,"ogTitle":718,"ogDescription":719,"noIndex":6,"ogImage":720,"ogUrl":721,"ogSiteName":672,"ogType":673,"canonicalUrls":721,"schema":722},"Ultimativer Leitfaden für die Migration von AWS CodeCommit zu GitLab","In diesem umfassenden Tutorial erfährst du, wie du von AWS Services zu GitLab migrieren und die DevSecOps-Plattform nahtlos integrieren kannst. ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097810/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2828%29_4mi0l4wzUa5VI4wtf8gInx_1750097810027.png","https://about.gitlab.com/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ultimativer Leitfaden für die Migration von AWS CodeCommit zu GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"},{\"@type\":\"Person\",\"name\":\"Samer Akkoub\"},{\"@type\":\"Person\",\"name\":\"Bart Zhang\"}],\n        \"datePublished\": \"2024-08-26\",\n      }\n                  ",{"title":718,"description":719,"authors":724,"heroImage":720,"date":729,"body":730,"category":680,"tags":731,"updatedDate":733},[725,726,727,728],"Tsukasa Komatsubara","Darwin Sanoy","Samer Akkoub","Bart Zhang","2024-08-26","Am 25. Juli 2024 hat AWS eine wichtige Ankündigung in Bezug auf den CodeCommit-Service des Unternehmens veröffentlicht. Wie in ihrem [offiziellen Blogbeitrag](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/) beschrieben, hat AWS beschlossen, Neukund(inn)en den Zugriff auf CodeCommit zu entziehen. Bestehende Kund(inn)en können den Service zwar weiterhin nutzen, aber AWS führt keine neuen Funktionen mehr ein und konzentriert sich nur noch auf die Verbesserung von Sicherheit, Verfügbarkeit und Leistung.\n\nDiese Ankündigung hat Entwicklerteams dazu veranlasst, eine Migration ihrer Repositorys zu alternativen Git-Anbietern in Betracht zu ziehen. Angesichts dieser Änderungen haben wir diese umfassende Anleitung erstellt, um Teams bei der Migration zu GitLab und der Integration mit anderen AWS-Services zu unterstützen.\n\n**Hinweis:** Weitere Einzelheiten zu den offiziellen Migrationsempfehlungen von AWS findest du im [entsprechenden Blogbeitrag](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/).\n\n## Über diesen Leitfaden\n\nDieser Leitfaden enthält umfassende Informationen für Entwicklungsteams, die GitLab nutzen und eine Integration mit AWS-Services in Betracht ziehen oder eine Migration von AWS-gehosteten Git-Repositories zu GitLab.com planen. Der Leitfaden ist in drei Hauptabschnitte unterteilt:\n\n- [Parallele Migration zu GitLab](#section-1-parallel-migration-to-gitlab): Beschreibt die schrittweise Migration vorhandener, in AWS gehosteter Repositories zu GitLab.com bei gleichzeitiger Minimierung von Risiken.\n\n- [Integration mit AWS CodeBuild](#section-2-integrating-gitlab-with-aws-codebuild): Beschreibt die Schritte zur Integration von GitLab-Repositories mit AWS CodeBuild und zur Einrichtung einer leistungsstarken Umgebung mit kontinuierlicher Integration.\n\n- [Integration mit AWS CodePipeline](#section-3-integrating-gitlab-with-aws-codepipeline): Enthält Details zur Verbindung von GitLab-Repositories mit AWS CodePipeline, um effiziente Pipelines für kontinuierliche Lieferung zu erstellen.\n\n- [Downstream-Integrationen für CodePipeline- und CodeStar-Verbindunge](#section-4-migrating-to-gitlab): Beschreibt die Nutzung von GitLab-AWS-Verbindungen für umfassende Servicezugriffe mit zahlreichen Integrationsmöglichkeiten im gesamten AWS-Ökosystem.\n\nIn dieser Anleitung erfährst du, wie du die leistungsstarken Funktionen von GitLab und AWS kombinieren kannst, um einen effizienten und flexiblen Entwicklungs-Workflow zu erstellen.\n\n## Abschnitt 1: Parallele Migration zu GitLab \n\nWenn du vorhast, Git-Repositories, die auf AWS gehostet werden, auf GitLab.com zu migrieren, findest du in diesem Abschnitt eine Anleitung für eine schrittweise Migration, die die Risiken minimiert. Mit den Mirroring-Funktionen von GitLab kannst du bestehende Entwicklungsabläufe beibehalten und gleichzeitig die neue Umgebung testen.\n\n### Warum ist die parallele Migration wichtig?\n\nUmfangreiche Systemmigrationen sind immer mit Risiken verbunden, insbesondere mit potenziellen Auswirkungen auf die laufende Entwicklungsarbeit, bestehende Integrationen und automatisierte Prozesse. Ein paralleler Migrationsansatz bietet die folgenden Vorteile:\n\n1. Risikominimierung: Teste die neue Umgebung, während bestehende Systeme betriebsbereit bleiben.\n2. Nahtloser Übergang: Entwicklungsteams können sich allmählich an das neue System gewöhnen.\n3. Integrationstests: Teste alle Integrationen und Automatisierungen in der neuen Umgebung gründlich.\n4. Zukunftsfähigkeit: Ermögliche es den Teams, schrittweise auf GitLab CI/CD zu migrieren, parallel zur bestehenden CI.\n\nEine parallele Migration ist nicht erforderlich, wenn du bereits weißt, dass du direkt zu GitLab wechseln möchtest.\n\n### Schritte für die Migration zu GitLab.com\n\n#### Schritt 1: Einrichtung auf GitLab.com\n\n- Überprüfe, ob dein Unternehmen bereits eine Gruppe auf GitLab.com besitzt und ob Single Sign-On (SSO) eingerichtet ist. Wenn ja, solltest du nach Möglichkeit beides verwenden.\n\n- Wenn dein Unternehmen noch nicht auf GitLab.com vertreten ist, besuche [GitLab.com](www.gitlab.com) und erstelle ein neues Konto oder melde dich bei einem bestehenden Konto an.\n- Erstelle einen neuen Unternehmens-Namensraum (eine Gruppe auf der Stammebene von gitlab.com).\n- Wähle einen Namen, der dein gesamtes Unternehmen widerspiegelt (und noch nicht vergeben ist).\n\n#### Schritt 2: Repository importieren\nBei paralleler Migration: Verwende die Pull-Mirroring-Funktion von GitLab, um Änderungen von in AWS gehosteten Repositories automatisch mit GitLab.com zu synchronisieren.\n\n1. Gehe zur Zielgruppe auf GitLab.com.\n2. Klicke oben rechts auf „Neues Projekt“.\n3. Klicke auf der Seite „Neues Projekt erstellen“ auf „Projekt importieren“.\n4. Klicke auf der Seite „Projekt importieren“ auf „Repository nach URL“.\n5. Gib die URL deines in AWS gehosteten Repositorys in das Feld „Git-Repository-URL“ ein.\n6. Aktiviere unter dem Feld „Git-Repository-URL“ die Option „Repository spiegeln“.\n7. Authentifizierung einrichten: Wähle in der AWS-CodeCommit-Konsole die Klon-URL für das Repository aus, das du migrieren möchtest. Wenn du CodeCommit-Repositories in GitLab importieren möchtest, kannst du die HTTPS-CodeCommit-URL verwenden, um das Repository über die GitLab-Repository-Spiegelung zu klonen. Außerdem musst du deine Git-Zugangsdaten von AWS für deinen IAM-Benutzer (Identity and Access Management) in GitLab angeben. Du kannst Git-Zugangsdaten für AWS CodeCommit erstellen, indem du dieser [AWS-Anleitung](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html) folgst.\n\n![Klon-URL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/clone-url-screenshot__1__aHR0cHM6_1750097822121.png)\n\nMit dieser Einrichtung werden Änderungen aus dem von AWS gehosteten Repository automatisch alle fünf Minuten auf GitLab.com übertragen.\n\nWeitere Informationen findest du in unserer [Dokumentation zur Repository-Spiegelung](https://docs.gitlab.com/ee/user/project/repository/mirror/).\n\n#### Schritt 3: Integrationen testen und validieren\n\n1. CI/CD-Pipelines: Richte die Datei `.gitlab-ci.yml` in GitLab CI ein, um vorhandene Pipelines zu replizieren. Weitere Informationen zur [Planung einer Migration von anderen CI-Tools nach GitLab CI/CD](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html).\n2. Ticketverfolgung: Importiere Projekt-Tickets und teste Workflows.\n3. Code Review: Richte den Merge-Request-Prozess ein und teste die Review-Workflows.\n#### Schritt 4: Schrittweise Migration\n\n1. Beginne mit kleinen oder unkritischen Projekten, um dich mit der Arbeit auf GitLab.com vertraut zu machen.\n2. Biete Schulungen für Teammitglieder an und plane Zeit für die Anpassung an neue Workflows ein.\n3. Migriere nach und nach weitere Projekte und stelle dabei sicher, dass die Integrationen und Workflows problemlos funktionieren.\n\nWeitere Informationen findest du unter [Automatisieren von Migrationen von CodeCommit nach GitLab](https://gitlab.com/guided-explorations/aws/migrating-from-codecommit-to-gitlab/-/blob/main/migrating_codecommit_to_gitlab.md).\n\n#### Schritt 5: Migration abschließen\nWenn alle Tests und Validierungen abgeschlossen sind und das Team mit der neuen Umgebung vertraut ist, kannst du die vollständige Migration planen. Gehe für jedes Projekt wie folgt vor:\n\n1. Lege ein Migrationsdatum fest und benachrichtige alle Stakeholder.\n2. Führe die abschließende Datensynchronisierung durch.\n3. Entferne die Spiegelungseinstellungen aus dem GitLab-Projekt.\n4. Lege in AWS gehostete Repositories als schreibgeschützt fest und übertrage alle Entwicklungsarbeiten nach GitLab.com.\n\n#### Schritt 6: Bewerten der Akzeptanz der neuen Funktionen\n\nDie Zusammenarbeit in GitLab und die Automatisierung von Workflows für Entwickler(innen) sind weitaus umfangreicher als in CodeCommit. Nimm dir etwas Zeit, um diese Fähigkeiten kennenzulernen. Der Merge-Request-Prozess ist im Vergleich zu CodeCommit besonders vielseitig.\n\nWenn die Repositories auf GitLab stabil sind, kannst du GitLab CI/CD mühelos parallel zu einer vorhandenen Lösung ausprobieren. Die Teams können sich Zeit nehmen, um ihre GitLab-CI/CD-Automatisierung zu optimieren, ohne dass die Produktions-Workflows davon betroffen sind.\n\nAuch die Artefaktverwaltung von GitLab ist mit der Release-Funktion und vielen Paketregistrierungen sehr leistungsfähig.\n\n### Abschnitt 1: Zusammenfassung\nMit einem parallelen Migrationsansatz zu GitLab kannst du einen reibungslosen Übergang erreichen und gleichzeitig die Risiken minimieren. Mit diesem Prozess können sich Teams schrittweise an die neue Umgebung anpassen und sicherstellen, dass alle Integrationen und Automatisierungen ordnungsgemäß funktionieren. Bei der Übernahmemigration wird nur ein einziges Kontrollkästchen ausgelassen, wenn bekannt ist, dass eine parallele Migration nicht notwendig ist.\n\n## Abschnitt 2: Integration von GitLab mit AWS CodeBuild\n\nWenn du Code aus GitLab-Repositories mit AWS CodeBuild erstellen und testen möchtest, hilft dir diese umfassende Anleitung beim Einrichten einer effizienten CI-Pipeline.\n\n### Voraussetzungen\n\n- GitLab.com-Konto\n- AWS-Konto\n- AWS CLI (konfiguriert)\n\n### Schritt 1: GitLab-Verbindung in AWS CodeStar-Verbindungen erstellen\n\n1. Melde dich in der AWS-Managementkonsole an und navigiere zum CodeBuild-Service.\n2. Wähle in der linken Navigationsleiste „Einstellungen“ > „Verbindungen“ aus.\n3. Klicke auf die Schaltfläche „Verbindung erstellen“.\n4. Wähle „GitLab“ als Anbieter aus.\n5. Gib einen Verbindungsnamen ein und klicke auf „Mit GitLab verbinden“.\n6. Daraufhin wirst du zur GitLab-Authentifizierungsseite weitergeleitet.\n7. Erteile die erforderlichen Berechtigungen.\n8. Nach erfolgreichem Abschluss ändert sich der Verbindungsstatus in „Verfügbar“.\n\n![CodeStar-Connect-Einrichtung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### Schritt 2: AWS-CodeBuild-Projekt erstellen\n\n1. Klicke im CodeBuild-Dashboard auf „Build-Projekt erstellen“.\n2. Gib einen Projektnamen und eine Beschreibung ein.\n3. Wähle in den Quelleneinstellungen „GitLab“ als Anbieter aus.\n4. Wähle die soeben erstellte Verbindung aus und gib das GitLab-Repository und den Branch an.\n\n![CodeBuild-Projekt hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_3_add_codebuild_aHR0cHM6_1750097822123.png)\n\n**Hinweis: Konfiguriere ab Schritt 3 die Einstellungen für deine spezifische Umgebung und deine Anforderungen.**\n\n### Zusammenfassung von Abschnitt 2\nIn diesem Abschnitt wurde ausführlich beschrieben, wie du GitLab-Repositories in AWS CodeBuild integrieren kannst. Diese Einrichtung ermöglicht eine kontinuierliche Integrationspipeline, bei der Codeänderungen in GitLab automatisch mit AWS CodeBuild erstellt und getestet werden.\n\n## Abschnitt 3: GitLab mit AWS CodePipeline integrieren\n\nWenn du die kontinuierliche Lieferung von GitLab-Repositories mit AWS CodePipeline implementieren möchtest, wird dir diese detaillierte Anleitung helfen. Die Integration ist jetzt noch einfacher geworden, da GitLab als AWS-CodeStar-Connections-Anbieter verfügbar ist.\n\n### Voraussetzungen\n\n- GitLab.com-Konto\n- AWS-Konto\n- AWS CLI (konfiguriert)\n\n### Schritt 1: GitLab-Verbindung in AWS CodeStar-Verbindungen erstellen\n\n1. Melde dich in der AWS-Managementkonsole an und navigiere zum CodePipeline-Service.\n2. Wähle in der linken Navigationsleiste „Einstellungen“ > „Verbindungen“ aus.\n3. Klicke auf die Schaltfläche „Verbindung erstellen“.\n4. Wähle „GitLab“ als Anbieter aus.\n5. Gib einen Verbindungsnamen ein und klicke auf „Mit GitLab verbinden“.\n6. Daraufhin wirst du zur GitLab-Authentifizierungsseite weitergeleitet.\n7. Erteile die erforderlichen Berechtigungen.\n8. Nach erfolgreichem Abschluss ändert sich der Verbindungsstatus in „Verfügbar“.\n\n![CodeStar Connections einrichten](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### Schritt 2: AWS CodePipeline erstellen\n\n1. Klicke im CodePipeline-Dashboard auf „Pipeline erstellen“.\n2. Gib einen Pipeline-Namen ein und klicke auf „Weiter“.\n3. Wähle „GitLab“ als Quellenanbieter aus.\n4. Wähle die soeben erstellte Verbindung aus und gib das GitLab-Repository und den Branch an.\n5. Wähle den Triggertyp aus: Du kannst die Ausführung der CodePipeline-Pipeline anhand von Pull- oder Push-Ereignissen für bestimmte Branches und Dateitypen in deinem Repository auslösen.\n\n![Quellenanbieter hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822125.png)\n\n![Quellkonfiguration hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_provider_aHR0cHM6_1750097822127.png)\n\n**Hinweis: Konfiguriere ab Schritt 3 die Einstellungen für deine spezifische Umgebung und deine Anforderungen.**\n\n### Zusammenfassung von Abschnitt 3\nIn diesem Abschnitt wurde beschrieben, wie du GitLab-Repositories in die AWS CodePipeline integrierst. Diese Einrichtung ermöglicht eine CD-Pipeline, bei der Codeänderungen in GitLab automatisch in deiner AWS-Umgebung bereitgestellt werden.\n\n## Abschnitt 4: Migration zu GitLab\n\nDie Integration von GitLab in AWS eröffnet dir leistungsstarke Möglichkeiten zur Optimierung deiner Entwicklungs- und Bereitstellungs-Workflows und hilft dir, deine Probleme bei der Quellcodeverwaltung zu lösen. Diese Integration kann auf verschiedene Arten erreicht werden, die jeweils einzigartige Vorteile bieten:\n\n- Wenn du AWS-CodeStar-Verbindungen verwendest, um GitLab mit AWS-Services zu verknüpfen, erhältst du einen kohärenten Workflow, da du externe Git-Repositories wie GitLab mit verschiedenen AWS-Services verbinden kannst. Diese Einrichtung unterstützt automatisierte Builds, Bereitstellungen und andere wichtige Aktionen direkt von deinem GitLab-Repository aus und macht deinen Entwicklungsprozess integrierter und effizienter.\n\n- Die Verbindung von GitLab mit AWS CodePipeline über AWS CodeStar Connections treibt die Automatisierung voran und ermöglicht es dir, eine vollständige CI/CD-Pipeline zu erstellen. Dieser Ansatz integriert GitLab mit AWS CodePipeline und ermöglicht es dir, den gesamten Prozess – von der Quellcodeverwaltung über Builds bis hin zu Tests und Bereitstellung – mit AWS-Services wie CodeBuild und CodeDeploy zu automatisieren. So wird ein robuster, skalierbarer und effizienter Bereitstellungsprozess gewährleistet.\n\n![Diagramm neuer Technologien und Lösungen für die gemeinsame Nutzung von GitLab und AWS](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_configured_aHR0cHM6_1750097822129.png)\n\n1\\. Verbindung von GitLab mit AWS-Services über AWS CodeStar Connections\n\nAWS CodeStar Connections ist ein Service, mit dem du externe Git-Repositories (wie GitHub oder Bitbucket) mit den AWS-Services verbinden kannst. Du kannst GitLab auch über CodeStar Connections mit AWS-Services verbinden. Wenn du GitLab verwendest, musst du möglicherweise eine benutzerdefinierte Verbindung als HTTP-Git-Server einrichten.\nDie folgenden AWS-Services können mit dieser Methode mit GitLab verbunden werden:\n\n- **AWS Service Catalog **\n\nDer AWS Service Catalog hilft Unternehmen bei der Standardisierung und Verwaltung von AWS-Ressourcen. Die Integration mit GitLab verbessert die Transparenz beim Ressourcenmanagement und vereinfacht die Nachverfolgung von Änderungen. Insbesondere kannst du Katalogaktualisierungen auf der Grundlage von GitLab-Commits automatisieren und so die Effizienz deines Vorgangs verbessern.\n\n- __AWS CodeBuild__\n\nAWS CodeBuild ist ein verwalteter Build-Service, der Quellcode kompiliert, Tests durchführt und bereitstellbare Softwarepakete erstellt. Die Integration von GitLab mit CodeBuild ermöglicht es, automatisierte Build-Prozesse zu starten, wenn Codeänderungen an GitLab übertragen werden. Dies garantiert einheitliche Builds und erleichtert die Zusammenarbeit und Versionskontrolle.\n\n- __AWS Glue Notebook Jobs__\n\nAWS Glue Notebook Jobs ist ein Service, mit dem du interaktiv Datenaufbereitungs- und ETL-Aufgaben (Extract, Transform, Load) entwickeln und ausführen kannst. Die Integration von GitLab mit Glue Notebook Jobs ermöglicht die Versionskontrolle für Notebooks und ETL-Skripte, fördert die Zusammenarbeit zwischen Teammitgliedern und verbessert das Qualitätsmanagement von Datenverarbeitungs-Pipelines.\n\n- __AWS Proton__\n\nAWS Proton ist ein Service, der die Entwicklung und Bereitstellung von Microservices und serverlosen Anwendungen automatisiert. Durch die Integration von GitLab mit AWS Proton kannst du Infrastructure as Code verwalten, Bereitstellungen automatisieren und ein konsistentes Umgebungsmanagement sicherstellen, was zu effizienteren Entwicklungsprozessen führt.\n\nWenn AWS CodeStar Connections in Zukunft mehr Dienste unterstützen, wird es immer einfacher, GitLab mit zusätzlichen AWS-Services zu verbinden. Du solltest regelmäßig prüfen, ob es neue Services gibt, die CodeStar Connections unterstützen.\n\n2. Verbindung von CodePipeline mit GitLab über AWS CodeStar Connections (einschließlich CodeDeploy)\n\nAWS CodePipeline ist ein kontinuierlicher Bereitstellungsdienst, der den Freigabeprozess für Software automatisiert. Um GitLab mit CodePipeline zu verbinden, musst du AWS CodeStar Connections verwenden. Mit dieser Einrichtung kannst du ein GitLab-Repository als Quelle festlegen und die gesamte CI/CD-Pipeline automatisieren.\nBeispiele für wichtige Aktionen, die CodePipeline unterstützt:\n- **Quellcode-Kontrolle:** AWS CodeCommit, GitHub, Bitbucket, GitLab\n- **Erstellen und Testen:** AWS CodeBuild, Jenkins\n- **Bereitstellen:** AWS CodeDeploy, Elastic Beanstalk, ECS, S3\n- **Genehmigen:** Manuelle Genehmigung\n- **Infrastruktur-Management:** AWS CloudFormation\n- **Serverlos:** AWS Lambda\n- **Tests:** AWS Device Farm\n- **Benutzerdefinierte Aktionen:** AWS Step Functions\n\nDurch die Integration von GitLab mit CodePipeline kannst du die Pipeline automatisch auslösen, wenn Codeänderungen nach GitLab gepusht werden, um einen konsistenten Prozess vom Build bis zur Bereitstellung sicherzustellen. In Kombination mit den Versionskontrollfunktionen von GitLab ist es außerdem einfacher, den Verlauf und die Zustände der Bereitstellung zu verfolgen, was zu einer flexibleren und zuverlässigeren Softwarebereitstellung führt.\n\n## Das hast du gelernt\nDiese Anleitung enthält umfassende Informationen über die Migration zu und die Integration von GitLab in AWS. In den vier Abschnitten haben wir Folgendes behandelt:\n- Parallele Migration zu GitLab: Wie du schrittweise von bestehenden, bei AWS gehosteten Repositories zu GitLab.com migrierst und dabei die Risiken minimierst.\n- Integration mit AWS CodeBuild: Schritte zum Einrichten einer leistungsstarken CI-Umgebung, die mit GitLab-Repositories integriert ist.\n- Integration mit AWS CodePipeline: Wie du effiziente Continuous-Delivery-Pipelines mit GitLab-Repositories aufbaust.\n- Nachgelagerte Integrationen für CodePipeline und CodeStar Connections: Die Nutzung von GitLab-AWS-Verbindungen für einen weitreichenden Service-Zugang, wodurch eine Reihe von Integrationsmöglichkeiten im gesamten AWS-Ökosystem entstehen.\n\nDa die Code-Hosting- und Integrationsstrategie jedes Unternehmens einzigartig ist, kannst du dieses Tutorial als Ausgangspunkt für deine eigene GitLab- und AWS- Integrations- und Implementierungsstrategie nutzen.\n\n## Zusätzliche Ressourcen\n\nWeitere Informationen und erweiterte Konfigurationen findest du in den folgenden Ressourcen:\n\n- [GitLab-Dokumentation](https://docs.gitlab.com/)\n- [AWS-CodeBuild-Benutzerhandbuch](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)\n- [AWS-CodePipeline-Benutzerhandbuch](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)\n- [GitLab-CI/CD-Dokumentation](https://docs.gitlab.com/ee/ci/)\n- [Integration mit AWS](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab_aws_integration.html)\n\nWenn du Fragen hast oder Unterstützung benötigst, wende dich bitte an den [GitLab-Support](https://about.gitlab.com/support/) oder den AWS-Support. Wir hoffen, dass dir diese umfassende Anleitung bei deiner AWS-GitLab-Integration hilft",[109,732,682,684,9,680,234],"AWS","2024-11-27",{"slug":735,"featured":91,"template":688},"ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","content:de-de:blog:ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","Ultimate Guide To Migrating From Aws Codecommit To Gitlab","de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"_path":741,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":742,"content":748,"config":759,"_id":761,"_type":14,"title":762,"_source":16,"_file":763,"_stem":764,"_extension":19},"/de-de/blog/what-is-an-ide",{"ogTitle":743,"schema":744,"ogImage":745,"ogDescription":746,"ogSiteName":672,"noIndex":6,"ogType":673,"ogUrl":747,"title":743,"canonicalUrls":747,"description":746},"IDE: Integrierte Entwicklungsumgebung einfach erklärt ","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist eine integrierte Entwicklungsumgebung (IDE)?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-11-13\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659768/Blog/Hero%20Images/AdobeStock_271529563.jpg","Wir zeigen dir, was eine integrierte Entwicklungsumgebung (IDE) ist. ✓ Definition ✓ Unterschiede ✓ Komponenten ✓ Auswahl ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com/blog/what-is-an-ide",{"heroImage":745,"body":749,"authors":750,"updatedDate":752,"date":753,"title":754,"tags":755,"description":757,"category":758},"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",[751],"GitLab Germany Team","2025-05-14","2024-11-13","Was ist eine integrierte Entwicklungsumgebung (IDE)?",[9,756],"embedded DevOps","Der ultimative Guide: Alles, was du über Integrierte Entwicklungsumgebungen wissen musst.","engineering",{"slug":760,"featured":6,"template":688},"what-is-an-ide","content:de-de:blog:what-is-an-ide.yml","What Is An Ide","de-de/blog/what-is-an-ide.yml","de-de/blog/what-is-an-ide",{"_path":766,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":767,"content":773,"config":779,"_id":781,"_type":14,"title":782,"_source":16,"_file":783,"_stem":784,"_extension":19},"/de-de/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"title":768,"description":769,"ogTitle":768,"ogDescription":769,"noIndex":6,"ogImage":770,"ogUrl":771,"ogSiteName":672,"ogType":673,"canonicalUrls":771,"schema":772},"Automatisierung der Migration von Container-Images von Amazon ECR zu GitLab","Wenn Plattformteams ihre CI/CD zu GitLab verschieben, sollte die Migration von Container-Images kein Engpass sein. Befolge diese Schritt-für-Schritt-Anleitung, um den Pipeline-Migrationsprozess zu automatisieren.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","https://about.gitlab.com/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisierung der Migration von Container-Images von Amazon ECR zu GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-13\",\n      }\n                  ",{"title":768,"description":769,"authors":774,"heroImage":770,"date":775,"body":776,"category":758,"tags":777,"updatedDate":778},[703],"2025-02-13","„Wir müssen Hunderte von Container-Images von Amazon Elastic Container Registry (ECR) zu GitLab migrieren. Könnt ihr uns helfen?“ Diese Frage taucht immer wieder in Gesprächen mit Platform Engineers auf. Sie modernisierten also ihre DevSecOps-Toolchain mit GitLab, kamen aber beim Verschieben ihrer Container-Images nicht weiter. Während ein einzelner Image-Transfer einfach ist, erscheint das schiere Volumen überwältigend.\n\nEin Platform Engineer brachte es auf den Punkt: „Ich weiß genau, was zu tun ist – pullen, neu kennzeichnen, pushen. Aber ich habe 200 Microservices mit jeweils mehreren Tags. Ich kann es nicht rechtfertigen, Wochen für diese Migration aufzuwenden, während wichtige Infrastrukturarbeiten anstehen.“\n\n## Die Herausforderung\n\nDieses Gespräch führte zu einer Idee. Was wäre, wenn wir den gesamten Prozess automatisieren könnten? Wenn Plattformteams ihre [CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/) zu GitLab verschieben, sollte die Migration von Container-Images kein Engpass sein. Der manuelle Prozess ist einfach, aber repetitiv: Jedes Image pullen, neu kennzeichnen und in die Container-Registry von GitLab pushen. Angesichts dutzender Repositories und mehrerer Tags pro Image, bedeutet dies Tage oder Wochen langwieriger Arbeit.\n\n## Die Lösung\n\nWir haben uns daran gemacht, eine GitLab-Pipeline zu erstellen, die all diese schwierigen Aufgaben automatisch erledigt. Das Ziel war einfach: Wir wollten Platform Engineers ein Tool zur Verfügung stellen, das sie in wenigen Minuten einrichten und über Nacht ausführen können, sodass am nächsten Morgen alle ihre Images erfolgreich migriert wurden.\n\n### Einrichten des Zugriffs\n\nDas Wichtigste zuerst: die Sicherheit. Teams sollen diese Migration mit minimalen AWS-Berechtigungen durchführen können. Hier ist die schreibgeschützte Identitäts- und Zugriffsmanagement (IAM)-Richtlinie dafür:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": [\n                \"ecr:GetAuthorizationToken\",\n                \"ecr:BatchCheckLayerAvailability\",\n                \"ecr:GetDownloadUrlForLayer\",\n                \"ecr:DescribeRepositories\",\n                \"ecr:ListImages\",\n                \"ecr:DescribeImages\",\n                \"ecr:BatchGetImage\"\n            ],\n            \"Resource\": \"*\"\n        }\n    ]\n}\n```\n\n### GitLab-Konfiguration\n\nNachdem die Sicherheit gewährleistet ist, ist der nächste Schritt die Einrichtung von GitLab. Wir haben uns auf das Wesentliche beschränkt. Du musst diese Variablen in deinen CI/CD-Einstellungen konfigurieren:\n\n```\nAWS_ACCOUNT_ID: Your AWS account number\nAWS_DEFAULT_REGION: Your ECR region\nAWS_ACCESS_KEY_ID: [Masked]\nAWS_SECRET_ACCESS_KEY: [Masked]\nBULK_MIGRATE: true\n```\n\n### Die Migrationspipeline\n\nJetzt wird es interessant. Wir haben die Pipeline mit Docker-in-Docker erstellt, um alle Image-Vorgänge zuverlässig zu verarbeiten:\n\n```yaml\nimage: docker:20.10\nservices:\n  - docker:20.10-dind\n\nbefore_script:\n  - apk add --no-cache aws-cli jq\n  - aws sts get-caller-identity\n  - aws ecr get-login-password | docker login --username AWS --password-stdin\n  - docker login -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD} ${CI_REGISTRY}\n```\n\nDie Pipeline hat drei Phasen, die jeweils auf der letzten aufbauen:\n\n1. Entdeckung\n\nZuerst findet sie alle deine Repositories:\n\n```bash\nREPOS=$(aws ecr describe-repositories --query 'repositories[*].repositoryName' --output text)\n```\n\n2. Tag-Auflistung\n\nDann ruft sie für jedes Repository alle Tags ab:\n\n```bash\nTAGS=$(aws ecr describe-images --repository-name $repo --query 'imageDetails[*].imageTags[]' --output text)\n```\n\n3. Übertragung\n\nSchließlich übernimmt sie die eigentliche Migration:\n\n```bash\ndocker pull ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag}\ndocker tag ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag} ${CI_REGISTRY_IMAGE}/${repo}:${tag}\ndocker push ${CI_REGISTRY_IMAGE}/${repo}:${tag}\n```\n\n## Das Ergebnis\n\nErinnerst du dich an den Platform Engineer, der nicht wochenlang mit der Migration verbringen wollte? Diese Lösung bietet Folgendes:\n\n- automatisierte Erkennung und Migration aller Repositories und Tags\n- konsistente Image-Benennung zwischen ECR und GitLab\n- Fehlerbehandlung für fehlgeschlagene Übertragungen\n- klare Protokollierung zur Verfolgung des Fortschritts\n\nAnstatt Skripte zu schreiben und die Migration zu überwachen, konnte sich der Plattform Engineer auf wertvollere Arbeit konzentrieren.\n\n## Verwendung\n\nDie ersten Schritte sind einfach:\n\n1. Kopiere die Datei `.gitlab-ci.yml` in dein Repository.\n2. Konfiguriere die AWS- und GitLab-Variablen.\n3. Setze `BULK_MIGRATE` auf „true“, um die Migration zu starten.\n\n## Best Practices\n\nBei der Unterstützung von Teams bei ihren Migrationen haben wir einige Dinge gelernt:\n\n- Der Prozess sollte außerhalb der Stoßzeiten durchgeführt werden, um die Auswirkungen auf dein Team zu minimieren.\n- Die Pipeline-Protokolle sind wichtig – darin findest du Informationen, wenn es ein Problem gibt.\n- Die Elastic Container Registry (ECR) sollte erst deaktiviert werden, wenn du überprüft hast, dass alle Images erfolgreich übertragen wurden.\n- Bei sehr großen Migrationen solltest du eine Ratenbegrenzung in Betracht ziehen, um eine Überlastung deines Netzwerks zu vermeiden.\n\nWir haben diese Pipeline in unserem öffentlichen GitLab-Repository quelloffen verfügbar gemacht, weil wir der Meinung sind, dass Plattform Engineers Zeit damit verbringen sollten, wertvolle Infrastrukturen aufzubauen, anstatt Container-Images zu kopieren. Passe sie an deine Bedürfnisse an und stelle Fragen zur Implementierung, wenn etwas unklar ist.\n\n> #### Informationen dazu und zu anderen Paketkomponenten findest du in unserer [CI/CD-Katalog-Dokumentation](https://gitlab.com/explore/catalog/components/package).",[109,732,684,682,680,9],"2025-04-10",{"slug":780,"featured":91,"template":688},"automating-container-image-migration-from-amazon-ecr-to-gitlab","content:de-de:blog:automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","Automating Container Image Migration From Amazon Ecr To Gitlab","de-de/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","de-de/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",1,[665,693,715,740],1758662385441]