[{"data":1,"prerenderedAt":1089},["ShallowReactive",2],{"/de-de/blog/categories/product/":3,"navigation-de-de":22,"banner-de-de":442,"footer-de-de":454,"product-category-page-de-de":664},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":17,"_source":18,"_file":19,"_stem":20,"_extension":21},"/de-de/blog/categories/product","categories",false,"",{"title":9,"description":10},"Produkt","Browse articles related to Produkt on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","product","content:de-de:blog:categories:product.yml","yaml","Product","content","de-de/blog/categories/product.yml","de-de/blog/categories/product","yml",{"_path":23,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":25,"_id":438,"_type":16,"title":439,"_source":18,"_file":440,"_stem":441,"_extension":21},"/shared/de-de/main-navigation","de-de",{"logo":26,"freeTrial":31,"sales":36,"login":41,"items":46,"search":379,"minimal":415,"duo":429},{"config":27},{"href":28,"dataGaName":29,"dataGaLocation":30},"/de-de/","gitlab logo","header",{"text":32,"config":33},"Kostenlose Testversion anfordern",{"href":34,"dataGaName":35,"dataGaLocation":30},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":37,"config":38},"Vertrieb kontaktieren",{"href":39,"dataGaName":40,"dataGaLocation":30},"/de-de/sales/","sales",{"text":42,"config":43},"Anmelden",{"href":44,"dataGaName":45,"dataGaLocation":30},"https://gitlab.com/users/sign_in/","sign in",[47,91,189,194,300,360],{"text":48,"config":49,"cards":51,"footer":74},"Plattform",{"dataNavLevelOne":50},"platform",[52,58,66],{"title":48,"description":53,"link":54},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":55,"config":56},"Erkunde unsere Plattform",{"href":57,"dataGaName":50,"dataGaLocation":30},"/de-de/platform/",{"title":59,"description":60,"link":61},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":62,"config":63},"Lerne GitLab Duo kennen",{"href":64,"dataGaName":65,"dataGaLocation":30},"/de-de/gitlab-duo/","gitlab duo ai",{"title":67,"description":68,"link":69},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":70,"config":71},"Mehr erfahren",{"href":72,"dataGaName":73,"dataGaLocation":30},"/de-de/why-gitlab/","why gitlab",{"title":75,"items":76},"Erste Schritte mit",[77,82,87],{"text":78,"config":79},"Platform Engineering",{"href":80,"dataGaName":81,"dataGaLocation":30},"/de-de/solutions/platform-engineering/","platform engineering",{"text":83,"config":84},"Entwicklererfahrung",{"href":85,"dataGaName":86,"dataGaLocation":30},"/de-de/developer-experience/","Developer experience",{"text":88,"config":89},"MLOps",{"href":90,"dataGaName":88,"dataGaLocation":30},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":9,"left":92,"config":93,"link":95,"lists":99,"footer":171},true,{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"Alle Lösungen anzeigen",{"href":98,"dataGaName":94,"dataGaLocation":30},"/de-de/solutions/",[100,126,149],{"title":101,"description":102,"link":103,"items":108},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":30},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[109,113,117,122],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":30,"dataGaName":110},"/de-de/solutions/continuous-integration/",{"text":114,"config":115},"KI-unterstützte Entwicklung",{"href":64,"dataGaLocation":30,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"Quellcodeverwaltung",{"href":120,"dataGaLocation":30,"dataGaName":121},"/de-de/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"Automatisierte Softwarebereitstellung",{"href":106,"dataGaLocation":30,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":30,"icon":133},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[135,139,144],{"text":136,"config":137},"Sicherheit und Compliance",{"href":131,"dataGaLocation":30,"dataGaName":138},"Security & Compliance",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":30,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Compliance und Governance",{"href":147,"dataGaLocation":30,"dataGaName":148},"/de-de/solutions/continuous-software-compliance/","Compliance and governance",{"title":150,"link":151,"items":156},"Bewertung",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":30},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Sichtbarkeit und Bewertung",{"href":154,"dataGaLocation":30,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Wertstrommanagement",{"href":164,"dataGaLocation":30,"dataGaName":165},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Analysen und Einblicke",{"href":169,"dataGaLocation":30,"dataGaName":170},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab für",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":30,"dataGaName":178},"/de-de/enterprise/","enterprise",{"text":180,"config":181},"Kleinunternehmen",{"href":182,"dataGaLocation":30,"dataGaName":183},"/de-de/small-business/","small business",{"text":185,"config":186},"den öffentlichen Sektor",{"href":187,"dataGaLocation":30,"dataGaName":188},"/de-de/solutions/public-sector/","public sector",{"text":190,"config":191},"Preise",{"href":192,"dataGaName":193,"dataGaLocation":30,"dataNavLevelOne":193},"/de-de/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":287},"Ressourcen",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"Alle Ressourcen anzeigen",{"href":201,"dataGaName":197,"dataGaLocation":30},"/de-de/resources/",[203,236,259],{"title":204,"items":205},"Erste Schritte",[206,211,216,221,226,231],{"text":207,"config":208},"Installieren",{"href":209,"dataGaName":210,"dataGaLocation":30},"/de-de/install/","install",{"text":212,"config":213},"Kurzanleitungen",{"href":214,"dataGaName":215,"dataGaLocation":30},"/de-de/get-started/","quick setup checklists",{"text":217,"config":218},"Lernen",{"href":219,"dataGaLocation":30,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Produktdokumentation",{"href":224,"dataGaName":225,"dataGaLocation":30},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Best-Practice-Videos",{"href":229,"dataGaName":230,"dataGaLocation":30},"/de-de/getting-started-videos/","best practice videos",{"text":232,"config":233},"Integrationen",{"href":234,"dataGaName":235,"dataGaLocation":30},"/de-de/integrations/","integrations",{"title":237,"items":238},"Entdecken",[239,244,249,254],{"text":240,"config":241},"Kundenerfolge",{"href":242,"dataGaName":243,"dataGaLocation":30},"/de-de/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":248,"dataGaLocation":30},"/de-de/blog/","blog",{"text":250,"config":251},"Remote",{"href":252,"dataGaName":253,"dataGaLocation":30},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":255,"config":256},"TeamOps",{"href":257,"dataGaName":258,"dataGaLocation":30},"/de-de/teamops/","teamops",{"title":260,"items":261},"Vernetzen",[262,267,272,277,282],{"text":263,"config":264},"GitLab-Services",{"href":265,"dataGaName":266,"dataGaLocation":30},"/de-de/services/","services",{"text":268,"config":269},"Community",{"href":270,"dataGaName":271,"dataGaLocation":30},"/community/","community",{"text":273,"config":274},"Forum",{"href":275,"dataGaName":276,"dataGaLocation":30},"https://forum.gitlab.com/","forum",{"text":278,"config":279},"Veranstaltungen",{"href":280,"dataGaName":281,"dataGaLocation":30},"/events/","events",{"text":283,"config":284},"Partner",{"href":285,"dataGaName":286,"dataGaLocation":30},"/de-de/partners/","partners",{"backgroundColor":288,"textColor":289,"text":290,"image":291,"link":295},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":292,"config":293},"the source promo card",{"src":294},"/images/navigation/the-source-promo-card.svg",{"text":296,"config":297},"Lies die News",{"href":298,"dataGaName":299,"dataGaLocation":30},"/de-de/the-source/","the source",{"text":301,"config":302,"lists":304},"Unternehmen",{"dataNavLevelOne":303},"company",[305],{"items":306},[307,312,318,320,325,330,335,340,345,350,355],{"text":308,"config":309},"Über",{"href":310,"dataGaName":311,"dataGaLocation":30},"/de-de/company/","about",{"text":313,"config":314,"footerGa":317},"Karriere",{"href":315,"dataGaName":316,"dataGaLocation":30},"/jobs/","jobs",{"dataGaName":316},{"text":278,"config":319},{"href":280,"dataGaName":281,"dataGaLocation":30},{"text":321,"config":322},"Geschäftsführung",{"href":323,"dataGaName":324,"dataGaLocation":30},"/company/team/e-group/","leadership",{"text":326,"config":327},"Team",{"href":328,"dataGaName":329,"dataGaLocation":30},"/company/team/","team",{"text":331,"config":332},"Handbuch",{"href":333,"dataGaName":334,"dataGaLocation":30},"https://handbook.gitlab.com/","handbook",{"text":336,"config":337},"Investor Relations",{"href":338,"dataGaName":339,"dataGaLocation":30},"https://ir.gitlab.com/","investor relations",{"text":341,"config":342},"Trust Center",{"href":343,"dataGaName":344,"dataGaLocation":30},"/de-de/security/","trust center",{"text":346,"config":347},"AI Transparency Center",{"href":348,"dataGaName":349,"dataGaLocation":30},"/de-de/ai-transparency-center/","ai transparency center",{"text":351,"config":352},"Newsletter",{"href":353,"dataGaName":354,"dataGaLocation":30},"/company/contact/","newsletter",{"text":356,"config":357},"Presse",{"href":358,"dataGaName":359,"dataGaLocation":30},"/press/","press",{"text":361,"config":362,"lists":363},"Kontakt",{"dataNavLevelOne":303},[364],{"items":365},[366,369,374],{"text":37,"config":367},{"href":39,"dataGaName":368,"dataGaLocation":30},"talk to sales",{"text":370,"config":371},"Support",{"href":372,"dataGaName":373,"dataGaLocation":30},"/support/","get help",{"text":375,"config":376},"Kundenportal",{"href":377,"dataGaName":378,"dataGaLocation":30},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":380,"login":381,"suggestions":388},"Schließen",{"text":382,"link":383},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":384,"config":385},"gitlab.com",{"href":44,"dataGaName":386,"dataGaLocation":387},"search login","search",{"text":389,"default":390},"Vorschläge",[391,394,399,401,406,411],{"text":59,"config":392},{"href":64,"dataGaName":393,"dataGaLocation":387},"GitLab Duo (AI)",{"text":395,"config":396},"Code Suggestions (KI)",{"href":397,"dataGaName":398,"dataGaLocation":387},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":110,"config":400},{"href":112,"dataGaName":110,"dataGaLocation":387},{"text":402,"config":403},"GitLab auf AWS",{"href":404,"dataGaName":405,"dataGaLocation":387},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":407,"config":408},"GitLab auf Google Cloud",{"href":409,"dataGaName":410,"dataGaLocation":387},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":412,"config":413},"Warum GitLab?",{"href":72,"dataGaName":414,"dataGaLocation":387},"Why GitLab?",{"freeTrial":416,"mobileIcon":421,"desktopIcon":426},{"text":417,"config":418},"Kostenlos testen",{"href":419,"dataGaName":35,"dataGaLocation":420},"https://gitlab.com/-/trials/new/","nav",{"altText":422,"config":423},"GitLab-Symbol",{"src":424,"dataGaName":425,"dataGaLocation":420},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":422,"config":427},{"src":428,"dataGaName":425,"dataGaLocation":420},"/images/brand/gitlab-logo-type.svg",{"freeTrial":430,"mobileIcon":434,"desktopIcon":436},{"text":431,"config":432},"Erfahre mehr über GitLab Duo",{"href":64,"dataGaName":433,"dataGaLocation":420},"gitlab duo",{"altText":422,"config":435},{"src":424,"dataGaName":425,"dataGaLocation":420},{"altText":422,"config":437},{"src":428,"dataGaName":425,"dataGaLocation":420},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":443,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"title":444,"button":445,"config":449,"_id":451,"_type":16,"_source":18,"_file":452,"_stem":453,"_extension":21},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":70,"config":446},{"href":447,"dataGaName":448,"dataGaLocation":30},"/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":24,"_draft":6,"_partial":6,"_locale":7,"data":456,"_id":660,"_type":16,"title":661,"_source":18,"_file":662,"_stem":663,"_extension":21},"/shared/de-de/main-footer",{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":652},"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,588,622],{"title":48,"links":481,"subMenu":486},[482],{"text":483,"config":484},"DevSecOps-Plattform",{"href":57,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":190,"links":488},[489,493,498],{"text":490,"config":491},"Tarife anzeigen",{"href":192,"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":136,"config":512},{"href":131,"dataGaName":513,"dataGaLocation":463},"security & compliance",{"text":123,"config":515},{"href":106,"dataGaName":107,"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":120,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":110,"config":531},{"href":112,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":162,"config":534},{"href":164,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/de-de/solutions/gitops/","gitops",{"text":175,"config":542},{"href":177,"dataGaName":178,"dataGaLocation":463},{"text":180,"config":544},{"href":182,"dataGaName":183,"dataGaLocation":463},{"text":546,"config":547},"Öffentlicher Sektor",{"href":187,"dataGaName":188,"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":195,"links":559},[560,562,564,566,569,571,574,576,578,580,582,584,586],{"text":207,"config":561},{"href":209,"dataGaName":210,"dataGaLocation":463},{"text":212,"config":563},{"href":214,"dataGaName":215,"dataGaLocation":463},{"text":217,"config":565},{"href":219,"dataGaName":220,"dataGaLocation":463},{"text":222,"config":567},{"href":224,"dataGaName":568,"dataGaLocation":463},"docs",{"text":245,"config":570},{"href":247,"dataGaName":248,"dataGaLocation":463},{"text":240,"config":572},{"href":573,"dataGaName":243,"dataGaLocation":463},"/customers/",{"text":250,"config":575},{"href":252,"dataGaName":253,"dataGaLocation":463},{"text":263,"config":577},{"href":265,"dataGaName":266,"dataGaLocation":463},{"text":255,"config":579},{"href":257,"dataGaName":258,"dataGaLocation":463},{"text":268,"config":581},{"href":270,"dataGaName":271,"dataGaLocation":463},{"text":273,"config":583},{"href":275,"dataGaName":276,"dataGaLocation":463},{"text":278,"config":585},{"href":280,"dataGaName":281,"dataGaLocation":463},{"text":283,"config":587},{"href":285,"dataGaName":286,"dataGaLocation":463},{"title":301,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":308,"config":591},{"href":310,"dataGaName":303,"dataGaLocation":463},{"text":313,"config":593},{"href":315,"dataGaName":316,"dataGaLocation":463},{"text":321,"config":595},{"href":323,"dataGaName":324,"dataGaLocation":463},{"text":326,"config":597},{"href":328,"dataGaName":329,"dataGaLocation":463},{"text":331,"config":599},{"href":333,"dataGaName":334,"dataGaLocation":463},{"text":336,"config":601},{"href":338,"dataGaName":339,"dataGaLocation":463},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":463},"/sustainability/",{"text":607,"config":608},"Vielfalt, Inklusion und Zugehörigkeit",{"href":609,"dataGaName":610,"dataGaLocation":463},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":341,"config":612},{"href":343,"dataGaName":344,"dataGaLocation":463},{"text":351,"config":614},{"href":353,"dataGaName":354,"dataGaLocation":463},{"text":356,"config":616},{"href":358,"dataGaName":359,"dataGaLocation":463},{"text":618,"config":619},"Transparenzerklärung zu moderner Sklaverei",{"href":620,"dataGaName":621,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":623,"links":624},"Nimm Kontakt auf",[625,628,630,632,637,642,647],{"text":626,"config":627},"Sprich mit einem Experten/einer Expertin",{"href":39,"dataGaName":40,"dataGaLocation":463},{"text":370,"config":629},{"href":372,"dataGaName":373,"dataGaLocation":463},{"text":375,"config":631},{"href":377,"dataGaName":378,"dataGaLocation":463},{"text":633,"config":634},"Status",{"href":635,"dataGaName":636,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":638,"config":639},"Nutzungsbedingungen",{"href":640,"dataGaName":641,"dataGaLocation":463},"/terms/","terms of use",{"text":643,"config":644},"Datenschutzerklärung",{"href":645,"dataGaName":646,"dataGaLocation":463},"/de-de/privacy/","privacy statement",{"text":648,"config":649},"Cookie-Einstellungen",{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":92},"cookie preferences","ot-sdk-btn",{"items":653},[654,656,658],{"text":638,"config":655},{"href":640,"dataGaName":641,"dataGaLocation":463},{"text":643,"config":657},{"href":645,"dataGaName":646,"dataGaLocation":463},{"text":648,"config":659},{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":92},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"featuredPost":665,"allPosts":687,"totalPages":1087,"initialPosts":1088},{"_path":666,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":667,"content":670,"config":680,"_id":683,"_type":16,"title":684,"_source":18,"_file":685,"_stem":686,"_extension":21},"/de-de/blog/exact-code-search-find-code-faster-across-repositories",{"noIndex":6,"title":668,"description":669,"ogTitle":668,"ogDescription":669},"Exact Code Search: Code blitzschnell in Repositories finden","So findet diese neue GitLab-Funktion exakte Treffer, nutzt Regex-Muster und zeigt kontextbezogene Ergebnisse in Terabyte-großen Codebasen an.",{"title":671,"description":669,"authors":672,"heroImage":674,"date":675,"body":676,"category":14,"tags":677},"Exact Code Search: So findet man Code blitzschnell über mehrere Repositories hinweg",[673],"Dmitry Gruzd","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-06-25","**Kurz gesagt:** Was wäre, wenn du jede Codezeile in 48 TB an Repositories in Millisekunden finden könntest? GitLabs neue [Exact Code Search](https://docs.gitlab.com/ee/user/search/exact_code_search.html) macht genau das möglich – mit präzisen Treffern, leistungsstarker Regex-Unterstützung und kontextbezogenen mehrzeiligen Ergebnissen, die die Arbeit mit großen Codebasen revolutionieren.\n\n## Warum traditionelle Code-Suche herausfordernd ist\n\nJeder, der mit Code arbeitet, kennt die Frustration bei der Suche über Repositories hinweg. Egal ob du als Entwickler(in) einen Fehler debuggst, als DevOps-Ingenieur(in) Konfigurationen untersuchst, als Sicherheitsanalyst(in) nach Schwachstellen suchst, als technische(r) Redakteur(in) Dokumentationen aktualisierst oder als Manager(in) Implementierungen überprüfst – du weißt genau, was du brauchst, aber herkömmliche Suchwerkzeuge lassen dich oft im Stich.\n\nDiese konventionellen Tools liefern Dutzende von False Positives, bieten nicht den nötigen Kontext zum Verständnis der Ergebnisse und werden mit wachsenden Codebasen immer langsamer. Das Ergebnis? Wertvolle Zeit wird mit der Suche nach der Nadel im Heuhaufen verschwendet, anstatt Software zu entwickeln, zu sichern oder zu verbessern.\n\nGitLabs Code-Suchfunktion basierte bisher auf Elasticsearch oder OpenSearch. Diese eignen sich zwar hervorragend für die Suche in Issues, Merge Requests, Kommentaren und anderen Daten mit natürlicher Sprache, wurden aber nicht speziell für Code entwickelt. Nach der [Evaluierung zahlreicher Optionen](https://gitlab.com/groups/gitlab-org/-/epics/7404) haben wir eine bessere Lösung entwickelt.\n\n## Wir stellen vor: Exact Code Search – drei bahnbrechende Funktionen\n\nMit GitLabs **[Exact Code Search](https://docs.gitlab.com/ee/user/search/exact_code_search.html)**, derzeit in der Beta-Phase und angetrieben von [Zoekt](https://github.com/sourcegraph/zoekt) (ausgesprochen \"sukt\", niederländisch für \"sucht\"). Zoekt ist eine Open-Source-Code-Suchmaschine, die ursprünglich von Google entwickelt und jetzt von Sourcegraph gepflegt wird – speziell konzipiert für schnelle, präzise Code-Suche im großen Maßstab. Wir haben sie mit GitLab-spezifischen Integrationen, Verbesserungen für Unternehmensmaßstäbe und nahtloser Integration des Berechtigungssystems erweitert.\n\nDiese Funktion revolutioniert, wie du Code findest und verstehst, mit drei Hauptfunktionen:\n\n**1. Exact Match-Modus: Null False Positives**\n\nIm **Exact Match-Modus** liefert die Suchmaschine nur Ergebnisse, die exakt deiner Suchanfrage entsprechen, und eliminiert False Positives. Diese Präzision ist unbezahlbar beim:\n\n* Suchen nach spezifischen Fehlermeldungen\n* Finden bestimmter Funktionssignaturen\n* Aufspüren von Instanzen spezifischer Variablennamen\n\n**2. Regular Expression-Modus: Leistungsstarkes Pattern Matching**\n\nFür komplexe Suchanforderungen ermöglicht der Regular Expression-Modus die Erstellung ausgefeilter Suchmuster:\n\n* Finde Funktionen, die bestimmten Namensmustern folgen\n* Lokalisiere Variablen mit bestimmten Einschränkungen\n* Identifiziere potenzielle Sicherheitslücken mittels Pattern Matching\n\n**3. Mehrzeilige Treffer: Code im Kontext sehen**\n\n![Exact Code Search](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750704179/ttjuilkt3v7gtyywnchx.png)\n\nStatt nur eine einzelne Zeile mit deinem Suchbegriff zu sehen, erhältst du den umgebenden Kontext, der für das Verständnis des Codes entscheidend ist. Das eliminiert die Notwendigkeit, für grundlegendes Verständnis in Dateien zu klicken, und beschleunigt deinen Workflow erheblich.\n\n## Von Funktionen zu Workflows: Anwendungsfälle und Auswirkungen aus der Praxis\n\nSchauen wir uns an, wie diese Funktionen zu echten Produktivitätssteigerungen in alltäglichen Entwicklungsszenarien führen:\n\n### Debugging: Von der Fehlermeldung zur Ursache in Sekunden\n\nVor Exact Code Search:\nEine Fehlermeldung kopieren, suchen, durch Dutzende von Teiltreffern in Kommentaren und Dokumentation waten, durch mehrere Dateien klicken und schließlich den tatsächlichen Code finden.\n\nMit Exact Code Search:\n\n1. Die exakte Fehlermeldung kopieren\n2. Sie in Exact Code Search im Exact Match-Modus einfügen\n3. Sofort die präzise Stelle finden, wo der Fehler ausgelöst wird, mit umgebendem Kontext\n\n**Auswirkung:** Reduziere die Debugging-Zeit von Minuten auf Sekunden und eliminiere die Frustration durch False Positives.\n\n### Code-Exploration: Unbekannte Codebasen schnell meistern\n\nVor Exact Code Search:\nDurch Verzeichnisse browsen, fundierte Vermutungen über Dateispeicherorte anstellen, Dutzende von Dateien öffnen und langsam eine mentale Karte der Codebasis aufbauen.\n\nMit Exact Code Search:\n\n* Nach Schlüsselmethoden oder -klassen im Exact Match-Modus suchen\n* Mehrzeilige Treffer überprüfen, um Implementierungsdetails zu verstehen\n* Den Regular Expression-Modus nutzen, um ähnliche Muster in der Codebasis zu finden\n\n**Auswirkung:** Baue eine mentale Karte der Code-Struktur in Minuten statt Stunden auf und beschleunige Onboarding und teamübergreifende Zusammenarbeit dramatisch.\n\n### Refactoring mit Zuversicht\n\nVor Exact Code Search:\nVersuchen, alle Instanzen einer Methode zu finden, einige Vorkommen übersehen und durch unvollständiges Refactoring Fehler einführen.\n\nMit Exact Code Search:\n\n* Den Exact Match-Modus nutzen, um alle Vorkommen von Methoden oder Variablen zu finden\n* Kontext überprüfen, um Verwendungsmuster zu verstehen\n* Dein Refactoring mit vollständigen Informationen über die Auswirkungen planen\n\n**Auswirkung:** Eliminiere die \"übersehene Instanz\"-Fehler, die Refactoring-Bemühungen oft plagen, verbessere die Code-Qualität und reduziere Nacharbeit.\n\n### Sicherheitsaudits: Verwundbare Muster finden\n\nSicherheitsteams können:\n\n* Regex-Muster erstellen, die bekanntem verwundbarem Code entsprechen\n* Über alle Repositories in einem Namespace suchen\n* Schnell potenzielle Sicherheitsprobleme mit Kontext identifizieren, der bei der Risikobewertung hilft\n\n**Auswirkung:** Verwandle Sicherheitsaudits von manuellen, fehleranfälligen Prozessen in systematische, umfassende Überprüfungen.\n\n### Repository-übergreifende Einblicke\n\nSuche über deinen gesamten Namespace oder deine Instanz, um:\n\n* Ähnliche Implementierungen in verschiedenen Projekten zu identifizieren\n* Möglichkeiten für gemeinsame Bibliotheken oder Standardisierung zu entdecken\n\n**Auswirkung:** Baue Silos zwischen Projekten ab und identifiziere Möglichkeiten für Code-Wiederverwendung und Standardisierung.\n\n## Die technische Grundlage: Wie Zoekt Geschwindigkeit und Präzision liefert\n\nBevor wir in unsere Skalierungserfolge eintauchen, lass uns erkunden, was Zoekt grundlegend von traditionellen Suchmaschinen unterscheidet – und warum es exakte Treffer so unglaublich schnell finden kann.\n\n### Positionale Trigramme: Das Geheimnis blitzschneller exakter Treffer\n\nZoekts Geschwindigkeit kommt von der Verwendung **positionaler Trigramme** – einer Technik, die jede Sequenz von drei Zeichen zusammen mit ihren exakten Positionen in Dateien indexiert. Dieser Ansatz löst einen der größten Schmerzpunkte, die Entwickler(innen) mit Elasticsearch-basierter Code-Suche hatten: False Positives.\n\nSo funktioniert es:\n\n**Traditionelle Volltextsuchmaschinen** wie Elasticsearch tokenisieren Code in Wörter und verlieren Positionsinformationen. Wenn du nach `getUserId()` suchst, könnten sie Ergebnisse liefern, die **user**, **get** und **Id** über eine Datei verteilt enthalten – was zu diesen frustrierenden False Positives für GitLab-Nutzer(innen) führt.\n\n**Zoekts positionale Trigramme** behalten exakte Zeichensequenzen und ihre Positionen bei. Wenn du nach `getUserId()` suchst, sucht Zoekt nach den exakten Trigrammen wie **get**, **etU**, **tUs**, **Use**, **ser**, **erI**, **rId**, **Id(**, **d()**, alle in der korrekten Reihenfolge und Position. Das stellt sicher, dass nur exakte Treffer zurückgegeben werden.\n\nDas Ergebnis? Suchanfragen, die zuvor Hunderte irrelevanter Ergebnisse lieferten, liefern jetzt nur noch die präzisen Treffer, nach denen du suchst. Das war [eine unserer meistgewünschten Funktionen](https://gitlab.com/gitlab-org/gitlab/-/issues/325234) aus gutem Grund – Entwickler(innen) verloren erhebliche Zeit beim Durchsuchen von False Positives.\n\n### Regular Expression-Performance im großen Maßstab\n\nZoekt glänzt bei exakten Treffern und ist für Regular Expression-Suchen optimiert. Die Engine nutzt ausgefeilte Algorithmen, um Regex-Muster wenn möglich in effiziente Trigramm-Abfragen umzuwandeln und behält die Geschwindigkeit selbst bei komplexen Mustern über Terabytes von Code bei.\n\n## Entwickelt für Unternehmensmaßstäbe\n\nExact Code Search ist leistungsstark und für massive Skalierung mit beeindruckender Performance gebaut. Das ist nicht nur eine neue UI-Funktion – sie wird von einer komplett neu konzipierten Backend-Architektur angetrieben.\n\n### Terabytes von Code mit Leichtigkeit bewältigen\n\nAllein auf GitLab.com indexiert und durchsucht unsere Exact Code Search-Infrastruktur über **48 TB** an Code-Daten bei gleichzeitig blitzschnellen Antwortzeiten. Diese Größenordnung repräsentiert Millionen von Repositories über Tausende von Namespaces, alle innerhalb von Millisekunden durchsuchbar. Um das in Perspektive zu setzen: Diese Größenordnung repräsentiert mehr Code als die gesamten Linux-Kernel-, Android- und Chromium-Projekte zusammen. Dennoch kann Exact Code Search eine spezifische Zeile in dieser massiven Codebasis in Millisekunden finden.\n\n### Selbstregistrierende Node-Architektur\n\nUnsere innovative Implementierung bietet:\n\n* **Automatische Node-Registrierung:** Zoekt-Nodes registrieren sich selbst bei GitLab\n* **Dynamische Shard-Zuweisung:** Das System weist Namespaces automatisch Nodes zu\n* **Gesundheitsüberwachung:** Nodes, die sich nicht melden, werden automatisch als offline markiert\n\nDiese selbstkonfigurierende Architektur vereinfacht die Skalierung dramatisch. Wenn mehr Kapazität benötigt wird, können Administratoren einfach weitere Nodes hinzufügen, ohne komplexe Neukonfiguration.\n\n### Verteiltes System mit intelligentem Load Balancing\n\nHinter den Kulissen arbeitet Exact Code Search als verteiltes System mit diesen Schlüsselkomponenten:\n\n* **Spezialisierte Such-Nodes:** Zweckgebundene Server, die Indexierung und Suche übernehmen\n* **Intelligentes Sharding:** Code wird basierend auf Namespaces über Nodes verteilt\n* **Automatisches Load Balancing:** Das System verteilt Arbeit intelligent basierend auf Kapazität\n* **Hohe Verfügbarkeit:** Mehrere Replikate gewährleisten kontinuierlichen Betrieb, selbst wenn Nodes ausfallen\n\n*Hinweis: Hohe Verfügbarkeit ist in die Architektur integriert, aber noch nicht vollständig aktiviert. Siehe [Issue 514736](https://gitlab.com/gitlab-org/gitlab/-/issues/514736) für Updates.*\n\n### Nahtlose Sicherheitsintegration\n\nExact Code Search integriert sich automatisch mit GitLabs Berechtigungssystem:\n\n* Suchergebnisse werden basierend auf den Zugriffsrechten des Nutzers gefiltert\n* Nur Code aus Projekten, auf die der Nutzer Zugriff hat, wird angezeigt\n* Sicherheit ist in die Kernarchitektur integriert, nicht nachträglich hinzugefügt\n\n### Optimierte Performance\n\n* **Effiziente Indexierung:** Große Repositories werden in Dutzenden von Sekunden indexiert\n* **Schnelle Query-Ausführung:** Die meisten Suchen liefern Ergebnisse mit Antwortzeiten unter einer Sekunde\n* **Streaming-Ergebnisse:** Die neue gRPC-basierte föderierte Suche streamt Ergebnisse, sobald sie gefunden werden\n* **Frühzeitiger Abbruch:** Sobald genügend Ergebnisse gesammelt wurden, pausiert das System die Suche\n\n## Von der Bibliothek zum verteilten System: Technische Herausforderungen, die wir gelöst haben\n\nWährend Zoekt die Kern-Suchtechnologie bereitstellte, war es ursprünglich als minimale Bibliothek zur Verwaltung von `.zoekt`-Indexdateien konzipiert – nicht als verteilte Datenbank oder Unternehmens-Service. Hier sind die wichtigsten technischen Herausforderungen, die wir überwunden haben, um es in GitLabs Maßstab zum Laufen zu bringen:\n\n### Herausforderung 1: Aufbau einer Orchestrierungsschicht\n\n**Das Problem:** Zoekt war für die Arbeit mit lokalen Indexdateien konzipiert, nicht für die Verteilung über mehrere Nodes, die viele gleichzeitige Nutzer bedienen.\n\n**Unsere Lösung:** Wir haben eine umfassende Orchestrierungsschicht aufgebaut, die:\n\n* Datenbankmodelle erstellt und verwaltet, um Nodes, Indizes, Repositories und Aufgaben zu verfolgen\n* Eine selbstregistrierende Node-Architektur implementiert (inspiriert von GitLab Runner)\n* Automatische Shard-Zuweisung und Load Balancing über Nodes hinweg handhabt\n* Bidirektionale API-Kommunikation zwischen GitLab Rails und Zoekt-Nodes bereitstellt\n\n### Herausforderung 2: Skalierung von Speicher und Indexierung\n\n**Das Problem:** Wie verwaltet man effizient Terabytes von Indexdaten über mehrere Nodes bei gleichzeitig schnellen Updates?\n\n**Unsere Lösung:** Wir implementierten:\n\n* Intelligentes Sharding: Namespaces werden basierend auf Kapazität und Last über Nodes verteilt\n* Unabhängige Replikation: Jeder Node indexiert unabhängig von [Gitaly](https://gitlab.com/gitlab-org/gitaly) (unserem Git-Speicherdienst), wodurch komplexe Synchronisation eliminiert wird\n* Watermark-Management: Ausgefeilte Speicherzuweisung, die verhindert, dass Nodes der Speicherplatz ausgeht\n* Einheitliche Binary-Architektur: Ein einzelnes `gitlab-zoekt`-Binary, das sowohl im Indexer- als auch im Webserver-Modus arbeiten kann\n\n### Herausforderung 3: Berechtigungsintegration\n\n**Das Problem:** Zoekt hatte kein Konzept von GitLabs komplexem Berechtigungssystem – Nutzer sollten nur Ergebnisse aus Projekten sehen, auf die sie Zugriff haben.\n\n**Unsere Lösung:** Wir haben native Berechtigungsfilterung direkt in den Suchablauf integriert:\n\n* Suchanfragen enthalten Nutzerberechtigungskontext\n* Ergebnisse werden gefiltert, um nur die anzuzeigen, auf die der Nutzer zugreifen kann, falls sich Berechtigungen ändern, bevor die Indexierung abgeschlossen ist\n\n### Herausforderung 4: Betriebliche Einfachheit\n\n**Das Problem:** Die Verwaltung eines verteilten Suchsystems sollte kein dediziertes Team erfordern.\n\n**Unsere Lösung:**\n\n* Auto-Scaling: Das Hinzufügen von Kapazität ist so einfach wie das Bereitstellen weiterer Nodes – sie registrieren sich automatisch und beginnen mit der Arbeit\n* Selbstheilung: Nodes, die sich nicht melden, werden automatisch als offline markiert und ihre Arbeit wird umverteilt\n* Zero-Configuration-Sharding: Das System bestimmt automatisch optimale Shard-Zuweisungen\n\n## Schrittweiser Rollout: Risikominimierung im großen Maßstab\n\nDer Rollout eines komplett neuen Such-Backends für Millionen von Nutzern erforderte sorgfältige Planung. So haben wir die Auswirkungen auf Kunden minimiert und gleichzeitig Zuverlässigkeit sichergestellt:\n\n### Phase 1: Kontrolliertes Testen (gitlab-org-Gruppe)\n\nWir begannen damit, Exact Code Search nur für die `gitlab-org`-Gruppe zu aktivieren – unsere eigenen internen Repositories. Das ermöglichte uns:\n\n* Das System mit echten Produktions-Workloads zu testen\n* Performance-Engpässe zu identifizieren und zu beheben\n* Den Bereitstellungsprozess zu optimieren\n* Aus den Workflows und dem Feedback echter Nutzer zu lernen\n\n### Phase 2: Performance-Validierung und -Optimierung\n\nVor der Erweiterung konzentrierten wir uns darauf sicherzustellen, dass das System GitLab.coms Maßstab bewältigen konnte:\n\n* Umfassendes Monitoring und Alerting implementiert\n* Speicherverwaltung mit echtem Produktionsdatenwachstum validiert\n\n### Phase 3: Schrittweise Kundenerweiterung\n\nWir erweiterten schrittweise auf Kunden, die daran interessiert waren, Exact Code Search zu testen:\n\n* Feedback zu Performance und Benutzererfahrung gesammelt\n* Die Such-UI basierend auf echten Nutzer-Workflows verfeinert\n* Indexierungs-Performance optimiert (große Repositories wie `gitlab-org/gitlab` indexieren jetzt in ~10 Sekunden)\n* Die Architektur basierend auf betrieblichen Erkenntnissen verfeinert\n* Indexierungs-Durchsatz massiv erhöht und Zustandsübergangs-Lebenszyklus verbessert\n\n### Phase 4: Breiter Rollout\n\nHeute haben über 99 % der Premium- und Ultimate-lizenzierten Gruppen auf GitLab.com Zugriff auf Exact Code Search. Nutzer können:\n\n* Zwischen Regex- und exaktem Suchmodus umschalten\n* Die Vorteile ohne Konfigurationsänderungen erleben\n* Bei Bedarf auf die vorherige Suche zurückgreifen (obwohl wenige dies wählen)\n\nDer schrittweise Rollout bedeutete, dass Nutzer keine Service-Unterbrechungen, Performance-Verschlechterungen oder Feature-Lücken während des Übergangs erlebten. Wir haben bereits positives Feedback von Nutzern erhalten, die bemerken, dass ihre Ergebnisse relevanter und schneller werden.\n\n> **Für technische Details:** Interessiert an der detaillierten Architektur und Implementierung? Schau dir unser umfassendes [Design-Dokument](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/code_search_with_zoekt/) für ausführliche technische Details an, wie wir dieses verteilte Suchsystem gebaut haben.\n\n## Erste Schritte mit Exact Code Search\n\nDer Einstieg in Exact Code Search ist einfach, da es bereits standardmäßig für Premium- und Ultimate-Gruppen auf GitLab.com aktiviert ist (über 99 % der berechtigten Gruppen haben derzeit Zugriff).\n\n### Schnellstart-Anleitung\n\n1. Navigiere zur erweiterten Suche in deinem GitLab-Projekt oder deiner Gruppe\n2. Gib deinen Suchbegriff im Code-Tab ein\n3. Wechsle zwischen Exact Match- und Regular Expression-Modus\n4. Nutze Filter, um deine Suche zu verfeinern\n\n### Grundlegende Such-Syntax\n\nEgal ob du den Exact Match- oder Regular Expression-Modus verwendest, du kannst deine Suche mit Modifikatoren verfeinern:\n\n| Abfrage-Beispiel | Was es bewirkt                                              |\n| ---------------- | ----------------------------------------------------------- |\n| `file:js`        | Sucht nur in Dateien, die \"js\" im Namen enthalten           |\n| `foo -bar`       | Findet \"foo\", schließt aber Ergebnisse mit \"bar\" aus        |\n| `lang:ruby`      | Sucht nur in Ruby-Dateien                                   |\n| `sym:process`    | Findet \"process\" in Symbolen (Methoden, Klassen, Variablen) |\n\n> **Profi-Tipp:** Für die effizientesten Suchen beginne spezifisch und erweitere dann bei Bedarf. Die Verwendung von `file:`- und `lang:`-Filtern erhöht die Relevanz dramatisch.\n\n### Erweiterte Suchtechniken\n\nStapele mehrere Filter für Präzision:\n\n```\nis_expected file:rb -file:spec\n```\n\nDas findet \"is_expected\" in Ruby-Dateien, die nicht \"spec\" im Namen haben.\n\nNutze reguläre Ausdrücke für leistungsstarke Muster:\n\n```\ntoken.*=.*[\\\"']\n```\n\n[Sieh dir diese Suche im GitLab Zoekt Repository an.](https://gitlab.com/search?search=token.*%3D.*%5B%5C%22'%5D&nav_source=navbar&project_id=46649240&group_id=9970&search_code=true&repository_ref=main&regex=true)\n\nDie Suche hilft, hartcodierte Passwörter zu finden, die, wenn nicht gefunden, ein Sicherheitsproblem darstellen können.\n\nFür detailliertere Syntax-Informationen, schau in die [Exact Code Search-Dokumentation](https://docs.gitlab.com/user/search/exact_code_search/#syntax).\n\n## Verfügbarkeit und Bereitstellung\n\n### Aktuelle Verfügbarkeit\n\nExact Code Search befindet sich derzeit in der Beta-Phase für GitLab.com-Nutzer mit Premium- und Ultimate-Lizenzen:\n\n* Verfügbar für über 99 % der lizenzierten Gruppen\n* Die Suche in der UI nutzt automatisch Zoekt, wenn verfügbar, Exact Code Search in der Such-API ist hinter einem Feature-Flag\n\n### Bereitstellungsoptionen für Self-Managed\n\nFür Self-Managed-Instanzen bieten wir mehrere Bereitstellungsmethoden:\n\n* Kubernetes/Helm: Unsere am besten unterstützte Methode, mit unserem [`gitlab-zoekt` Helm Chart](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-zoekt)\n* Andere Bereitstellungsoptionen: Wir arbeiten an der Vereinfachung der Bereitstellung für Omnibus und andere Installationsmethoden\n\nDie Systemanforderungen hängen von deiner Codebasis-Größe ab, aber die Architektur ist darauf ausgelegt, horizontal und/oder vertikal zu skalieren, wenn deine Anforderungen wachsen.\n\n## Was als Nächstes kommt\n\nWährend Exact Code Search bereits leistungsstark ist, verbessern wir sie kontinuierlich:\n\n* **Skalierungsoptimierungen** zur Unterstützung von Instanzen mit Hunderttausenden von Repositories\n* **Verbesserte Self-Managed-Bereitstellungsoptionen**, einschließlich vereinfachter Omnibus-Unterstützung\n* **Vollständige Hochverfügbarkeits-Unterstützung** mit automatischem Failover und Load Balancing\n\nBleib dran für Updates, während wir von Beta zu General Availability übergehen.\n\n## Transformiere deine Arbeitsweise mit Code\n\nGitLabs Exact Code Search repräsentiert ein grundlegendes Umdenken bei der Code-Entdeckung. Durch die Bereitstellung exakter Treffer, leistungsstarker Regex-Unterstützung und kontextbezogener Ergebnisse löst sie die frustrierendsten Aspekte der Code-Suche:\n\n* Keine Zeitverschwendung mehr mit irrelevanten Ergebnissen\n* Keine wichtigen Treffer mehr verpassen\n* Kein Durchklicken von Dateien mehr nur für grundlegendes Verständnis\n* Keine Performance-Probleme mehr bei wachsenden Codebasen\n\nDie Auswirkungen gehen über die individuelle Produktivität hinaus:\n\n* **Teams arbeiten besser zusammen** mit einfacher Code-Referenzierung\n* **Wissensaustausch beschleunigt sich**, wenn Muster auffindbar sind\n* **Onboarding wird schneller** mit schnellem Codebasis-Verständnis\n* **Sicherheit verbessert sich** mit effektivem Muster-Auditing\n* **Abbau technischer Schulden** wird machbarer\n\nExact Code Search ist nicht nur eine Funktion, es ist eine bessere Art, Code zu verstehen und damit zu arbeiten. Hör auf zu suchen und fang an zu finden.\n\n**Wir würden gerne von dir hören!** Teile deine Erfahrungen, Fragen oder Feedback zu Exact Code Search in unserem [Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/420920). Dein Input hilft uns, Verbesserungen und neue Funktionen zu priorisieren.\n\n> ### Bereit für smartere Code-Suche? Erfahre mehr in unserer [Dokumentation](https://docs.gitlab.com/ee/user/search/exact_code_search.html) oder probiere es jetzt aus, indem du eine Suche in deinen Premium- oder Ultimate-lizenzierten Namespaces oder Projekten durchführst. Noch kein GitLab-Nutzer? Teste [kostenlos GitLab Ultimate mit Duo für 60 Tage](https://about.gitlab.com/free-trial/)!",[14,678,679],"tutorial","open source",{"featured":6,"template":681,"slug":682},"BlogPost","exact-code-search-find-code-faster-across-repositories","content:de-de:blog:exact-code-search-find-code-faster-across-repositories.yml","Exact Code Search Find Code Faster Across Repositories","de-de/blog/exact-code-search-find-code-faster-across-repositories.yml","de-de/blog/exact-code-search-find-code-faster-across-repositories",[688,709,734,758,780,799,824,844,865,887,909,931,950,971,992,1015,1039,1062],{"_path":689,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":690,"content":693,"config":703,"_id":705,"_type":16,"title":706,"_source":18,"_file":707,"_stem":708,"_extension":21},"/de-de/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":691,"title":692},"Ein neues Angebot von GitLab und IBM überbrückt Mainframe- und Cloud-native-Entwicklung mit nahtloser Integration, CI/CD-Runner-Unterstützung, End-to-End-Transparenz und Kosteneffizienz.","GitLab Ultimate für IBM Z: Moderne DevSecOps für Mainframes",{"heroImage":694,"body":695,"authors":696,"updatedDate":699,"date":700,"title":692,"tags":701,"description":691,"category":14},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750440008/myqt5vcjlffh8sszw507.png","GitLab und IBM haben sich zusammengeschlossen, um eine grundlegende Diskrepanz in der Unternehmensentwicklung zu lösen: Mainframe-Entwickler(innen) sollen mit denselben modernen Tools, Workflows und Kollaborationsfunktionen arbeiten können wie ihre Kolleg(inn)en in verteilten Umgebungen.\n\nGitLab Ultimate für IBM Z, eine von GitLab zertifizierte, integrierte DevSecOps-Lösung, die speziell für die Mainframe-Umgebung entwickelt wurde, macht genau das möglich: Sie ermöglicht es Unternehmen, ihre Mainframe-Entwicklungsworkflows zu modernisieren, indem eine nahtlose Migration von veralteten Legacy-Bibliotheksmanagern erleichtert wird. Mit CI/CD-Pipelines, die nativ auf IBM z/OS laufen, erleben Kund(inn)en beschleunigte Innovation und reduzierte Betriebskosten.\n\n## Herausforderungen der heutigen Mainframe-Entwicklung\n\nUnternehmen, die IBM Z-Systeme für geschäftskritische Workloads einsetzen, stehen vor Herausforderungen, für die herkömmliche DevSecOps-Tools nicht ausgestattet sind. Cloud-native Teams profitieren von modernen [CI/CD](https://about.gitlab.com/topics/ci-cd/)-Pipelines, kollaborativer Entwicklung und automatisierten Tests. Im Gegensatz dazu werden Mainframe-Teams oft zurückgelassen – sie stecken mit veralteten Tools fest, die zu kostspieligen Ineffizienzen und operativen Silos führen.\n\nTeams greifen oft auf Workarounds zurück, wie SSH-Verbindungen und manuelle Dateiübertragungen, die Sicherheitslücken schaffen und Audits erschweren. Wenn Compliance-Anforderungen streng sind, werden diese improvisierten Lösungen zu inakzeptablen Risiken. Gleichzeitig unterhalten Organisationen teure parallele Toolchains, wobei Legacy-Mainframe-Entwicklungstools Premium-Lizenzkosten verursachen, während sie im Vergleich zu modernen Alternativen nur eingeschränkte Funktionalität bieten.\n\nDiese Fragmentierung schafft zwei Probleme: langsamere Bereitstellungszyklen und Schwierigkeiten bei der Rekrutierung von Entwickler(inne)n, die modernste Prozesse erwarten.\n\n> **„GitLab Ultimate für IBM Z stellt einen wichtigen Schritt zur Bewältigung einer langjährigen Branchenherausforderung dar. IDC-Forschung zeigt, dass Mainframe-Entwickler(innen) oft mit Legacy-Tools arbeiten, die zu Bereitstellungsineffizienzen beitragen und es schwieriger machen, neue Talente anzuziehen. Mit diesem Angebot werden moderne DevSecOps-Fähigkeiten und einheitliche Workflows direkt auf den Mainframe gebracht. Dies befähigt Entwickler(innen), kollaborativer und effizienter zu arbeiten, während es Organisationen hilft, Innovation zu beschleunigen und Mainframe-Entwicklung in breitere digitale Transformationsstrategien zu integrieren.\"** - Katie Norton, Research Manager, DevSecOps und Software Supply Chain Security bei IDC\n\n## Vereinheitlichte Entwicklungsumgebungen\n\nWahre Modernisierung bedeutet mehr als nur die Aktualisierung der Mainframe-Entwicklung. Es bedeutet, eine einheitliche Plattform zu schaffen, auf der Mainframe-, Cloud-native-, Web- und Mobile-Entwicklungsteams nahtlos zusammenarbeiten.\n\nGitLab Ultimate für IBM Z ermöglicht es Entwickler(inne)n, konsistente Workflows zu verwenden, unabhängig davon, ob sie auf z/OS, Cloud oder On-Premises-Infrastruktur bereitstellen – Wissen wird zwischen Teams übertragen, anstatt in Silos zu verbleiben. Organisationen können schrittweise modernisieren, ohne Geschäftsunterbrechungen, da Legacy-Systeme weiterhin funktionieren, während Teams moderne Praktiken in ihrem eigenen Tempo übernehmen.\n\nWährend Organisationen Hybrid-Cloud-Strategien verfolgen, bietet GitLab die Grundlage für Anwendungen, die sich über Mainframe- und Cloud-native-Umgebungen erstrecken.\n\n## Was ist GitLab Ultimate für IBM Z?\n\nGitLab Ultimate für IBM Z bietet native z/OS-Runner-Unterstützung und ermöglicht eine nahtlose CI/CD-Pipeline-Ausführung direkt auf Ihrer Mainframe-Infrastruktur. Diese von GitLab zertifizierte Lösung hilft, die Notwendigkeit komplexer Workarounds zu eliminieren und gleichzeitig die Sicherheit und Zuverlässigkeit zu gewährleisten, die Ihre Unternehmensanwendungen erfordern.\n\nDie Kombination aus GitLabs umfassender DevSecOps-Plattform und IBMs tiefgreifender Mainframe-Expertise schafft etwas Einzigartiges auf dem Markt: eine zertifizierte Lösung, die eine echte Brücke zwischen unternehmenskritischen Legacy-Systemen und Cloud-nativer Innovation bietet.\n\n## GitLab Ultimate für IBM Z Funktionen\n\nGitLab Ultimate für IBM Z bietet Unternehmensteams die Tools, die sie benötigen, um die Mainframe-Entwicklung zu modernisieren und gleichzeitig kritische Geschäftssysteme zu erhalten.\n\n**Native z/OS-Runner-Unterstützung** hilft, Sicherheitsrisiken und Skalierbarkeitsengpässe im Zusammenhang mit Remote-Verbindungen zu eliminieren, während die Bereitstellung durch CI/CD-Pipelines beschleunigt wird, die direkt dort ausgeführt werden, wo sich Ihr Mainframe-Code befindet.\n\n**Einheitliches Source Code Management** modernisiert Toolchains, indem teure Legacy-Bibliotheksmanager durch GitLabs durchsuchbares, versionskontrolliertes Repository-System ersetzt werden, was zur Reduzierung von Lizenzkosten und Wartungsaufwand beiträgt.\n\n**Nahtlose Integration** mit IBM Developer for z/OS Enterprise Edition (IDzEE) liefert schnellere Software-Releases durch abhängigkeitsbasierte Builds, automatisiertes Code-Scanning und umfassende Debugging-Tools in vertrauten Entwicklerumgebungen, wodurch sowohl Qualität als auch Sicherheit verbessert werden.\n\n**End-to-End-Transparenz** über Mainframe- und verteilte Umgebungen hinweg bietet umfassendes Projektmanagement von der Planung bis zur Produktion und ermöglicht automatisierte DevOps-Workflows, die durch moderne Entwicklungstools der nächsten Generation zur Talentbindung beitragen.\n\n## Modernisiere deine Mainframe-Entwicklungsumgebung noch heute\n\nGitLab Ultimate für IBM Z ist jetzt für Organisationen verfügbar, die bereit sind, ihre Mainframe-Entwicklungserfahrung zu transformieren. Weitere Informationen befinden sich auf der [GitLab und IBM Partnerseite](https://about.gitlab.com/de-de/partners/technology-partners/ibm/).",[697,698],"Mike Flouton","Andy Bradfield","2025-06-23","2025-06-20",[286,14,110,702],"DevSecOps",{"featured":92,"template":681,"slug":704},"gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes","content:de-de:blog:gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","Gitlab Ultimate For Ibm Z Modern Devsecops For Mainframes","de-de/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","de-de/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"_path":710,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":711,"content":719,"config":728,"_id":730,"_type":16,"title":731,"_source":18,"_file":732,"_stem":733,"_extension":21},"/de-de/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"ogTitle":712,"schema":713,"ogImage":714,"ogDescription":715,"ogSiteName":716,"noIndex":6,"ogType":717,"ogUrl":718,"title":712,"canonicalUrls":718,"description":715},"GitLab ist ein Leader in der Forrester Wave™: DevOps Platforms, Q2 2025","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab ist ein Leader in der The Forrester Wave™: DevOps Platforms, Q2 2025\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2025-06-02\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658898/Blog/Hero%20Images/blog-post-image-forrester-wave-1800x945px-fy26.png","Forrester bezeichnet die GitLab-Plattform als die „All-in-One-Lösung unter den All-in-One-Lösungen“ und geeignet „für Unternehmen, die mit einem Kauf eine Standardisierung herbeiführen möchten“.","https://about.gitlab.com","article","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"heroImage":714,"body":720,"authors":721,"updatedDate":7,"date":723,"title":712,"tags":724,"description":715,"category":14},"Die Wahl einer DevSecOps-Plattform ist eine der wichtigesten technologischen Entscheidungen, die ein Unternehmen zu treffen hat. Deshalb freuen wir uns sehr, dass wir als [**führender Anbieter in The Forrester Wave™: DevOps Platforms, Q2 2025** (nur in englischer Sprache verfügbar)](https://about.gitlab.com/forrester-wave-devops-platform/) ausgezeichnet wurden. \n\nWir haben die höchstmöglichen Punktzahlen bei den Kriterien erhalten, die unseren Kund(inn)en laut ihren eigenen Angaben am wichtigsten sind, einschließlich der Benutzungserfahrung am ersten Tag, der Entwicklungstools, der Build-Automatisierung und CI, der automatisierten Bereitstellung, der Risikominderung im Zusammenhang mit KI, KI-Infusion, direkt integrierter Sicherheitstools und Plattformkohäsion.\n\n***„GitLab ist die All-in-One-Lösung unter den All-in-One-Lösungen, die ihrem Namen am stärksten gerecht wird, und eignet sich damit für Unternehmen, die mit einem einzigen Kauf eine Standardisierung herbeiführen möchten.“ –*** Forrester Wave™: DevOps Platforms, Q2 2025\n\nDiese Auszeichnung spiegelt das wider, was wir selbst von unseren Kund(inn)en gehört haben: Sie müssen sichere Software schneller bereitstellen, doch ihre bestehenden Lösungen zwingen sie, Kompromisse bei der Geschwindigkeit, Sicherheit oder Einfachheit einzugehen. GitLab wird jedoch allen drei Anforderungen gerecht. Und mit unserer [Veröffentlichung von GitLab 18.0 (nur in englischer Sprache verfügbar)](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/) im Mai sind wir noch einen Schritt weiter gegangen, indem wir ohne zusätzliche Kosten [die KI-nativen Funktionen von GitLab Duo](https://about.gitlab.com/de-de/blog/gitlab-premium-with-duo/) – wie Test Generation, Code Suggestions und Code Refactoring – direkt in GitLab Premium und GitLab Ultimate integriert haben.\n\n> **[Erhalte jetzt Zugang zum englischsprachigen Bericht.](https://about.gitlab.com/forrester-wave-devops-platform/)**\n\n![ Forrester Wave™: DevOps-Plattformen, Grafik Q2 2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673518/Blog/Content%20Images/Image_DevOps-Platforms-Q2-2025.png)\n\n## Mit unternehmensweiter Kontrolle an der Spitze der KI-Transformation bleiben\n\nDevSecOps entwickelt sich rasant weiter, wobei die KI an der Spitze dieses Wandels steht. Leider zwingen viele KI-Tools die Anwender(innen) zu einer Wahl: entweder modernste Funktionen oder eine höchstmögliche Unternehmenssicherheit. \n\nGitLab hat sowohl bei den Kriterien **KI-Infusion** als auch **KI-Risikominderung** 5 Punkte erhalten – die höchste mögliche Punktzahl. Wir freuen uns, dass unser klarer Fokus auf die Entwicklung innovativer KI-Funktionen, bei denen gleichermaßen eine umfassende Sicherheit gewährleistet bleibt, nicht nur von unseren Kund(inn)en wahrgenommen wird.\n\nDiese doppelte Stärke zeigt sich in unseren KI-Angeboten von GitLab Duo, unter anderem:\n\n* Duo Workflow (private Beta-Version): Autonome KI-Agenten, die komplexe Aufgaben bei der Entwicklung, Sicherheit und Betrieb bewältigen – mit Leitlinien und Audit-Trails auf Enterprise-Niveau.  \n* Agentic Chat: Kontextbezogene, dialogorientierte KI-Unterstützung für alles von Codeerläuterungen bis hin zur Erstellung von Tests – mit integriertem Schutz des geistigen Eigentums und Datenschutzkontrollen.  \n* Code Suggestions: KI-Unterstützung, die Codeblöcke vorausschauend vervollständigen, eine Funktionslogik definieren, Tests generieren und häufig verwendeten Code wie Regex-Muster vorschlagen kann.  \n* KI-native Vulnerability Resolution: Findet und behebt Sicherheitslücken mit automatischen Erklärungen und automatisch erstellten Merge Requests, um so den Entwicklungsprozess zu optimieren.\n\n## Mit weniger mehr erreichen\n\nWir haben deutlich vernommen, dass DevSecOps-Teams nicht noch mehr Tools und Integrationen benötigen, die sie bei einzelnen Abschnitten ihres Software-Entwicklungsprozesses unterstützen. Sie benötigen stattdessen eine nahtlose, integrierte Entwicklererfahrung, die den gesamten Lebenszyklus der Softwareentwicklung abdeckt.\n\nWir sind überzeugt, dass die Bewertungen von GitLab in den folgenden Kriterien unsere kundenorientierte Strategie bestätigen:\n\n* **Nutzungserfahrung am ersten Tag:** Forrester zitiert unsere „starke Nutzungserfahrung am ersten Tag“ und stellt fest, dass „alles sofort einsatzbereit ist“, unterstützt durch umfangreiche Migrationstools und Tutorials. \n* **Entwicklertools:** Forrester verweist beispielhaft auf [GitLab Duo mit Amazon Q](https://about.gitlab.com/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), unser Angebot für agentische KI für AWS-Kund(inn)en, sowie auf unsere Entwicklungsumgebung in der Cloud, die integrierte Entwicklungsplattform und Wikis für die Dokumentation.  \n* **Projektplanung und -abstimmung:** Forrester hebt unser „starkes Compliance Center“ hervor und stellt fest, dass wir über Tools verfügen, um die Abstimmung in beide Richtungen voranzutreiben.  \n* **Pipeline-Sicherheit:** Forrester gibt uns die höchstmögliche Punktzahl beim Kriterium Pipeline-Sicherheit.  \n* **Build-Automatisierung und CI:** Forrester erwähnt unsere Build-Automatisierung und CI mit mehrstufigen Build-Pipelines und einer starken Unterstützung für selbst gehostete Installationen.\n\n## Bericht lesen \n\nFür uns spiegelt sich in unserer Auszeichnung als führender Anbieter in The Forrester Wave™: DevOps-Plattformen, Q2 2025 die Breite und Tiefe der Funktionen unserer Plattform wider, die als Single Source of Truth über den gesamten Lebenszyklus der Softwareentwicklung hinweg fungiert. Kein Jonglieren mit mehreren Tools und Integrationen mehr – GitLab bietet eine nahtlose, integrierte Erfahrung, die die Produktivität steigert und Reibungsverluste reduziert. \n\nWir sind überzeugt, dass sich in dieser hervorragenden Platzierung die harte Arbeit unseres Teams, die vielen Beiträge der Open-Source-Community von GitLab, das unschätzbare Feedback unserer Kund(inn)en und unser Engagement für die Gestaltung der Zukunft der Softwareentwicklung widerspiegeln.\n\n> **[Öffne den englischsprachigen Bericht.](https://about.gitlab.com/forrester-wave-devops-platform/)**\n\n*Forrester spricht keine Empfehlung für Unternehmen, Produkte, Marken oder Dienstleistungen aus, die in seinen Forschungspublikationen vorkommen, und rät niemandem, sich auf der Grundlage der in diesen Publikationen aufgeführten Bewertungen für die Produkte oder Dienstleistungen eines Unternehmens oder einer Marke zu entscheiden. Die Informationen basieren auf den besten verfügbaren Ressourcen. Die Meinungen spiegeln die jeweils aktuelle Einschätzung wider und können sich ändern. Weitere Informationen zur Objektivität von Forrester (in englischer Sprache) findest du [hier](https://www.forrester.com/about-us/objectivity/).*",[722],"Dave Steer","2025-06-02",[725,14,726,727],"research","news","DevSecOps platform",{"slug":729,"featured":92,"template":681},"gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","content:de-de:blog:gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","Gitlab Named A Leader In The Forrester Wave Devops Platforms Q2 2025","de-de/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","de-de/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"_path":735,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":736,"content":742,"config":752,"_id":754,"_type":16,"title":755,"_source":18,"_file":756,"_stem":757,"_extension":21},"/de-de/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"title":737,"description":738,"ogTitle":737,"ogDescription":738,"noIndex":6,"ogImage":739,"ogUrl":740,"ogSiteName":716,"ogType":717,"canonicalUrls":740,"schema":741},"Erste Schritte mit GitLab: Arbeiten mit CI/CD-Variablen","Erfahre, was CI/CD-Variablen sind, warum sie in DevSecOps wichtig sind und wie du sie am besten einsetzt.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659525/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25.png","https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab: Arbeiten mit CI/CD-Variablen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2025-05-27\",\n      }",{"title":737,"description":738,"authors":743,"heroImage":739,"date":745,"body":746,"category":14,"tags":747,"updatedDate":751},[744],"GitLab Team","2025-05-27","*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.* \n\nIn einem früheren Artikel haben wir uns mit [GitLab CI/CD](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-understanding-ci-cd/) beschäftigt. Jetzt tauchen wir tiefer in die Welt der **CI/CD-Variablen** ein und erschließen ihr volles Potenzial.\n\n## Inhaltsverzeichnis\n\n- [Was sind CI/CD-Variablen?](#was-sind-cicd-variablen%3F)\n- [Warum sind CI/CD-Variablen wichtig?](#warum-sind-cicd-variablen-wichtig%3F)\n- [Geltungsbereiche von CI/CD-Variablen: Projekt, Gruppe und Instanz](#geltungsbereiche-von-cicd-variablen-projekt-gruppe-und-instanz)\n- [Definieren von CI/CD-Variablen](#definieren-von-cicd-variablen)\n- [Verwenden von CI/CD-Variablen](#verwenden-von-cicd-variablen)\n- [Vordefinierte CI/CD-Variablen](#vordefinierte-cicd-variablen)\n- [Bewährte Methoden](#bewährte-methoden)\n- [Entdecke die Leistungsfähigkeit von Variablen](#entdecke-die-leistungsfähigkeit-von-variablen)\n- [Reihe „Erste Schritte mit GitLab\"](#reihe-„erste-schritte-mit-gitlab“)\n\n### Was sind CI/CD-Variablen?\n\nCI/CD-Variablen sind dynamische Schlüssel-Wert-Paare, die du auf verschiedenen Ebenen in deiner GitLab-Umgebung definieren kannst (z. B. Projekt, Gruppe oder Instanz). Diese Variablen fungieren als Platzhalter für Werte, die du in deiner `.gitlab-ci.yml`-Datei verwenden kannst, um deine Pipelines anzupassen, vertrauliche Informationen sicher zu speichern und deine CI/CD-Konfiguration besser zu pflegen.\n\n### Warum sind CI/CD-Variablen wichtig?\n\nCI/CD-Variablen bieten zahlreiche Vorteile:\n\n* **Flexibilität** – Du kannst deine Pipelines leicht an verschiedene Umgebungen, Konfigurationen oder Bereitstellungsziele anpassen, ohne dein zentrales CI/CD-Skript zu ändern. \n* **Sicherheit** – Speichere vertrauliche Informationen wie API-Schlüssel, Passwörter und Token sicher und verhindere so, dass sie in deinem Code offengelegt werden.  \n* **Wartbarkeit** – Verwalte deine CI/CD-Konfiguration sauber und übersichtlich, indem du Werte in Variablen zentralisierst, was Aktualisierungen und Änderungen erleichtert. \n* **Wiederverwendbarkeit** – Definiere Variablen einmal und verwende sie in mehreren Projekten wieder, um die Konsistenz zu fördern und doppelte Arbeit zu vermeiden.\n\n### Geltungsbereiche von CI/CD-Variablen: Projekt, Gruppe und Instanz\n\nMit GitLab kannst du CI/CD-Variablen mit unterschiedlichen Geltungsbereichen definieren und so ihre Sichtbarkeit und Zugänglichkeit steuern:\n\n* **Variablen auf Projektebene** – Diese Variablen sind spezifisch für ein einzelnes Projekt und eignen sich ideal zum Speichern von projektspezifischen Einstellungen, wie zum Beispiel:\n  * Bereitstellungs-URLs: Definiere unterschiedliche URLs für Staging- und Produktivumgebungen. \n  * Datenbank-Zugangsdaten: Speichere Details zur Datenbankverbindung für Tests oder die Bereitstellung.  \n  * Feature-Flags: Aktiviere oder deaktiviere Funktionen in verschiedenen Phasen deiner Pipeline.  \n  * Beispiel: Du hast ein Projekt mit dem Namen „MyWebApp“ und möchtest die URL für die Bereitstellung speichern. Du erstellst eine Variable auf Projektebene mit dem Namen `DPROD_DEPLOY_URL` und dem Wert `https://mywebapp.com`.  \n* **Variablen auf Gruppenebene** – Diese Variablen werden von allen Projekten innerhalb einer GitLab-Gruppe gemeinsam genutzt. Sie sind nützlich für Einstellungen, die für mehrere Projekte gleich sind, wie z. B.:\n\n  * API-Schlüssel für gemeinsam genutzte Dienste: Speichere API-Schlüssel für Dienste wie AWS, Google Cloud oder Docker Hub, die von mehreren Projekten innerhalb der Gruppe genutzt werden.  \n  * Globale Konfigurationseinstellungen: Lege gemeinsame Konfigurationsparameter fest, die für alle Projekte in der Gruppe gelten.  \n  * Beispiel: Du hast eine Gruppe mit dem Namen „Web-Apps“ und möchtest einen API-Schlüssel für Docker Hub speichern. Du erstellst eine Variable auf Gruppenebene mit dem Namen `DOCKER_HUB_API_KEY` und dem entsprechenden API-Schlüsselwert.  \n* **Variablen auf Instanzebene** – Diese Variablen sind für alle Projekte auf einer GitLab-Instanz verfügbar. Sie werden in der Regel für globale Einstellungen verwendet, die für das gesamte Unternehmen gelten, wie z. B.:\n\n  * Standard-Token für die Registrierung von Runnern: Lege ein Standard-Token für die Registrierung neuer [Runner (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/) fest.  \n  * Lizenzinformationen: Hier kannst du Lizenzschlüssel für GitLab-Funktionen oder Tools von Drittanbietern speichern.  \n  * Globale Umgebungseinstellungen: Lege Umgebungsvariablen fest, die für alle Projekte verfügbar sein sollen.  \n  * Beispiel: Du möchtest ein Standard-Docker-Image für alle Projekte in deiner GitLab-Instanz festlegen. Du erstellst eine Variable auf Instanzebene mit dem Namen `DEFAULT_DOCKER_IMAGE` und dem Wert `ubuntu:latest`.\n\n### Definieren von CI/CD-Variablen\n\nSo definierst du eine CI/CD-Variable:\n\n1. Klicke auf die Schaltflächen **Einstellungen > CI/CD** für dein Projekt, deine Gruppe oder deine Instanz.  \n2. Gehe zum Abschnitt **Variablen**.  \n3. Klicke auf **Variable hinzufügen**.  \n4. Gib den **Schlüssel** (z. B. `API_KEY`) und den **Wert** ein.  \n5. Aktiviere optional das Kontrollkästchen **Variable schützen**, wenn es sich um vertrauliche Informationen handelt. Dadurch wird sichergestellt, dass die Variable nur für Pipelines verfügbar ist, die auf geschützten Branches oder Tags ausgeführt werden.  \n6. Aktiviere optional das Kontrollkästchen **Variable maskieren**, um den Wert der Variable in den Job-Protokollen auszublenden und eine versehentliche Offenlegung zu verhindern.  \n7. Klicke auf **Variable speichern**.\n\n### Verwenden von CI/CD-Variablen\n\nUm eine CI/CD-Variable in deiner `.gitlab-ci.yml`-Datei zu verwenden, stellst du dem Variablennamen einfach `$` voran:\n\n```yaml\ndeploy_job:\n  script:\n    - echo \"Deploying to production...\"\n    - curl -H \"Authorization: Bearer $API_KEY\" https://api.example.com/deploy\n```\n\n### Vordefinierte CI/CD-Variablen\n\nGitLab stellt [vordefinierte CI/CD-Variablen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/variables/predefined_variables/) bereit, die du in deinen Pipelines verwenden kannst. Diese Variablen liefern Informationen über die aktuelle Pipeline, den Job, das Projekt und mehr.\n\nEinige häufig verwendete vordefinierte Variablen sind:\n\n* `$CI_COMMIT_SHA`: Der Commit-SHA der aktuellen Pipeline.  \n* `$CI_PROJECT_DIR`: Das Verzeichnis, in dem das Projekt geklont wird.  \n* `$CI_PIPELINE_ID`: Die ID der aktuellen Pipeline.  \n*`$CI_ENVIRONMENT_NAME`: Der Name der Umgebung, in der bereitgestellt wird (falls zutreffend).\n\n### Bewährte Methoden\n\n* Verwalte vertrauliche Variablen sicher: Verwende geschützte und maskierte Variablen für API-Schlüssel, Passwörter und andere vertrauliche Informationen. \n* Vermeide das Hardcoding von Werten: Verwende Variablen zum Speichern von Konfigurationswerten, um deine Pipelines flexibler und wartbarer zu machen.  \n* Organisiere deine Variablen: Verwende aussagekräftige Namen und gruppiere verwandte Variablen, um sie besser zu organisieren.  \n* Verwende den richtigen Geltungsbereich: Wähle den richtigen Geltungsbereich (Projekt, Gruppe oder Instanz) für deine Variablen aus, je nach Verwendungszweck und Sichtbarkeit.\n\n### Entdecke die Leistungsfähigkeit von Variablen\n\nCI/CD-Variablen sind ein leistungsstarkes Tool zur Anpassung und Sicherung deiner GitLab-Pipelines. Wenn du verstanden hast, wie Variablen funktionieren und ihre unterschiedlichen Geltungsbereiche kennst, kannst du flexiblere, wartbarere und effizientere Workflows erstellen.\n\nWir hoffen, dass diese Informationen für dich hilfreich waren und du jetzt gut gerüstet bist, um die Möglichkeiten von GitLab für deine Entwicklungsprojekte zu nutzen.\n\n> Lege jetzt los mit CI/CD-Variablen mit einer [kostenlosen, 60-tägigen Testversion von GitLab Ultimate mit Duo Enterprise](https://about.gitlab.com/de-de/free-trial/).\n\n## Reihe „Erste Schritte mit GitLab“\nLies weitere Artikel in unserer Serie „Erste Schritte mit GitLab“:\n\n- [Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Projekte in GitLab importieren (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Projektmanagement](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automatisiere Agile-Workflows mit dem gem gitlab-triage](https://about.gitlab.com/de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Grundlegendes zu CI/CD](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-understanding-ci-cd/)\n",[14,678,748,749,110,750],"CI","CD","features","2025-06-10",{"slug":753,"featured":92,"template":681},"getting-started-with-gitlab-working-with-ci-cd-variables","content:de-de:blog:getting-started-with-gitlab-working-with-ci-cd-variables.yml","Getting Started With Gitlab Working With Ci Cd Variables","de-de/blog/getting-started-with-gitlab-working-with-ci-cd-variables.yml","de-de/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"_path":759,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":760,"content":766,"config":774,"_id":776,"_type":16,"title":777,"_source":18,"_file":778,"_stem":779,"_extension":21},"/de-de/blog/gitlab-premium-with-duo",{"title":761,"description":762,"ogTitle":761,"ogDescription":762,"noIndex":6,"ogImage":763,"ogUrl":764,"ogSiteName":716,"ogType":717,"canonicalUrls":764,"schema":765},"Künstliche Intelligenz für alle Kund(inn)en von GitLab Premium und Ultimate","GitLab Premium und Ultimate umfassen jetzt GitLab Duo für die Erstellung und das Verständnis von Code während des gesamten Lebenszyklus der Softwareentwicklung – und das ohne zusätzliche Kosten.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660188/Blog/Hero%20Images/blog-premium-with-duo-cover-0756-fy26-v2-1800x945.png","https://about.gitlab.com/blog/gitlab-premium-with-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Künstliche Intelligenz für alle Kund(inn)en von GitLab Premium und Ultimate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2025-05-15\",\n      }\n                  ",{"title":761,"description":762,"authors":767,"heroImage":763,"date":769,"body":770,"category":14,"tags":771,"updatedDate":773},[768],"David DeSanto, Chief Product Officer, GitLab","2025-05-15","Heute präsentieren wir GitLab 18.0, das unsere neuesten Innovationen und Pläne in den Bereichen DevSecOps-Workflows, Sicherheit und Compliance sowie KI in den Vordergrund stellt.\n\n**Ab dieser Version enthalten GitLab Premium und Ultimate jetzt auch die grundlegenden KI-Funktionen von GitLab Duo – und das ohne zusätzliche Kosten.**\n\nAlle Kund(inn)en mit Premium- und Ultimate-Lizenz erhalten sofort Zugang zu GitLab Duo Codevorschläge und Duo Chat direkt in ihren bevorzugten unterstützten Quellcode-Editoren und IDEs.\n\n## KI für jedes Entwicklungsteam\n\nKünstliche Intelligenz steht jetzt im Mittelpunkt der Entwicklererfahrung. KI verbessert die Programmierung in vielerlei Hinsicht: Sie analysiert deine Codebase und liefert dir während der Eingabe Vorschläge in Echtzeit, erstellt Funktionen und Methoden basierend auf dem Kontext deines Projekts, reduziert sich wiederholende Aufgaben und automatisiert Code Reviews.\n\nIn den letzten Jahren haben wir [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) entwickelt, um generative und agentische KI-Funktionen wie diese in unsere Plattform einzubauen. Da das Schreiben von Code nur der Anfang des Software-Lebenszyklus ist – unsere [globale DevSecOps-Studie](https://about.gitlab.com/de-de/developer-survey/) hat ergeben, dass Entwickler(innen) 79 % ihrer Zeit mit anderen Aufgaben als der Code-Erstellung verbringen – haben wir eine Strategie entwickelt, um KI in den gesamten Lebenszyklus der Softwareentwicklung zu integrieren. \n\nJetzt freuen wir uns, den nächsten Schritt nach vorne zu machen, indem wir wesentliche Funktionen von GitLab Duo in unsere GitLab-Premium- und Ultimate-Tarife aufnehmen, damit Entwickler(innen) die Vorteile von KI **ohne zusätzliche Kosten** in Anspruch nehmen können.\n\nDurch die Aufnahme von GitLab Duo Chat und Duo Codevorschläge in Premium und Ultimate können alle Softwareentwickler(innen) ihre Workflows innerhalb der IDE beschleunigen – ohne dass sie separate Tools, Lizenzen oder Governance benötigen. Alle bestehenden Kund(inn)en mit Premium- und Ultimate-Lizenz haben sofortigen Zugriff auf Duo Chat und Codevorschläge, sobald sie auf GitLab 18.0 upgraden, und diese Erweiterung wird zum Standard für alle Neukund(inn)en.\n\n> **„GitLab hat bereits dazu beigetragen, dass wir nicht mehr auf eine fragmentierte Toolchain angewiesen sind, was die Kosten für unzusammenhängende Lösungen gesenkt und unseren Workflow optimiert hat. Die Erweiterung von GitLab Premium mit Duo wird unsere Effizienz und Kosteneinsparungen noch weiter steigern, da unsere Entwickler(innen) weniger Zeit für routinemäßige Programmieraufgaben aufwenden müssen und mehr Zeit für die Bewältigung komplexer Herausforderungen haben, die einen echten geschäftlichen Nutzen bringen.“**\n>\n>- Andrei Nita, Chief Technology Officer bei McKenzie Intelligence Services\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Premium with Duo Core\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cbr>\u003C/br>\nKund(inn)en mit Premium- und Ultimate-Lizenz haben jetzt Zugriff auf die folgenden KI-basierten Funktionen:\n\n#### GitLab Duo Codevorschläge\n\n* Generierung vollständiger Funktionen und Codeblöcke aus Kommentaren  \n* Erhalten intelligenter Code-Vervollständigung während der Eingabe  \n* Unterstützung für mehr als 20 Programmiersprachen  \n* Verfügbar in den meisten gängigen IDEs\n\nIn dieser interaktiven Tour erfährst du mehr über GitLab Duo Codevorschläge (klicke auf das Bild, um die Tour zu starten).\n\n\u003Ca href=\"https://gitlab.navattic.com/code-suggestions\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175911/Blog/b5gdnls7jdyrpeyjby5j.png\" alt=\"GitLab Duo Code Suggestions cover image\">\u003C/a>\n\nWeitere Informationen findest du in unserer [Dokumentation zu Duo Codevorschläge (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/repository/code_suggestions/).\n\n#### GitLab Duo Chat\n\n* Erklärung von unbekanntem Code, um komplexe Funktionen zu verstehen  \n* Refaktorierung von vorhandenem Code, um Qualität und Wartbarkeit zu verbessern  \n* Generierung umfassender Testfälle, um Bugs früher zu erkennen  \n* Behebung von Codeproblemen direkt in deinem Workflow\n\n![Duo Chat – Erklärung des API-Endpunkts](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Duo_Chat_-_gif_-_API_endpoint_explanation__3_.gif)\n\nWeitere Informationen findest du in unserer [Dokumentation zu Duo Chat (nur in englischer Sprache vefügbar)](https://docs.gitlab.com/user/gitlab_duo_chat/).\n\n> **„Für uns als GitLab-Benutzer(innen) sind die intelligenten Codevorschläge von Duo zu einer täglichen Ressource für unsere Entwickler(innen) geworden. In Kombination mit der Chat-Funktion ermöglicht sie sofortiges Feedback und Iteration, was zu schnelleren Entwicklungszyklen und einer sichereren Codebase führt. Es ist eine nahtlose und leistungsstarke Ergänzung zu unseren Workflows.“**\n>\n>- Felix Kortmann, Chief Technology Officer, Ignite by FORVIA HELLA\n\n## Duo Enterprise jetzt für Kund(inn)en von GitLab Premium verfügbar\n\nAuf vielfachen Wunsch unserer Kund(inn)en könnt ihr jetzt auch mit [GitLab Premium](https://about.gitlab.com/de-de/pricing/premium/) Duo Enterprise, unsere komplette KI-Suite, erwerben, ohne auf GitLab Ultimate upgraden zu müssen. Premium-Kund(inn)en kommen in den Genuss eines umfassenden KI-Erlebnisses, das nahtlos in den gesamten Lebenszyklus der Softwareentwicklung integriert ist. Dazu gehören spannende GitLab Duo-Funktionen wie:\n\n* [Root Cause Analysis (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases) hilft bei der schnellen Behebung von CI/CD-Pipeline-Fehlern und sorgt dafür, dass deine CI/CD-Pipelines stabil bleiben.\n* [Code Review (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) ermöglicht eine schnellere Merge-Request-Review, indem Duo als Code-Prüfer genutzt wird.  \n* [Erweiterter Chat (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/gitlab_duo_chat/) fasst Unterhaltungen zusammen, hilft beim Verständnis von Codeänderungen und bietet erweiterte Konfigurationsunterstützung.  \n* [Self-Hosted (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/) ermöglicht den Einsatz von Duo in Air-Gapped- und Offline-Umgebungen, indem genehmigte KI-Modelle für Duo gehostet werden.\n\nNeben der Verfügbarkeit von Duo Enterprise investieren wir weiterhin in den Erfolg unserer GitLab-Premium-Kund(inn)en. Seit der Einführung von GitLab 17 [haben wir mehr als hundert Funktionen und Verbesserungen bereitgestellt](https://gitlab.com/gitlab-org/gitlab/-/releases), darunter: \n\n* Der [**CI/CD-Katalog** (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) ermöglicht es Entwickler(inne)n, bereits vorhandene CI/CD-Komponenten und -Konfigurationen zu teilen, zu entdecken und wiederzuverwenden.  \n\n* Die [**Artefaktregistrierung** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/virtual_registry/) bietet Entwickler(inne)n sicheren Zugriff auf Artefakte und eine nahtlose Integration in CI/CD-Pipelines.  \n* [**Remote-Entwicklung** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/remote_development/) ermöglicht es Entwickler(inne)n, in bedarfsgerechten,  \nCloud-basierten Entwicklungsumgebungen zu arbeiten.\n\n> [Erfahre mehr über die Funktionen von GitLab Premium (nur in englischer Sprache verfügbar).](https://about.gitlab.com/pricing/premium/#wp-premium-features)\n\n## GitLab Duo: KI, die Unternehmen dort unterstützt, wo sie arbeiten\n\nGitLab-Kund(inn)en haben Zugriff auf eine umfassende Auswahl an Duo-Angeboten, die in unseren Pro- und Enterprise-Lösungen enthalten sind. So können sie genau dort eingesetzt werden, wo du dich im KI-Einführungszyklus befindest. Je weiter deine Teams fortgeschritten sind, desto mehr Funktionen kannst du nutzen, um sichere Software schneller zu entwickeln, zu testen und bereitzustellen.\n\n![Hauptfunktionen in GitLab-Duo-Tarifen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Screenshot_2025-05-14_at_8.50.34_AM.png)\n\n## Wie bestehende Kund(inn)en von GitLab Ultimate und Premium in GitLab Duo einsteigen können\n\nAb GitLab 18.0 sind die Funktionen Duo Codevorschläge und Duo Chat für bestehende Kund(inn)en von GitLab Ultimate und Premium standardmäßig deaktiviert. Du kannst sie aber ganz einfach aktivieren – wie, erfährst du weiter unten.\n\nSo nutzt du GitLab Premium und Ultimate mit Duo: \n\n1. Stelle sicher, dass du GitLab Premium oder Ultimate hast. Wenn nicht, kannst du es 60 Tage lang kostenlos testen. \n\n2. Aktiviere GitLab Duo in deinen Organisationseinstellungen.\n\n3. Wenn du eine lokale IDE verwendest, installiere die entsprechende [Editor-Erweiterung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/editor_extensions/#available-extensions) für GitLab. \n\n4. Verwende Codevorschläge und Duo Chat in deiner bevorzugten unterstützten lokalen IDE oder der GitLab Web IDE.\n\n**Hinweis:** Für Neukund(inn)en und Testversionen werden die KI-Funktionen von GitLab automatisch aktiviert.\n\n## KI-native Entwicklung erfordert eine DevSecOps-Plattform\n\nKI verändert die Arbeit der Entwickler(innen) grundlegend. In Unternehmen wird es nicht nur mehr Mitarbeitende geben, die Software entwickeln. Es wird auch mehr produktionsreifen Code geben, der von KI generiert wird – **was GitLab wichtiger denn je macht.** \n\nWir haben GitLab Premium und Ultimate mit Duo speziell für diese neue Realität entwickelt, damit Teams eine sichere Grundlage für ihren gesamten Code haben. Wenn KI in deinem Unternehmen Code generiert, wird GitLab zu deinem Kontrollzentrum: keine separaten Tools für Sicherheitsscans, Compliance-Checks oder die Verwaltung von Pipelines. Es reicht eine einzige, einheitliche Plattform, die mit deinem Unternehmen wächst und sicherstellt, dass der gesamte Code deinen Standards entspricht, bevor er in die Produktion gelangt. Während KI deine Entwicklung beschleunigt, kannst du mit GitLab die Kontrolle, Sicherheit und Qualität von Anfang bis Ende gewährleisten.\n\n> Wenn du mehr über GitLab Duo und die Möglichkeiten erfahren möchtest, wie es die Arbeit deines Teams verändern kann, [besuche unsere GitLab-Premium-Seite](https://about.gitlab.com/de-de/pricing/premium/). Wenn du bereits Kund(in) von GitLab bist, wende dich an deine(n) Ansprechpartner(in) bei GitLab, um eine Demo zu planen. Komm am 24. Juni 2025 zu unserem [virtuellen Launch-Event für GitLab 18 (nur in englischer Sprache verfügbar)](https://about.gitlab.com/eighteen/), um mehr über die Zukunft der KI-nativen Softwareentwicklung zu erfahren.\n",[772,727,726,750,14],"AI/ML","2025-05-20",{"slug":775,"featured":92,"template":681},"gitlab-premium-with-duo","content:de-de:blog:gitlab-premium-with-duo.yml","Gitlab Premium With Duo","de-de/blog/gitlab-premium-with-duo.yml","de-de/blog/gitlab-premium-with-duo",{"_path":781,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":782,"content":787,"config":793,"_id":795,"_type":16,"title":796,"_source":18,"_file":797,"_stem":798,"_extension":21},"/de-de/blog/getting-started-with-gitlab-understanding-ci-cd",{"title":783,"description":784,"ogTitle":783,"ogDescription":784,"noIndex":6,"ogImage":739,"ogUrl":785,"ogSiteName":716,"ogType":717,"canonicalUrls":785,"schema":786},"Erste Schritte mit GitLab: Grundlegendes zu CI/CD","In diesem Leitfaden für Einsteiger(innen) lernst du die Grundlagen der kontinuierlichen Integration und kontinuierlichen Lieferung kennen. Du erfährst, was CI/CD-Komponenten sind und wie du sie erstellst.","https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab: Grundlegendes zu CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-25\",\n      }",{"title":783,"description":784,"authors":788,"heroImage":739,"date":790,"body":791,"category":14,"tags":792,"updatedDate":723},[789],"GitLab","2025-04-25","Stell dir einen Workflow vor, bei dem jede Codeänderung automatisch erstellt, getestet und für deine Benutzer(innen) bereitgestellt wird. Genau das macht [CI/CD (Kontinuierliche Integration/Kontinuierliche Lieferung)](https://about.gitlab.com/de-de/topics/ci-cd/)! Mit CI/CD kannst du Fehler frühzeitig erkennen, die Qualität des Codes sicherstellen und Software schneller und häufiger bereitstellen.\n\n## Inhaltsverzeichnis\n\n- [Was ist CI/CD?](#was-ist-cicd%3F)\n- [Vorteile von GitLab CI/CD](#vorteile-von-gitlab-cicd)\n- [Die Elemente von GitLab CI/CD](#die-elemente-von-gitlab-cicd)\n- [GitLab CI einrichten](#gitlab-ci-einrichten)\n- [Beispiele für die CI/CD-Konfiguration](#beispiele-für-die-cicd-konfiguration)\n- [GitLab Auto-DevOps](#gitlab-auto-devops)\n- [CI/CD-Katalog](#cicd-katalog)\n- [CI-Vorlagen](#ci-vorlagen)\n- [Entwicklung der nächsten Generation](#entwicklung-der-nächsten-generation)\n- [Reihe „Erste Schritte mit GitLab\"](#reihe-„erste-schritte-mit-gitlab“)\n\n### Was ist CI/CD?\n\n* **Kontinuierliche Integration** ist eine Entwicklungsmethode, bei der Entwickler(innen) häufig, nach Möglichkeit mehrmals am Tag, Codeänderungen in ein gemeinsames Repository integrieren. Jede Integration wird dann durch einen automatisierten Build- und Testprozess überprüft, so dass die Teams Probleme frühzeitig erkennen können.  \n* **Kontinuierliche Lieferung** erweitert CI, indem sie die Bereitstellungspipeline automatisiert und dafür sorgt, dass dein Code *immer* in einem einsatzfähigen Zustand ist. Du kannst deine Anwendung mit einem einzigen Klick oder automatisch in verschiedenen Umgebungen (z. B. Staging, Produktion) bereitstellen.  \n* **Kontinuierliche Bereitstellung** geht noch einen Schritt weiter, indem sie *jeden erfolgreichen Build* automatisch für die Produktion bereitstellt. Dies erfordert ein hohes Maß an Vertrauen in deine automatisierten Tests und deinen Bereitstellungsprozess.\n\n### Vorteile von GitLab CI/CD\n\nGitLab CI/CD ist ein leistungsstarkes, eingegliedertes System, das in GitLab integriert ist. Es bietet ein nahtloses Erlebnis für die Automatisierung deines gesamten Software-Entwicklungsprozesses. Mit GitLab CI/CD kannst du:\n\n* **Alles automatisieren:** Erstelle, teste und stelle deine Anwendungen mit Leichtigkeit bereit.  \n* **Bugs frühzeitig erkennen:** Erkenne und behebe Fehler, bevor sie die Produktion erreichen.  \n* **Schnelleres Feedback erhalten:** Du erhältst sofortige Rückmeldung zu deinen Code-Änderungen.  \n* **Die Zusammenarbeit verbessern:** Arbeite mit automatisierten Workflows effektiver im Team zusammen.  \n* **Die Bereitstellung beschleunigen:** Veröffentliche Software schneller und häufiger.  \n* **Risiken reduzieren:** Minimiere Fehler bei der Bereitstellung und vermeide Rollbacks.\n\n### Die Elemente von GitLab CI/CD\n\n* `.gitlab-ci.yml`**:** Diese [YAML-Datei (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/), die sich im Stammverzeichnis deines Projekts befindet, definiert deine CI/CD-Pipeline, einschließlich Phasen, Jobs und Runner.  \n* [**GitLab Runner** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/)**:** Dieser Agent führt deine CI/CD-Jobs auf deiner Infrastruktur aus (z. B. auf physischen Computern, virtuellen Maschinen, Docker-Containern oder Kubernetes-Clustern).  \n* [**Phasen** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/#stages)**:** Phasen definieren die Reihenfolge der Ausführung deiner Jobs (z. B. Erstellen, Testen und Bereitstellen).  \n* [**Jobs** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/#job-keywords)**:** Jobs sind einzelne Arbeitseinheiten innerhalb einer Phase (z. B. Code kompilieren, Tests ausführen und für das Staging bereitstellen).\n\n### GitLab CI einrichten\n\nDie ersten Schritte mit GitLab CI sind einfach. Hier ist ein einfaches Beispiel für eine `.gitlab-ci.yml`-Datei:\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the application...\"\n\ntest_job:\n  stage: test\n  script:\n    - echo \"Running tests...\"\n\ndeploy_job:\n  stage: deploy\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n\n```\n\nDiese Konfiguration definiert drei Phasen: „build“, „test“ und „deploy“. Jede Phase enthält einen Job, der ein einfaches Skript ausführt.\n\n### Beispiele für die CI/CD-Konfiguration\n\nSehen wir uns einige realistischere Beispiele an.\n\n**Erstellen und Bereitstellen einer Node.js-Anwendung**\n\nDie folgende Pipelinedefinition beschreibt die Verwendung von npm, um eine Node.js-Anwendung zu erstellen und zu testen, und [dpl (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/examples/deployment/), um die Anwendung in Heroku bereitzustellen. In der Bereitstellungsphase der Pipeline werden die [GitLab-CI/CD-Variablen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/variables/) verwendet, mit denen Entwickler(innen) vertrauliche Informationen (z. B. Zugangsdaten) speichern und sicher in CI/CD-Prozessen verwenden können. In diesem Beispiel wird ein API-Schlüssel für die Bereitstellung in Heroku unter dem variablen Schlüsselnamen '$HEROKU_API_KEY` gespeichert, den das dpl-Tool verwendet.\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild:\n  stage: build\n  image: node:latest\n  script:\n    - npm install\n    - npm run build\n\ntest:\n  stage: test\n  image: node:latest\n  script:\n    - npm run test\n\ndeploy:\n  stage: deploy\n  image: ruby:latest\n  script:\n    - gem install dpl\n    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY\n\n```\n\n**Bereitstellung in verschiedenen Umgebungen (Staging und Produktivumgebung)**\n\nGitLab bietet auch [Umgebungen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/environments/) mit CI/CD. Mit dieser Funktion können Benutzer(innen) die Bereitstellung von CI/CD auf Infrastrukturziele verfolgen. Im folgenden Beispiel fügt die Pipeline Phasen mit einer Umgebungseigenschaft für eine Staging- und eine Produktivumgebung hinzu. Während die Phase „deploy_staging“ ihr Skript immer ausführt, erfordert die Phase „deploy_production“ eine manuelle Genehmigung, um eine versehentliche Bereitstellung in der Produktionsumgebung zu verhindern.\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy_staging\n  - deploy_production\n\nbuild:\n  # ...\n\ntest:\n  # ...\n\ndeploy_staging:\n  stage: deploy_staging\n  script:\n    - echo \"Deploying to staging...\"\n  environment:\n    name: staging\n\ndeploy_production:\n  stage: deploy_production\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n  when: manual  # Requires manual approval\n\n```\n\n### GitLab Auto-DevOps\n\n[GitLab Auto-DevOps (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/topics/autodevops/) vereinfacht CI/CD, indem es eine vordefinierte Konfiguration bereitstellt, mit der deine Anwendungen automatisch erstellt, getestet und bereitgestellt werden. Es nutzt bewährte Methoden und Branchenstandards, um deinen Workflow zu optimieren.\n\nSo aktivierst du Auto-DevOps:\n\n1. Gehe in deinem Projekt zu **Einstellungen > CI/CD > Allgemeine Pipelines**.  \n2. Aktiviere die Option **Auto-DevOps**.\n\nAuto-DevOps erkennt automatisch die Sprache und das Framework deines Projekts und konfiguriert die erforderlichen Build-, Test- und Bereitstellungsphasen. Du musst nicht einmal eine `.gitlab-ci.yml`-Datei erstellen.\n\n### CI/CD-Katalog\n\nDer [CI/CD-Katalog (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) ist eine Liste von Projekten mit veröffentlichten [CI/CD-Komponenten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/components/), die du zur Erweiterung deines CI/CD-Workflows nutzen kannst. Jeder kann ein Komponentenprojekt erstellen und es zum CI/CD-Katalog hinzufügen oder zu einem bestehenden Projekt beitragen, um die verfügbaren Komponenten zu verbessern. Die veröffentlichten Komponenten findest du im [CI/CD-Katalog](https://gitlab.com/explore/catalog) auf GitLab.com.\n\n> [Tutorial: So richtest du deine erste GitLab-CI/CD-Komponente ein (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n\n### CI-Vorlagen\n\nDu kannst auch deine eigenen [CI-Vorlagen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/examples/) erstellen, um CI/CD-Konfigurationen zu standardisieren und über mehrere Projekte hinweg wiederzuverwenden. Das fördert die Konsistenz und reduziert doppelte Arbeit.\n\nSo erstellst du eine CI-Vorlage:\n\n1. Erstelle eine `.gitlab-ci.yml`-Datei in einem eigenen Projekt oder Repository.  \n2. Definiere deine CI/CD-Konfiguration in der Vorlage. \n3. Verwende in der `.gitlab-ci.yml`-Datei deines Projekts das Schlüsselwort `include`, um die Vorlage einzuschließen.\n\n## Entwicklung der nächsten Generation\n\nGitLab CI/CD ist ein leistungsstarkes Tool, das deinen Workflow bei der Entwicklung verbessern kann. Wenn du die Konzepte von CI/CD verstehst, deine Pipelines konfigurierst und Funktionen wie Auto-DevOps, den CI/CD-Katalog und CI-Vorlagen nutzt, kannst du deinen gesamten Software-Entwicklungsprozess automatisieren und schneller und effizienter hochwertige Software liefern.\n\n> Willst du dein Wissen vertiefen? Registriere dich für die [englischsprachigen Kurse der GitLab University](https://university.gitlab.com/). Du kannst auch sofort mit der [kostenlosen 60-tägigen Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/?hosted=saas) loslegen.\n\n## Reihe „Erste Schritte mit GitLab“\n\nWeitere Artikel in unserer Serie „Erste Schritte mit GitLab“:\n\n- [Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Projekte in GitLab importieren (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Projektmanagement](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automatisiere Agile-Workflows mit dem gem gitlab-triage](https://about.gitlab.com/de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n",[110,748,749,727,14,678],{"slug":794,"featured":92,"template":681},"getting-started-with-gitlab-understanding-ci-cd","content:de-de:blog:getting-started-with-gitlab-understanding-ci-cd.yml","Getting Started With Gitlab Understanding Ci Cd","de-de/blog/getting-started-with-gitlab-understanding-ci-cd.yml","de-de/blog/getting-started-with-gitlab-understanding-ci-cd",{"_path":800,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":801,"content":807,"config":818,"_id":820,"_type":16,"title":821,"_source":18,"_file":822,"_stem":823,"_extension":21},"/de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"ogTitle":802,"schema":803,"ogImage":804,"ogDescription":805,"ogSiteName":716,"noIndex":6,"ogType":717,"ogUrl":806,"title":802,"canonicalUrls":806,"description":805},"GitLab 18.0: Migration Guide für Breaking Changes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Die Breaking Changes in GitLab 18.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Martin Brümmer\"},{\"@type\":\"Person\",\"name\":\"Fabian Zimmer\"},{\"@type\":\"Person\",\"name\":\"Sam Wiskow\"}],\n        \"datePublished\": \"2025-04-18\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","GitLab 18.0 Breaking Changes: Analysiere Auswirkungen auf deine Projekte. Dokumentation mit allen Maßnahmen für einen sicheren Upgrade-Prozess.","https://about.gitlab.com/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"heroImage":804,"body":808,"authors":809,"updatedDate":813,"date":814,"title":815,"tags":816,"description":817,"category":14},"GitLab 18.0, unser nächstes Major Release, wird vollgepackt sein mit neuen Funktionen, die die Grenzen der DevSecOps-Innovation sprengen. Gleichzeitig werden wir einige veraltete Funktionen aus GitLab entfernen. Hier erfährst du, was du über diese Änderungen wissen musst und wie du ihre Auswirkungen minimieren kannst.\n\n## Inhaltsverzeichnis\n- [Bereitstellungsfenster](#bereitstellungsfenster)\n - [GitLab.com](#gitlabcom)\n - [GitLab Self-Managed](#gitlab-self-managed)\n - [GitLab Dedicated](#gitlab-dedicated)\n- [Breaking Changes](#breaking-changes)\n - [Hohe Auswirkungen](#hohe-auswirkungen)\n - [Mittlere Auswirkungen](#mittlere-auswirkungen)\n - [Geringe Auswirkungen](#geringe-auswirkungen)\n- [Tools und Ressourcen, um deine Auswirkungen zu verwalten](#tools-und-ressourcen-um-deine-auswirkungen-zu-verwalten)\n\n## Bereitstellungsfenster\n\n### GitLab.com  \n\nBreaking Changes für GitLab.com waren auf diese drei Zeitfenster beschränkt: \n\n- 21.–23. April 2025  \n- 28.–30. April 2025  \n- 5.–7. Mai 2025\n\nViele weitere Änderungen werden im Laufe des Monats eingeführt. In dieser [englischsprachigen Dokumentation zu den grundlegenden Änderungen](https://docs.gitlab.com/update/breaking_windows/) erfährst du mehr über die wichtigsten Änderungen in jedem dieser Zeitfenster.\n\n***Hinweis:** In Ausnahmefällen können Breaking Changes geringfügig außerhalb dieser Zeitfenster liegen.* \n\n### GitLab Self-Managed\n\nGitLab 18.0 ist ab dem 15. Mai verfügbar. Mehr über den Release-Zeitplan erfährst du [hier (nur in englischer Sprache verfügbar)](https://about.gitlab.com/releases/).\n\n### GitLab Dedicated\n\nDas Upgrade auf GitLab 18.0 findet während deines Wartungsfensters vom 24.–29. Juni 2025 statt. Mehr dazu erfährst du [hier (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/dedicated/maintenance/#release-rollout-schedule). Dort findest du auch dein zugewiesenes Wartungsfenster.\n\nWir haben außerdem spezielle Tools und Ressourcen entwickelt, die dir dabei helfen, die Auswirkungen der Änderungen auf deine Umgebung abzuschätzen und alle notwendigen Maßnahmen vor dem Upgrade auf 18.0 zu planen. [Informationen zu diesen Tools und Ressourcen zur Risikominderung](#tools-and-resources-to-manage-your-impact) findest du weiter unten in diesem Artikel.\n\nAuf der [Seite zu veralteten Funktionen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=18.0), findest du eine vollständige Liste der Komponenten, die in 18.0 entfernt werden sollen. Im Folgenden erfährst du, was auf dich zukommt und wie du dich auf die diesjährige Version vorbereiten kannst, je nachdem, welche Bereitstellung du verwendest.\n\n## Breaking Changes\n\n### Hohe Auswirkungen\n\n**1. CI/CD-Job-Token – Entfernung der Einstellung „Zugriff von deinem Projekt beschränken“**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 14.4 haben wir eine Einstellung eingeführt, um **[den Zugriff *von* den CI/CD-Job-Token (CI_JOB_TOKEN) deines Projekts zu beschränken (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access)** und so die Sicherheit zu erhöhen. Diese Einstellung wurde **CI_JOB_TOKEN-Zugriff beschränken** genannt. In GitLab 16.3 haben wir diese Einstellung aus Gründen der Übersichtlichkeit in **Zugriff *von* diesem Projekt beschränken** umbenannt.\n\nIn GitLab 15.9 haben wir die alternative Einstellung **[Autorisierte Gruppen und Projekte (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-group-or-project-to-the-job-token-allowlist)** eingeführt. Diese Einstellung steuert den Zugriff von Job-Token auf dein Projekt mithilfe einer Zulassungsliste. Diese neue Einstellung ist eine deutliche Verbesserung gegenüber der ursprünglichen Einstellung. Die erste Iteration wurde in GitLab 16.0 als veraltet markiert und soll in GitLab 18.0 entfernt werden.\n\nDie Einstellung **Zugriff *von* diesem Projekt beschränken** ist für alle neuen Projekte standardmäßig deaktiviert. Ab GitLab 16.0 kannst du diese Einstellung nicht wieder aktivieren, nachdem sie in einem Projekt deaktiviert wurde. Verwende stattdessen die Einstellung **Autorisierte Gruppen und Projekte**, um den Zugriff von Job-Token auf deine Projekte zu steuern.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)]( https://docs.gitlab.com/update/deprecations/#cicd-job-token---limit-access-from-your-project-setting-removal)\n- [Überprüfung über GitLab Detective verfügbar](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**2. CI/CD-Job-Token – Durchsetzung der Zulassungsliste für autorisierte Gruppen und Projekte**\n\nGitLab.com | Self-Managed | Dedicated\n\nMit der **[Einstellung für autorisierte Gruppen und Projekte (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-group-or-project-to-the-job-token-allowlist)** (in GitLab 15.9 eingeführt und in GitLab 16.3 in **Zugriff auf dieses Projekt beschränken** umbenannt) kannst du den Zugriff von CI/CD-Job-Token auf dein Projekt verwalten. Wenn du **Nur dieses Projekt und alle Gruppen und Projekte in der Zulassungsliste** auswählst, können nur Gruppen oder Projekte, die der Zulassungsliste hinzugefügt wurden, Job-Token verwenden, um auf dein Projekt zuzugreifen.\n\n* **Vor GitLab 15.9** war die Zulassungsliste standardmäßig deaktiviert (Einstellung [**Alle Gruppen und Projekte** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-any-project-to-access-your-project)), sodass der Zugriff von Job-Token aus jedem Projekt möglich war.   \n* **Seit GitLab 17.6** haben Administrator(inn)en von GitLab-Self-Managed- und Dedicated-Instanzen die Möglichkeit, [**eine sicherere Einstellung für alle Projekte zu erzwingen** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#job-token-permissions), die verhindert, dass Projektbetreuer(innen) **Alle Gruppen und Projekte** auswählen. Diese Änderung sorgt für ein höheres Maß an Sicherheit zwischen Projekten.   \n* In GitLab 18.0 ist diese Einstellung standardmäßig aktiviert. Auf GitLab.com werden wir die Zulassungslisten deiner Projekte automatisch auf der Grundlage deiner Projekt-Authentifizierungsprotokolle auffüllen.   \n* Um sich auf diese Änderung auf **GitLab.com** vorzubereiten, sollten Projektbetreuer(innen), die das Job-Token für die projektübergreifende Authentifizierung verwenden, die Zulassungslisten für **Autorisierte Gruppen und Projekte** ihres Projekts belegen. Sie sollten dann die Einstellung auf **Nur** **dieses Projekt und Gruppen und Projekte in der Zulassungsliste** ändern. Wir empfehlen die Verwendung der verfügbaren [Migrationswerkzeuge (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#auto-populate-a-projects-allowlist), um die Erstellung der Zulassungsliste basierend auf den [Authentifizierungsprotokollen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#job-token-authentication-log) des Projekts vor GitLab 18.0 zu ***automatisieren***.   \n* **Benutzer(innen) von Self-Managed** sollten die Zulassungslisten vor dem Upgrade auf 18.0 belegen.   \n* **Dedicated-Benutzer(innen)** sollten mit ihrem GitLab-Kontoteam zusammenarbeiten, um die geeignete Strategie für ihre spezifische Instanz zu entwickeln.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#cicd-job-token---authorized-groups-and-projects-allowlist-enforcement)\n- [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-gr)\n- [Überprüfung über GitLab Detective verfügbar](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**3. Durchsetzung des Geltungsbereichs von Abhängigkeits-Proxy-Token**\n\nGitLab.com | Self-Managed | Dedicated\n\nDer Abhängigkeits-Proxy für Container akzeptiert die Anfragen **`docker login`** und **`docker pull`** mit **persönlichen, Projekt-** oder **Gruppen-**Zugriffstoken, ohne deren Geltungsbereich zu validieren.\n\nIn GitLab 18.0 benötigt der Abhängigkeits-Proxy sowohl den Geltungsbereich **`read_registry`** als auch den Geltungsbereich **`write_registry`** für die Authentifizierung. Nach dieser Änderung werden Authentifizierungsversuche mit Token ohne diese Bereiche **abgelehnt**.\n\nErstelle vor dem Upgrade neue Zugriffstoken mit den [**erforderlichen Geltungsbereichen** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy-for-container-images) und aktualisiere deine Workflow-Variablen und -Skripte mit diesen neuen Token.\n\nDu hast auch die Möglichkeit, den [**Dependency Token Checker**](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/dependancy-token-checker/) zu verwenden, ein von der Community entwickeltes Skript, mit dem du Token anzeigen und automatisch rotieren kannst.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#dependency-proxy-token-scope-enforcement)\n\n### Mittlere Auswirkungen\n\n**1. Neue Fristen für die Datenaufbewahrung bei Sicherheitslücken auf GitLab.com**\n\nGitLab.com – **nur für Kund(inn)en mit Ultimate-Tarif**\n\nAb GitLab 18.1 werden wir mit einem schrittweisen, sechsmonatigen Rollout eine **neue Frist für die Datenaufbewahrung** für GitLab.com **Ultimate**-Kund(inn)en einführen, um die Systemleistung und -zuverlässigkeit zu verbessern. Die Datenaufbewahrungsfrist bestimmt, wie lange die Daten zu deinen Sicherheitslücken gespeichert werden.\n\nSicherheitslücken, die älter als 12 Monate sind und nicht aktualisiert wurden, werden automatisch in Cold-Storage-Archive verschoben. Diese Archive:\n\n* bleiben über die GitLab-Benutzeroberfläche zugänglich und können heruntergeladen werden\n* werden 3 Jahre lang aufbewahrt  \n* werden nach 3 Jahren endgültig gelöscht \n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)\n- [Dokumentation (nur in englischer Sprache verfügbar)](https://handbook.gitlab.com/handbook/security/records-retention-deletion/)\n\n**2. Ablehnen von Pull-Richtlinien für Container-Images, die nicht in `allowed_pull_policies` enthalten sind**\n\nGitLab.com | Self-Managed | Dedicated  \n\nAlle konfigurierten Pull-Richtlinien sollten in der [**allowed_pull_policies-Konfiguration** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies) vorhanden sein, die in der Datei **`config.toml`** des Runners angegeben ist. Wenn dies nicht der Fall ist, sollte der Job mit dem Fehler **`incompatible pull policy`** fehlschlagen.\n\nWenn in der aktuellen Implementierung mehrere Pull-Richtlinien definiert sind, werden Jobs übergeben, wenn mindestens eine Pull-Richtlinie mit den Richtlinien in **`allowed-pull-policies`** übereinstimmt, auch wenn andere Richtlinien nicht enthalten sind.\n\nIn GitLab 18.0 schlagen Jobs nur fehl, wenn keine der Pull-Richtlinien mit den in **`allowed-pull-policies`** angegebenen übereinstimmt. Im Gegensatz zum früheren Verhalten verwenden Jobs jedoch nur die in **`allowed-pull-policies`** aufgeführten Pull-Richtlinien. Diese Unterscheidung kann dazu führen, dass Jobs, die derzeit erfolgreich ausgeführt werden, in GitLab 18.0 fehlschlagen.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#reject-container-image-pull-policies-not-in-allowed_pull_policies)\n- [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies)\n\n**3. PostgreSQL 14 und 15 werden nicht mehr unterstützt**\n\nSelf-Managed \n\nGitLab folgt einem [**jährlichen Upgrade-Rhythmus für PostgreSQL** (nur in englischer Sprache verfügbar)](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/).\n\nDie Unterstützung für PostgreSQL 14 und 15 soll in GitLab 18.0 entfernt werden. Ab GitLab 18.0 ist PostgreSQL 16 die minimal erforderliche Version von PostgreSQL.\n\nPostgreSQL 14 und 15 werden für den gesamten Release-Zyklus von GitLab 17 unterstützt. PostgreSQL 16 wird auch für Instanzen unterstützt, die vor GitLab 18.0 ein Upgrade durchführen möchten.\n\nUm diese Änderung auf Instanzen vorzubereiten, die kein [**PostgreSQL-Cluster** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) verwenden (z. B. wenn du eine einzelne PostgreSQL-Instanz ausführst, die du mit einem Omnibus-Linux-Paket installiert hast), versuchen Upgrades auf GitLab 17.11, PostgreSQL automatisch auf Version 16 zu aktualisieren. Wenn du [**PostgreSQL-Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) verwendest oder [**dich gegen dieses automatische Upgrade entscheidest** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades), musst du [**manuell ein Upgrade auf PostgreSQL 16**](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server) durchführen, um ein Upgrade auf GitLab 18.0 durchführen zu können. Stelle sicher, dass du über genügend Speicherplatz verfügst, um das Upgrade durchzuführen.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported)\n- [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n- [Migrationsrichtlinien (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions/)\n\n**4. Einstellung der Terraform-CI/CD-Vorlagen**\n\nSelf-Managed\n\nDie Terraform-CI/CD-Vorlagen werden eingestellt und in GitLab 18.0 entfernt. Dies betrifft die folgenden Vorlagen:\n\n* `Terraform.gitlab-ci.yml`  \n* `Terraform.latest.gitlab-ci.yml`  \n* `Terraform/Base.gitlab-ci.yml`  \n* `Terraform/Base.latest.gitlab-ci.yml`\n\nGitLab kann die Binärdatei **`terraform`** in den Job-Images nicht auf eine Version aktualisieren, die unter der BSL lizenziert ist.\n\nUm Terraform weiterhin zu verwenden, klone die Vorlagen und das [**Terraform-Image**](https://gitlab.com/gitlab-org/terraform-images) und pflege sie nach Bedarf. GitLab bietet [**detaillierte Anweisungen**](https://gitlab.com/gitlab-org/terraform-images) für die Migration zu einem benutzerdefinierten Image.\n\n**Als Alternative empfehlen wir die Verwendung der neuen CI/CD-Komponente OpenTofu auf GitLab.com oder der neuen CI/CD-Vorlage OpenTofu in GitLab Self-Managed.** CI/CD-Komponenten sind noch nicht für GitLab Self-Managed verfügbar. [**Ticket #415638**](https://gitlab.com/gitlab-org/gitlab/-/issues/415638) enthält jedoch den Vorschlag, diese Funktion hinzuzufügen. Wenn CI/CD-Komponenten auf GitLab Self-Managed verfügbar werden, wird die CI/CD-Vorlage OpenTofu entfernt.\n\nErfahre mehr über die neue [CI/CD-Komponente OpenTofu](https://gitlab.com/components/opentofu).\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#deprecate-terraform-cicd-templates)\n\n**5. Wichtiges Update des Prometheus-Unterdiagramms**\n\nSelf-Managed\n\nMit GitLab 18.0 und GitLab Chart 9.0 wird das Prometheus-Unterdiagramm von 15.3 auf 27.3 aktualisiert.\n\nZusammen mit diesem Update wird standardmäßig Prometheus 3 ausgeliefert.\n\nFür das Upgrade sind manuelle Schritte erforderlich. Wenn du Alertmanager, Node Exporter oder Pushgateway aktiviert hast, musst du auch deine Helm-Werte aktualisieren.\n\nWeitere Informationen findest du im [**Migrationsleitfaden** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/charts/releases/9_0/#prometheus-upgrade).\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#major-update-of-the-prometheus-subchart)\n\n### Geringe Auswirkungen\n\n**1. Pakete für SUSE Linux Enterprise Server 15 SP2 werden nicht mehr erstellt**\n\nSelf-Managed\n\nDie langfristige Unterstützung (LTSS) für SUSE Linux Enterprise Server (SLES) 15 SP2 endete im Dezember 2024.\n\nDaher werden wir die SLES-SP2-Distribution für Linux-Paketinstallationen nicht mehr unterstützen. Du solltest ein Upgrade auf SLES 15 SP6 durchführen, um weiterhin Support zu erhalten.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#support-for-suse-linux-enterprise-server-15-sp2)\n\n**2. Entfernen des Gitaly-Ratenbegrenzers**\n\nSelf-Managed\n\nGitaly unterstützte bisher [**RPC-basierte Ratenbegrenzung**](https://gitlab.com/gitlab-org/gitaly/-/blob/4b7ea24f6172a03e7989879200b47b6fd0e2d059/doc/backpressure.md#L55-55). Wir stellen diese Funktion ein, da sie nicht die gewünschten Ergebnisse erzielt. Weitere Informationen findest du im Ticket für die Deaktivierung.\n\nWenn Kund(inn)en den Ratenbegrenzer konfiguriert haben (der veraltet ist), wird kein Fehler zurückgegeben und die Konfiguration wird einfach ignoriert.\n\nKund(inn)en sollten stattdessen den [**Gleichzeitigkeitsgrenzwert** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/) verwenden.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#gitaly-rate-limiting)\n\n**3. Einstellung der Unterstützung für NGINX-Controller-Image 1.3.1**\n\nSelf-Managed\n\nWir aktualisieren das Standard-NGINX-Controller-Image auf 1.11.2. Diese neue Version erfordert neue RBAC-Regeln und einige Benutzer(innen) setzen **nginx-ingress.rbac.create: false**, um ihre eigenen RBAC-Regeln zu verwalten.\n\nDiese Benutzer(innen) müssen die RBAC-Regeln hinzufügen, bevor sie zu 1.11.2 oder höher migrieren. Wir haben einen Fallback-Mechanismus hinzugefügt, um 1.3.1 nur dann bereitzustellen, wenn dieser Helm-Wert wie oben festgelegt ist. Wir haben auch **nginx-ingress.controller.image.disableFallback** hinzugefügt, das standardmäßig auf „false“ gesetzt ist. Benutzer(innen), die ihr eigenes RBAC verwalten, können diesen Wert auf „true“ setzen, damit ihre Bereitstellungen auch 1.11.2 verwenden können, nachdem sie sichergestellt haben, dass die neuen RBAC-Regeln in Kraft sind.\n\nWir planen, die Unterstützung für das 1.3.1-Image und den Fallback-Mechanismus mit der Version 17.5 einzustellen, damit wir diese Unterstützung vollständig entfernen und nur noch 1.11.2 verwenden können, das zahlreiche Sicherheitsvorteile bietet.\n\n[Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#fallback-support-for-gitlab-nginx-chart-controller-image-v131)\n\n**4. Update der Hauptversion der Analysatoren der Anwendungssicherheitstests**\n\nGitLab.com | Self-Managed | Dedicated\n\nDie Phase der Anwendungssicherheitstests wird die Hauptversionen der Analysatoren zusammen mit der Veröffentlichung von GitLab 18.0 aktualisieren.\n\nWenn du nicht die standardmäßig enthaltenen Vorlagen verwendest oder deine Analysator-Versionen fixiert hast, musst du deine CI/CD-Job-Definition aktualisieren, um entweder die fixierte Version zu entfernen oder die neueste Hauptversion zu aktualisieren.\n\nBenutzer(innen) von GitLab 17.0–17.11 erhalten bis zur Veröffentlichung von GitLab 18.0 weiterhin normale Analysator-Updates. Nach GitLab 18.0 werden alle neu behobenen Bugs und Funktionen nur noch in der neuen Hauptversion der Analysatoren veröffentlicht.\n\nGemäß unseren Wartungsrichtlinien portieren wir keine Fehler und Funktionen in veraltete Versionen zurück. Sicherheitspatches werden bei Bedarf in die letzten drei Nebenversionen zurückportiert.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#application-security-testing-analyzers-major-version-update)\n\n**5. API-Entdeckung verwendet standardmäßig Branch-Pipelines**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 18.0 aktualisieren wir das Standardverhalten der CI/CD-Vorlage für die API-Erkennung (**API-Discovery.gitlab-ci.yml**).\n\nVor GitLab 18.0 konfiguriert diese Vorlage Jobs so, dass sie standardmäßig in [**Merge Request-Pipelines** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) ausgeführt werden, wenn ein MR geöffnet ist.\n\nAb GitLab 18.0 richten wir das Verhalten dieser Vorlage am Verhalten der [**stabilen Vorlagen-Editionen** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#template-editions) für andere AST-Scanner aus:\n\n* Standardmäßig führt die Vorlage Scan-Jobs in Branch-Pipelines aus.  \n* Du kannst die CI/CD-Variable **AST_ENABLE_MR_PIPELINES: true** festlegen, um MR-Pipelines zu verwenden, wenn ein MR geöffnet ist. Die Implementierung dieser neuen Variable wird im [**Ticket #410880**](https://gitlab.com/gitlab-org/gitlab/-/issues/410880) nachverfolgt.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#api-discovery-will-use-branch-pipelines-by-default)\n\n**6. DAST DAST_DEVTOOLS_API_TIMEOUT hat einen niedrigeren Standardwert**\n\nGitLab.com | Self-Managed | Dedicated\n\nDie Umgebungsvariable **DAST_DEVTOOLS_API_TIMEOUT** bestimmt, wie lange ein DAST-Scan auf eine Antwort des Browsers wartet. Vor GitLab 18.0 hatte die Variable einen statischen Wert von 45 Sekunden. Ab GitLab 18.0 hat die Umgebungsvariable **DAST_DEVTOOLS_API_TIMEOUT** einen dynamischen Wert, der basierend auf anderen Timeout-Konfigurationen berechnet wird.\n\nIn den meisten Fällen war der Wert von 45 Sekunden höher als der Timeout-Wert vieler Scannerfunktionen. Der dynamisch berechnete Wert macht die Variable __DAST_DEVTOOLS_API_TIMEOUT__ nützlicher, indem er die Anzahl der Fälle erhöht, für die sie gilt.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#dast-dast_devtools_api_timeout-will-have-a-lower-default-value) \n\n## Tools und Ressourcen, um deine Auswirkungen zu verwalten\n\nWir haben spezielle Tools entwickelt, um unseren Kund(inn)en zu helfen, zu verstehen, wie sich diese geplanten Änderungen auf ihre GitLab-Instanz(en) auswirken. Sobald du die Auswirkungen für deine Arbeit analysiert hast, solltest du die in der Dokumentation beschriebenen Maßnahmen überprüfen, um einen reibungslosen Übergang zu GitLab 18.0 zu gewährleisten.\n\n* [Veraltete Funktionen der erweiterten Suche](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/deprecation-migration-tools/advanced-search-deprecations): Dieses Tool nutzt die erweiterte Such-API von GitLab, um Zeichenfolgen zu finden, die in allen GitLab-Gruppen und -Projekten veraltet sind. Es zeigt auch, welche Dateien manuell überprüft werden sollten. *__Hinweis:__ Kann ein paar falsch positive Ergebnisse liefern.*   \n* [Dependency Scanning Build Support Detection Helper](https://gitlab.com/security-products/tooling/build-support-detection-helper): Dieses Tool identifiziert Projekte, die von drei Einstellungen der Abhängigkeitssuche betroffen sind ([1](https://docs.gitlab.com/update/deprecations/#dependency-scanning-for-javascript-vendored-libraries), [2](https://docs.gitlab.com/update/deprecations/#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner), [3](https://docs.gitlab.com/update/deprecations/#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects); alle auf Version 19.0 verschoben). Es verwendet die API, um nach relevanten Dateien und CI-Job-Namen zu suchen.\n* [GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md) (nur Self-Managed): Dieses experimentelle Tool überprüft automatisch eine GitLab-Installation auf bekannte Probleme. Es führt komplexe Überprüfungen durch, indem es Konfigurationsdateien oder Datenbankwerte analysiert. **Hinweis:** Muss direkt auf deinen GitLab-Knoten ausgeführt werden.\n\nWir haben außerdem eine Reihe von Mikrokursen (15 Minuten oder kürzer) auf der GitLab University gestartet, die dir bei der Planung und Durchführung von Maßnahmen zur Minderung einiger dieser Änderungen helfen. [Starte deine Lernreise hier](https://university.gitlab.com/catalog?query=18.0). \n\nWenn du einen kostenpflichtigen Tarif hast und Fragen zu diesen Änderungen hast oder Unterstützung benötigst, [öffne ein Support-Ticket](https://about.gitlab.com/support/portal/) im GitLab-Support-Portal. \n\nWenn du [Benutzer(in) einer kostenlosen Gitlab.com-Lizenz (nur in englischer Sprache verfügbar)](https://about.gitlab.com/support/statement-of-support/#free-users) bist, kannst du über meist englischsprachige Community-Quellen wie die [GitLab-Dokumentation](https://docs.gitlab.com/), das [GitLab-Community-Forum](https://forum.gitlab.com/) und [Stack Overflow](http://stackoverflow.com/questions/tagged/gitlab) auf zusätzlichen Support zugreifen.\n",[810,811,812],"Martin Brümmer","Fabian Zimmer","Sam Wiskow","2025-05-01","2025-04-18","Die Breaking Changes in GitLab 18.0",[14,727],"Bereite dich jetzt auf die Änderungen im kommenden Major Release vor. Analysiere die Auswirkungen für deine Arbeit und prüfe dann die in der Dokumentation beschriebenen Maßnahmen, um einen reibungslosen Übergang zu GitLab 18.0 zu gewährleisten.",{"slug":819,"featured":6,"template":681},"a-guide-to-the-breaking-changes-in-gitlab-18-0","content:de-de:blog:a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","A Guide To The Breaking Changes In Gitlab 18 0","de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"_path":825,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":826,"content":831,"config":838,"_id":840,"_type":16,"title":841,"_source":18,"_file":842,"_stem":843,"_extension":21},"/de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"title":827,"description":828,"ogTitle":827,"ogDescription":828,"noIndex":6,"ogImage":739,"ogUrl":829,"ogSiteName":716,"ogType":717,"canonicalUrls":829,"schema":830},"Automatisiere Agile-Workflows mit dem gem gitlab-triage","In unserer Serie „Erste Schritte mit GitLab“ erfährst du, wie du wiederkehrende Aufgaben – zum Beispiel die Triage von Tickets und Merge Requests – automatisierst und deinen Entwickler(inne)n dadurch wertvolle Zeit sparst.","https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisiere Agile-Workflows mit dem gem gitlab-triage\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-13\",\n      }",{"title":827,"description":828,"authors":832,"heroImage":739,"date":833,"body":834,"category":14,"tags":835,"updatedDate":837},[789],"2025-03-13","*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Einsteiger(inne)n helfen, die GitLabs DevSecOps-Plattform kennenzulernen.*\n\nIn diesem Beitrag geht es um das gem [`gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage), ein leistungsstarkes Tool, mit dem du Bots erstellen kannst, um deinen Agile-Workflow zu automatisieren.\n\n## Warum solltest du deinen Workflow automatisieren?\n\nEffizienz ist in der Softwareentwicklung ausschlaggebend. Indem du wiederkehrende Aufgaben wie die Triage von Tickets und Merge Requests automatisierst, schaffst du wertvolle Zeit für dein Team, in der es sich auf das Wichtigste konzentrieren kann: tolle Software zu entwickeln.\n\nMit `gitlab-triage` kannst du Folgendes tun:\n\n* **Konsistenz sicherstellen:** Wende Labels an und weise Tickets automatisch anhand vordefinierter Regeln zu.\n* **Reaktionszeit verbessern:** Erhalte sofortiges Feedback zu neuen Tickets und Merge Requests.\n* **Manuellen Aufwand reduzieren:** Mache manuelle Triage und Updates überflüssig.\n* **Produktivität steigern:** Entlaste dein Team, damit es sich auf das Programmieren und auf Innovationen konzentrieren kann.\n\n## Wir stellen vor: das gem `gitlab-triage`\n\nDas gem `gitlab-triage` ist eine Ruby-Bibliothek, mit der du Bots erstellen kannst, die mit deinen GitLab-Projekten interagieren. Diese Bots können automatisch verschiedenste Aktionen durchführen, darunter:\n\n* **Labels zuweisen:** Kategorisiere Tickets und Merge Requests automatisch.\n* **Kommentare verfassen:** Gib Neuheiten bekannt, fordere Informationen an oder hinterlasse Feedback.\n* **Aufgaben zuweisen:** Weise Tickets und Merge Request dem passenden Teammitglied zu.\n* **Abschließen:** Schließe veraltete oder gelöste Tickets und Merge Requests.\n* **Tickets erstellen:** Erstelle neue Tickets basierend auf bestimmten Ereignissen oder Bedingungen.\n* **Und vieles mehr!**\n\nSieh dir das [gem-Repository `gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) an.\n\n## Einrichtung deines Triage-Bots\n\nRichten wir jetzt deinen ersten Triage-Bot ein und bringen ihn zum Laufen.\n\n1. Installiere das gem. (Hinweis: Der Befehl gem ist verfügbar, wenn die Programmiersprache Ruby installiert ist.)\n\n```bash\ngem install gitlab-triage\n```\n\n2. Rufe dein GitLab-API-Token ab.\n\n* Gehe zu deinen GitLab-[Profileinstellungen](https://gitlab.com/-/profile/preferences).  \n* Gehe zu **Zugriffstoken**.\n* Erstelle ein neues Token mit dem Geltungsbereich `api`.\n* **Bewahre dein Token sicher auf und lege ein Ablaufdatum dafür fest, sodass es abläuft, wenn du diese Anleitung abgeschlossen hast.**\n\n3. Definiere deine Triage-Richtlinien.\n\nErstelle im Root-Verzeichnis deines Projekts eine Datei mit dem Namen `.triage-policies.yml`. Diese Datei enthält die Regeln, die das Verhalten deines Bots steuern. Hier ist ein einfaches Beispiel:\n\n```yaml\n\n---\n- name: \"Apply 'WIP' label\"\n  condition:\n    draft: true\n  action:\n    labels:\n      - status::wip\n\n- name: \"Request more information on old issue\"\n  condition:\n   date:\n    attribute: updated_at\n    condition: older_than\n    interval_type: months\n    interval: 12\n  action:\n    comment: |\n      {{author}} This issue has been open for more than 12 months, is this still an issue?\n```\n\nDiese Konfiguration definiert zwei Richtlinien:\n\n* Mit der ersten Richtlinie wird das Label `status::wip` allen Tickets zugewiesen, die im Entwurfsstatus sind.\n* Mit der zweiten Richtlinie wird ein Kommentar zu einem Ticket hinzugefügt, in dem angemerkt wird, dass das Ticket in den letzten 12 Monaten nicht aktualisiert wurde.\n\n4. Führe deinen Bot aus.\n\nDu kannst deinen Bot manuell mit dem folgenden Befehl ausführen:\n\n```bash\ngitlab-triage -t \u003Cyour_api_token> -p \u003Cyour_project_id>\n```\n\nErsetze `\u003Cyour_api_token>` mit deinem GitLab-API-Token und `\u003Cyour_project_id>` mit der [ID deines GitLab-Projekts](https://docs.gitlab.com/user/project/working_with_projects/#access-a-project-by-using-the-project-id). Wenn du sehen möchtest, welche Auswirkungen die Aktionen haben, bevor sie tatsächlich ausgeführt hast, kannst du `-n` oder `--dry-run` hinzufügen, um die Richtlinien erst einmal zu testen.\n\n## Automatisierung mit GitLab CI/CD\n\nUm die Ausführung deines Triage-Bots zu automatisieren, integrierst du ihn in [GitLab CI/CD (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation/). Hier ist ein Beispiel für eine `.gitlab-ci.yml`-Konfiguration:\n\n```yaml\n\ntriage:\n  script:\n    - gem install gitlab-triage\n    - gitlab-triage -t $GITLAB_TOKEN -p $CI_PROJECT_ID\n  only:\n    - schedules\n```\n\nDiese Konfiguration definiert einen Job mit dem Namen „Triage“, der das gem `gitlab-triage` installiert und den Bot mit dem `$GITLAB_TOKEN` (eine vordefinierte [CI/CD-Variable](https://docs.gitlab.com/ci/variables/); Dokumentation nur in englischer Sprache verfügbar) und der Variable `$CI_PROJECT_ID` ausführt. Die Klausel `only: schedules` stellt sicher, dass der Auftrag nur nach einem Zeitplan ausgeführt wird.\n\nUm einen [Zeitplan (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) zu erstellen, gehe zu den **CI/CD-Einstellungen** des Projekts und dann zu **Zeitpläne**. Erstelle einen neuen Zeitplan und lege fest, wie häufig dein Bot ausgeführt werden soll (z. B. täglich, stündlich, usw.).\n\n## Erweiterte Triage-Richtlinien\n\n`gitlab-triage` bietet eine Reihe von erweiterten Funktionen, mit denen du ausgefeiltere Triage-Richtlinien erstellen kannst:\n\n* **Reguläre Ausdrücke:** Verwende reguläre Ausdrücke für einen leistungsstarken Musterabgleich.\n* **Zusammenfassungsrichtlinien:** Konsolidiere ähnliche Tickets in ein Übersichtsticket.\n* **Benutzerdefinierte Aktionen:** Definiere mit [Ruby-Codeblöcken](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage#can-i-customize) benutzerdefinierte Aktionen, um komplexere Abläufe über die GitLab-API auszuführen.\n\nHier sind zwei umfassendere Praxisbeispiele aus dem Triage-Bot, der vom Developer Advocacy Team bei GitLab verwendet wird. Die vollständigen Richtlinien findest du in [dieser Datei](https://gitlab.com/gitlab-da/projects/devrel-bot/-/blob/master/.triage-policies.yml?ref_type=heads).\n\n```yaml\n- name: Issues where DA team member is an assignee outside DA-Meta project i.e. DevRel-Influenced\n  conditions:\n    assignee_member:\n      source: group\n      condition: member_of\n      source_id: 1008\n    state: opened\n    ruby: get_project_id != 18 \n    forbidden_labels:\n      - developer-advocacy\n  actions:   \n    labels:\n      - developer-advocacy\n      - DevRel-Influenced\n      - DA-Bot::Skip\n```\n\nDieses Beispiel zeigt Tickets in einer Gruppe. Dabei werden diejenigen ausgeschlossen, die sich im Projekt mit der ID 18 befinden und die Beauftragte haben, die Mitglieder der Gruppe mit der ID 1008 sind und nicht das Label `developer-advocacy` aufweisen. Mit dieser Richtlinie kann das Developer Advocacy Team bei GitLab Tickets finden, die Mitgliedern des Teams zugewiesen sind, aber nicht im Projekt des Teams enthalten sind. Indem die Labels der Teams hinzugefügt werden, kann das Team Beiträge identifizieren und nachverfolgen, die von Personen außerhalb des Teams gemacht wurden.\n\n```\n- name: Missing Due Dates\n  conditions:\n    ruby: missing_due_date\n    state: opened\n    labels:\n      - developer-advocacy\n    forbidden_labels:\n      - DA-Due::N/A\n      - DA-Bot::Skip\n      - DA-Status::FYI\n      - DA-Status::OnHold\n      - CFP\n      - DA-Bot::Triage\n  actions:\n    labels:\n      - DA-Bot-Auto-Due-Date\n    comment: |\n      /due #{get_current_quarter_last_date}\n```\n\nDer Bot in diesem zweiten Beispiel sucht nach allen Tickets mit dem Label `developer-advocacy`, die keine Labels aus der Liste der verbotenen Labes enthalten und deren Fälligkeitsdatum überschritten wurde. Er aktualisiert die Fälligkeitstermine automatisch, indem er dem Ticket mit einem Slash-Befehl und einem Datum, das über Ruby generiert wird, einen Kommentar hinzufügt.\n\nDie in den Richtlinien verwendeten Ruby-Skripte werden in einer separaten Datei definiert, wie unten gezeigt. Mit dieser Funktion kannst du flexibel mit Filtern und Aktionen arbeiten. Du siehst, dass Funktionen für verschiedene Ruby-Befehle erstellt werden, die wir in unseren Richtlinien verwendet haben.\n\n```\nrequire 'json'\nrequire 'date'\nrequire \"faraday\"\nrequire 'dotenv/load'\n\nmodule DATriagePlugin\n  def last_comment_at\n    conn = Faraday.new(\n      url: notes_url+\"?sort=desc&order_by=created_at&pagination=keyset&per_page=1\",\n      headers: {'PRIVATE-TOKEN' => ENV.fetch(\"PRIV_KEY\"), 'Content-Type' => 'application/json' }\n    )\n\n    response = conn.get()\n    if response.status == 200\n      jsonData = JSON.parse(response.body)\n      if jsonData.length > 0\n        Date.parse(jsonData[0]['created_at'])\n      else\n        Date.parse(resource[:created_at])\n      end\n    else\n      Date.parse(resource[:created_at])\n    end\n  end\n\n  def notes_url\n    resource[:_links][:notes]\n  end\n\n  def get_project_id\n    resource[:project_id]\n  end\n\n  def get_current_quarter_last_date()\n    yr = Time.now.year\n    case Time.now.month\n    when 2..4\n      lm = 4\n    when 5..7\n      lm = 7\n    when 8..10\n      lm = 10\n    when 11..12\n      lm = 1\n      yr = yr + 1\n    else\n      lm = 1    \n    end\n\n    return Date.new(yr, lm, -1) \n  end\n\n  def one_week_to_due_date\n    if(resource[:due_date] == nil)\n      false\n    else\n      days_to_due = (Date.parse(resource[:due_date]) - Date.today).to_i\n      if(days_to_due > 0 && days_to_due \u003C 7)\n        true\n      else\n        false\n      end\n    end\n  end\n\n  def due_date_past\n    if(resource[:due_date] == nil)\n      false\n    else\n      Date.today > Date.parse(resource[:due_date])\n    end\n  end\n\n  def missing_due_date\n    if(resource[:due_date] == nil)\n      true\n    else\n      false\n    end\n  end\n\nend\n\nGitlab::Triage::Resource::Context.include DATriagePlugin\n\n```\nDer Triage-Bot wird mit folgendem Befehl ausgeführt:\n\n``` \n`gitlab-triage -r ./triage_bot/issue_triage_plugin.rb --debug --token $PRIV_KEY --source-id gitlab-com --source groups`  \n```\n\n- `-r`: Übergibt eine Datei mit Anforderungen für die Ausführung der Triage. In diesem Fall übergeben wir unsere Ruby-Funktionen.  \n- `--debug`: Fügt der Ausgabe Debugging-Informationen hinzu.  \n- `--token`: Wird verwendet, um ein gültiges GitLab-API-Token zu übergeben.  \n- `--source`: Gibt an, ob die Quellen des Tickets, die durchsucht werden, in einer Gruppe oder einem Projekt liegen.\n- `--source-id`: Übernimmt die ID des ausgewählten Quelltyps – in diesem Fall eine Gruppe.\n\nDas GitLab-Projekt [triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) ist ein weiteres Praxisbeispiel, das etwas komplexer ist und bei dem du lernen kannst, deinen eigenen Triage-Bot zu erstellen.\n\n## Best Practices\n\n* **Beginne einfach:** Beginne mit grundlegenden Richtlinien und erhöhe die Komplexität schrittweise nach Bedarf. \n* **Teste gründlich:** Teste deine Richtlinien in einer Staging-Umgebung, bevor du sie in der Produktion bereitstellst.  \n* **Überwache regelmäßig:** Überwache die Aktivität deines Bots, um sicherzustellen, dass er sich wie erwartet verhält.\n* **Verwende beschreibende Namen:** Gib deinen Richtlinien klare und beschreibende Namen, damit sie einfach gepflegt werden können. \n* **Achte auf den Umfang deiner Filter:** Vielleicht kommst du in Versuchung, Tickets über Gruppen hinweg zu filtern, die Tausende von Tickets enthalten. Dies kann jedoch die Triage verlangsamen und der Prozess kann aufgrund von Ratenbeschränkungen für die GitLab-API auch fehlschlagen.  \n* **Priorisiere die Verwendung von Labels für die Triage:** Um unnötige Benachrichtigungen an andere Benuzter(innen) zu vermeiden, sind Labels eine tolle Möglichkeit, eine Triage durchzuführen, ohne Kommentare und Tickets zu überladen.\n\n## Übernimm die Kontrolle über deinen Workflow\n\nMit dem gem `gitlab-triage` kannst du deinen GitLab-Workflow automatisieren und eine ganz neue Effizienz ermöglichen. Erstelle zunächst einen einfachen Traige-Bot und lerne dann nach und nach die fortschrittlicheren Funktionen kennen. Du wirst erstaunt sein, wie viel Zeit und Aufwand du einsparen kannst\\!\n\n## Serie: Erste Schritte mit GitLab\n\nWeitere Artikel in unserer Serie „Erste Schritte mit GitLab“:\n\n- [Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n\n- [Projekte in GitLab importieren (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Projektmanagement](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-mastering-project-management/)\n",[727,678,14,836,110],"agile","2025-04-21",{"slug":839,"featured":6,"template":681},"automating-agile-workflows-with-the-gitlab-triage-gem","content:de-de:blog:automating-agile-workflows-with-the-gitlab-triage-gem.yml","Automating Agile Workflows With The Gitlab Triage Gem","de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem.yml","de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"_path":845,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":846,"content":852,"config":859,"_id":861,"_type":16,"title":862,"_source":18,"_file":863,"_stem":864,"_extension":21},"/de-de/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"title":847,"description":848,"ogTitle":847,"ogDescription":848,"noIndex":6,"ogImage":849,"ogUrl":850,"ogSiteName":716,"ogType":717,"canonicalUrls":850,"schema":851},"Erstelle eine neue Website in wenigen einfachen Schritten mit GitLab Pages ","In diesem Tutorial erfährst du, wie du deine persönliche Website mithilfe von GitLab Pages und einer einsatzbereiten Vorlage, die du in wenigen Minuten anpassen kannst, erstellst und hostest.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097716/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_7c3TDgNgct9xQbmTJSw0de_1750097716096.png","https://about.gitlab.com/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erstelle eine neue Website in wenigen einfachen Schritten mit GitLab Pages \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alex Fracazo\"}],\n        \"datePublished\": \"2025-03-03\",\n      }\n                  ",{"title":847,"description":848,"authors":853,"heroImage":849,"date":855,"body":856,"category":14,"tags":857,"updatedDate":858},[854],"Alex Fracazo","2025-03-03","Eine persönliche Website ist mehr als nur ein Arbeitsmittel für digitale Kreative und Technologieexpert(inn)en. Sie repräsentiert deine Marke. Aber eine Website von Grund auf neu zu erstellen, kann zeitaufwendig und teuer sein.\n\nMit [GitLab Pages (Dokumentation nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/pages/) kannst du deine Website mit integrierten Funktionen hosten, einschließlich SSL-Zertifikaten und einer von GitLab bereitgestellten Domain. All dies ist im kostenlosen Tarif von GitLab enthalten und somit eine effiziente Lösung für das Hosting deines professionellen Internetauftritts.\n\nWir nehmen dich mit auf eine unterhaltsame Reise, um mit GitLab Pages eine beeindruckende persönliche Website zu erstellen! Unsere Vorlage ist supereinfach und vielseitig und du kannst sie ganz leicht aufpeppen, damit sie deinen einzigartigen Stil widerspiegelt. Also schnapp dir deinen Lieblingssnack, mach es dir gemütlich und lass uns deine Online-Präsenz in etwas wirklich Fabelhaftes verwandeln!\n\n## Voraussetzungen\n\nBevor du loslegst, musst du die folgenden Voraussetzungen erfüllen:\n\n* Du brauchst ein GitLab-Konto (der [kostenlose Tarif](https://about.gitlab.com/de-de/pricing/) ist ausreichend).  \n* Du solltest mit den Grundlagen von HTML/CSS vertraut sein.  \n* Bereite Inhalte und Bilder vor, die du auf deiner Website verwendet möchtest (optional).\n\nSobald du ein GitLab-Konto eingerichtet hast und deine Inhalte verfügbar sind, kannst du mit den nächsten Schritten fortfahren.\n\n## Schritt 1: Neues Projekt erstellen\n\n1. Melde dich bei deinem GitLab-Konto an und erstelle ein Projekt.\n\n![GitLab-Pages-Tutorial – Begrüßungsbildschirm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097724/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183716_aHR0cHM6_1750097724662.png)\n\n2. Klicke auf **Leeres Projekt erstellen**.\n\n![GitLab-Pages-Tutorial – Bildschirm „Neues Projekt erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183814_aHR0cHM6_1750097724663.png)\n\n3. Gib deine Projektdetails ein:\n    * Nenne dein Projekt `deinbenutzername.gitlab.io`. Ersetze `deinbenutzername` durch deinen GitLab-Benutzernamen. **Tipp:** Der Projektname legt die URL deiner Website fest. Wenn du dein Projekt `deinbenutzername.gitlab.io` nennst, wird deine Website unter `https://deinbenutzername.gitlab.io` ohne zusätzlichen Pfad verfügbar sein. Wenn du jedoch einen anderen Projektnamen verwendest, wird deine Website unter `https://deinbenutzername.gitlab.io/project-name` verfügbar sein.\n    * Veröffentliche das Projekt.\n4. Klicke auf **Projekt erstellen **.\n\n![GitLab-Pages-Tutorial – Bildschirm „Leeres Projekt erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097724666.png)\n\n![GitLab-Pages-Tutorial – angepasste Einstiegsseite](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097724668.png)\n\n## Schritt 2: Vorlagendateien hinzufügen\n\nErstelle zunächst zwei neue Dateien in deinem Repository:\n\n![GitLab-Pages-Tutorial – Hinzufügen neuer Dateien zur persönlichen Seite](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750097724669.png)\n\n1. Erstelle zuerst `index.html`:\n    * Klicke in deinem Projekt auf die Schaltfläche **+** und wähle **Neue Datei** aus.\n    * Nenne die Datei `index.html`.\n![GitLab-Pages-Tutorial – Seite „Neue Datei“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750097724671.png)\n    * Füge deinen HTML-Inhalt hinzu.\n        * Verwende das unten angegebene HTML-Beispiel. (Profi-Tipp: Bitte GitLab Duo Chat, HTML-Code für erweiterte Funktionen zu generieren.)\n\n```    \n\u003C!DOCTYPE html>\n\u003Chtml>\n\u003Chead>\n    \u003Cmeta charset=\"utf-8\"/>\n    \u003Ctitle>[Dein Name] - [Dein Titel]\u003C/title>\n    \u003Cmeta name=\"description\" content=\"[Your Name] is a [Your Title].\"/>\n    \u003Cmeta name=\"author\" content=\"[Your Name]\"/>\n    \u003Cmeta property=\"og:title\" content=\"[Your Name]\" />\n    \u003Cmeta property=\"og:description\" content=\"[Your Title]\" />\n    \u003Cmeta property=\"og:image\" content=\"og.png\" />\n    \u003Cmeta name=\"viewport\" content=\"width=device-width,initial-scale=1\"/>\n    \u003Clink href=\"https://unpkg.com/basscss@8.0.2/css/basscss.min.css\" rel=\"stylesheet\">\n    \u003Clink href=\"style.css\" rel=\"stylesheet\">\n    \u003Clink rel=\"shortcut icon\" type=\"image/png\" href=\"favicon.png\"/>\n\u003C/head>\n\u003Cbody>\n\u003Cdiv class=\"content\" id=\"content\">\n  \u003Cdiv class=\"p2 sm-p4 mt2 sm-mt4 mb2 sm-mb4\">  \n  \u003Cdiv class=\"fade mt3\">\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">\n      \u003Cimg class=\"photo\" src=\"profile.png\" width=\"64\" height=\"64\">\n    \u003C/a>\n  \u003C/div>\n  \u003Ch2 class=\"mb0 mt4 fade\">\n    Hallo, ich bin [Dein Name]  \n    \u003Cspan class=\"smallcaps\">(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Dein Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/h2>\n  \u003Ch2 class=\"mt0 mb4 fade gray\">\n    Ich bin [Dein Titel]\n  \u003C/h2>\n  \u003Cp class=\"mb4 fade\">\n    Ich bin [Deine Rolle] bei [Dein Unternehmen], [Kurze Unternehmensbeschreibung].\n  \u003C/p>\n  \u003Cdiv class=\"fade\">\n    \u003Cp class=\"fade mb4\">\n      Dein persönliches Statement, was du tust und woran du interessiert bist. Füge hier deine Kontaktmöglichkeiten hinzu.\n    \u003C/p>\n  \u003C/div>\n  \u003Cp class=\"fade mb4\">\n    \u003Cspan class=\"gray\">—\u003C/span> \n    [Dein Name] \n    \u003Cspan class=\"smallcaps>(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Dein Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/p>\n  \u003C/div>\n\u003C/div>\n\u003C/body>\n\u003C/html> \n```\n\n* Füge eine Commit-Nachricht hinzu (z. B. „Added index.html“).\n  * Klicke auf **Änderungen committen**.\n\n2. Erstelle `style.css` (die Vorgehensweise ist die gleiche wie oben).\n\n```\nbody {\n  margin: 0;\n  padding: 0;\n  background: #000;\n  color: #f4f4f4;\n  font-family: \"Graphik Web\", system-ui, -apple-system, BlinkMacSystemFont, \"Helvetica Neue\", \"Helvetica\", \"Segoe UI\", Roboto, Ubuntu, sans-serif;\n  font-weight: 400;\n  font-smooth: antialiased;\n  -webkit-font-smoothing: antialiased;\n  -moz-osx-font-smoothing: grayscale;\n}\n\na {\n  color: #ff310a;\n  text-decoration: none;\n}\n\na:hover {\n  color: #CFEF54\n}\n\n.content {\n  max-width: 40rem;\n  margin: 0 auto;\n}\n\nimg.photo {\n  border-radius: 50%;\n}\n\np {\n  font-size: 1.5rem;\n  line-height: 1.4;\n  margin: 0;\n  letter-spacing: -0.05rem;\n}\n\nh2 {\n  font-weight: 400;\n  line-height: 1.3;\n  letter-spacing: -0.05rem;\n}\n\n.smallcaps {\n  font-variant: small-caps;\n  color:#333;\n}\n\n.gray{\n  color: #999;\n}\n\n.preloader {\n  display: flex;\n  justify-content: center;\n  align-items: center;\n  height: 100vh;\n  height: -moz-available;\n  height: -webkit-fill-available;\n  height: fill-available;\n  width: 100%;\n  background: #000;\n  position: fixed;\n  top: 0;\n  left: 0;\n  z-index: 9999;\n  transition: opacity 0.3s linear;\n  transform: translate3d(0, 0, 0);\n}\n\nbody.loaded .preloader {\n  opacity: 0;\n}\n\n.fade {\n  animation: fadeIn 1s ease-in-out both;\n}\n\n.fade:nth-child(2) {\n  animation-delay: 1s;\n}\n\n.fade:nth-child(3) {\n  animation-delay: 2s;\n}\n\n.fade:nth-child(4) {\n  animation-delay: 3s;\n}\n\n.fade:nth-child(5) {\n  animation-delay: 4s;\n}\n\n.fade:nth-child(6) {\n  animation-delay: 5s;\n}\n\n.fade:nth-child(7) {\n  animation-delay: 6s;\n}\n\n.fade:nth-child(8) {\n  animation-delay: 7s;\n}\n\n.fade:nth-child(9) {\n  animation-delay: 8s;\n}\n\n.fade:nth-child(10) {\n  animation-delay: 9s;\n}\n\n.fade:nth-child(11) {\n  animation-delay: 10s;\n}\n\n.fade:nth-child(12) {\n  animation-delay: 11s;\n}\n\n.fade:nth-child(13) {\n  animation-delay: 12s;\n}\n\n@keyframes fadeIn {\n  from {\n    opacity: 0;\n    transform: translate3d(0, 0%, 0);\n  }\n  to {\n    opacity: 1;\n    transform: translate3d(0, 0, 0);\n  }\n} \n\n```\n\n## Schritt 3: GitLab-CI-Datei konfigurieren\n\nEs gibt zwei Möglichkeiten, die GitLab-CI-Konfigurationsdatei zu erstellen, die GitLab mitteilt, wie deine Website erstellt und bereitgestellt werden soll:\n\n![GitLab-Pages-Tutorial – Bildschirm zur Optimierung deines Workflows mit CI/CD-Pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097724672.png)\n\n**Option 1: Verwende den Pipeline-Editor (empfohlen)**\n\n1. Gehe in deinem Projekt zu **Build > Pipeline-Editor**.\n\n![GitLab-Pages-Tutorial – Pipeline-Editor/main-Branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750097724673.png)\n\n2. Die Datei `.gitlab-ci.yml` wird automatisch erstellt. \n3. Kopiere die folgende Konfiguration und füge sie ein:\n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\n![GitLab-Pages-Tutorial – Neue Datei im Fenster](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097724674.png)\n\n**Option 2: Manuelle Erstellung**\n\nWenn du die Datei lieber manuell erstellen möchtest: \n1. Erstelle eine neue Datei mit dem Namen `.gitlab-ci.yml`. \n2. Füge die folgende Konfiguration ein:\n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\nDie GitLab-CI-Konfigurationsdatei ist der Schlüssel, um deine Website zum Laufen zu bringen. Diese Datei weist GitLab an, wie es deine Website erstellen und bereitstellen soll.\n\nSehen wir uns an, was jeder Teil macht:\n\n**Das script-Teil**\n\n```\nscript:\n  - mkdir .public\n  - cp -r * .public\n  - mv .public public\n```\n\nDieses Skript erstellt einen Ordner mit dem Namen `public` und kopiert alle Dateien deiner Website dorthin. GitLab Pages verwendet diesen Ordner standardmäßig, um deine Website zu bedienen, aber du kannst bei Bedarf [den Veröffentlichungsordner anpassen (Dokumentation nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/pages/introduction/#customize-the-default-folder).\n\n**Der only-Teil**\n\n```\nonly:\n  - main\n\n```\n\nDamit wird GitLab angewiesen, deine Website nur zu aktualisieren, wenn Änderungen am main-Branch vorgenommen werden. Das hilft, versehentliche Aktualisierungen durch experimentelle Änderungen zu verhindern.\n\n## Schritt 4: Jetzt geht alles wie von selbst\n1. Committe alle deine Änderungen.\n2. Gehe zu **Build > Pipelines**, um zu beobachten, wie deine Website bereitgestellt wird.\n3. Warte, bis die Pipeline erfolgreich abgeschlossen ist (durch ein grünes Häkchen gekennzeichnet).\n\n![GitLab-Pages-Tutorial – Pipeline für neue Seite wird ausgeführt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097724676.png)\n\n![GitLab-Pages-Tutorial – Pipeline für neue Seite übergeben](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097724677.png)\n\n## Schritt 5: Auf deine Website zugreifen\n\nSobald die Pipeline erfolgreich abgeschlossen ist, ist deine Website unter **https://[deinbenutzername].gitlab.io/** verfügbar.\n\nEine Übersicht über deine bereitgestellte Website und zusätzliche Einstellungen findest du in deinem Projekt im Bereich **Bereitstellen > Pages**. Hier findest du nützliche Informationen, wie zum Beispiel: \n\n* Die Zugriffs-URLs deiner Website   \n* Domain-Einstellungen  \n  * Standardmäßig aktiviert GitLab **Einzigartige Domain**. Achte darauf, dies zu deaktivieren, wenn du die von GitLab bereitgestellte Domain verwenden möchtest. Weitere Informationen findest du in der [Dokumentation für einzigartige Domains (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/pages#unique-domains).  \n* HTTPS-Zertifikatstatus   \n* Letzte Bereitstellungen   \n* Zusätzliche Konfigurationsoptionen\n* Benutzerdefinierte Domains\n\nDieser Bereich ist besonders hilfreich, wenn du benutzerdefinierte Domains einrichtest oder für die Problembehebung bei der Bereitstellung.\n\n**Passe deine Website an**\n\n![GitLab-Pages-Tutorial – Website anpassen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097724678.png)\n\n1. Ersetze alle „Dein …“-Platzhalter in `index.html` durch deine Daten.\n\n![GitLab-Pages-Tutorial – Datei hochladen, um Seite anzupassen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097724679.png)\n\n2. Füge deine Bilder hinzu:\n    - profile.png – dein Profilbild (64 x 64 px)\n    - favicon.png – dein Website-Favicon (32 x 32 px)\n    - Og.png – OpenGraph-Bild für Social-Media-Vorschau (1 200 x 630 px)\n\n**Sieh dir die Website an**\n\nWenn du mit GitLab vertraut bist, kannst du gerne [mein Repository forken](https://gitlab.com/fracazo/fracazo.gitlab.io), um schnell loszulegen. \n\nHier ist das Endergebnis:\n[https://fracazo.gitlab.io/](https://fracazo.gitlab.io/)\n\n**Häufige Probleme und Lösungen**\n- Standardmäßig aktiviert GitLab für Pages-Projekte „Einzigartige Domain“. Um die einfachere von GitLab bereitgestellte Domain (wie `benutzername.gitlab.io`) zu verwenden, gehe zu **Bereitstellen > Pages** und deaktiviere die Option „Einzigartige Domain verwenden“. Einzigartige Domains bieten zwar einige technische Vorteile, wie z. B. eine bessere Handhabung der Ressourcenpfade, aber für eine persönliche Website ziehst du vielleicht die cleanere URL-Struktur vor.\n- Wenn deine Pipeline fehlschlägt, stelle sicher, dass du in deiner `.gitlab-ci.yml`-Datei `main` anstelle von `master` verwendest.\n- Stelle sicher, dass deine Gruppe und dein Projekt öffentlich sind, damit GitLab Pages funktioniert.\n- Wenn in deiner Pipeline ein Job fehlschlägt, suche im Job-Protokoll nach detaillierten Fehlermeldungen, die dir bei der Problembehandlung helfen können.\n\nMit GitLab Pages und dieser Vorlage kannst du in wenigen Minuten eine professionelle oder persönliche Website erstellen. Die Vorlage ist clean, reaktionsschnell und einfach anzupassen. Wenn du dich beruflich weiterentwickelst, kannst du deine Website direkt über GitLab aktualisieren. \n\nDu kannst den Bereitstellungsprozess automatisieren, indem du die CI/CD-Funktionen von GitLab nutzt und dich auf die Erstellung großartiger Inhalte konzentrierst.\n\nUnd das Beste daran? All dies ist im kostenlosen Tarif von GitLab enthalten und somit eine ausgezeichnete Option für das kostenlose Hosting deiner persönlichen Projekte, Dokumentationsseiten oder sogar Websites für kleine Unternehmen. Weitere erweiterte Funktionen und Konfigurationen findest du in unserer [Pages-Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/pages/).\n\n## Wie geht es weiter mit GitLab Pages?\nWir arbeiten ständig daran, GitLab Pages für Kreative und Entwickler(innen) noch besser zu machen. Hier sind einige aufregende Verbesserungen, die bald verfügbar sein werden: \n\n### Vereinfachtes Domain-Management \nWir haben einige aufregende Updates für GitLab Pages, die die Verwaltung deiner Domains noch einfacher und unterhaltsamer machen werden! Du kannst dich auf ein optimiertes Dashboard freuen, das alle deine Domain-Einstellungen in einem übersichtlichen Bereich zusammenführt und alles leicht zugänglich macht. \n\nDu bleibst mit Echtzeit-Updates über deinen DNS- und SSL-Zertifikatsstatus auf dem Laufenden, damit deine Domains sicher sind und reibungslos funktionieren. \n\n### Einrichten benutzerdefinierter Domains\nDie Einrichtung benutzerdefinierter Domains ist mit unserem einfach zu befolgenden Prozess, der dich bei jedem Schritt begleitet, ein Kinderspiel. Außerdem kannst du deine benutzerdefinierten Domains so einrichten, dass Besucher(innen) von deiner alten Website automatisch auf deine neue umgeleitet werden – perfekt, wenn du möchtest, dass dein gesamter Traffic auf eine Hauptwebsite geleitet wird. Erfahre mehr über [benutzerdefinierte Domains (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/index.html#set-up-a-custom-domain).\n\n> Lege jetzt mit GitLab Pages im [kostenlosen Tarif von GitLab](https://about.gitlab.com/de-de/pricing/) los!\n\n## Mehr erfahren\n(Informationen nur in englischer Sprache verfügbar)\n- [GitLab-Pages-Funktionen überprüfen Apps und mehrere Website-Bereitstellungen](https://about.gitlab.com/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment/)\n- [GitLab Pages: Dokumentation zur Bereitstellung mehrerer Websites](https://docs.gitlab.com/user/project/pages/#parallel-deployments)\n- [Beispiele für GitLab Pages](https://gitlab.com/pages)",[678,727],"2025-03-06",{"slug":860,"featured":6,"template":681},"build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","content:de-de:blog:build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","Build A New Website In A Few Easy Steps With Gitlab Pages","de-de/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","de-de/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"_path":866,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":867,"content":873,"config":881,"_id":883,"_type":16,"title":884,"_source":18,"_file":885,"_stem":886,"_extension":21},"/de-de/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":868,"description":869,"ogTitle":868,"ogDescription":869,"noIndex":6,"ogImage":870,"ogUrl":871,"ogSiteName":716,"ogType":717,"canonicalUrls":871,"schema":872},"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":868,"description":869,"authors":874,"heroImage":870,"date":876,"body":877,"category":14,"tags":878,"updatedDate":880},[875],"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, 60-tägige Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) an.\n",[702,678,879],"solutions architecture","2025-05-13",{"slug":882,"featured":92,"template":681},"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":888,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":889,"content":895,"config":903,"_id":905,"_type":16,"title":906,"_source":18,"_file":907,"_stem":908,"_extension":21},"/de-de/blog/getting-started-with-gitlab-mastering-project-management",{"ogTitle":890,"schema":891,"ogImage":892,"ogDescription":893,"ogSiteName":716,"noIndex":6,"ogType":717,"ogUrl":894,"title":890,"canonicalUrls":894,"description":893},"Projektmanagement mit GitLab | Ein Leitfaden für die Praxis","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab – Projektmanagement\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-02-11\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097294/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097293924.png","Wir zeigen dir, warum sich GitLab für dein Projektmanagement lohnt. ✓ Komponenten ✓ Funktionen ✓ Vorteile ➤ GitLab Projektmanagement starten!","https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management",{"heroImage":892,"body":896,"authors":897,"updatedDate":898,"date":899,"title":900,"tags":901,"description":902,"category":14},"*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.*\n\nGitLab ist nicht nur ein Ort, an dem du deinen Code speichern kannst. Es ist vielmehr eine KI-basierte DevSecOps-Plattform, die dir hilft, deine Projekte zu planen, zu organisieren, nachzuverfolgen und erfolgreich zu liefern. In diesem Beitrag lernst du die wichtigsten Projektmanagementfunktionen von GitLab kennen und erfährst, wie du sie effektiv nutzen kannst.\n\n## Inhaltsverzeichnis\n\n- [Warum ist GitLab für das Projektmanagement geeignet?](#warum-ist-gitlab-für-das-projektmanagement-geeignet%3F)\n- [Hauptkomponenten des Projektmanagements mit GitLab](#hauptkomponenten-des-projektmanagements-mit-gitlab)\n- [Sieh dir die Funktionen im Detail an](#sieh-dir-die-funktionen-im-detail-an)\n  - [Epics - Das große Ganze](#epics---das-große-ganze)\n  - [Tickets - Dinge erledigen](#tickets---dinge-erledigen)\n  - [Labels - Organisiere deine Arbeit](#labels---organisiere-deine-arbeit)\n  - [Übersichten - Visualisiere deinen Workflow](#übersichten---visualisiere-deinen-workflow)\n  - [Aufgaben - Schlüssle deine Arbeit auf](#aufgaben---schlüssle-deine-arbeit-auf)\n  - [Meilensteine - Verfolge deinen Fortschritt](#meilensteine---verfolge-deinen-fortschritt)\n  - [Iterationen - Arbeiten in Sprints](#iterationen---arbeiten-in-sprints)\n  - [Zeiterfassung - Miss deinen Aufwand](#zeiterfassung---miss-deinen-aufwand)\n  - [Abhängigkeiten - Verwalte deinen Workflow](#abhängigkeiten---verwalte-deinen-workflow)\n  - [Vorlagen - Optimiere die Erstellung von Tickets](#vorlagen-optimiere-die-erstellung-von-tickets)\n- [Zusammenarbeit ist der Schlüssel](#zusammenarbeit-ist-der-schlüssel)\n- [Bist du bereit?](#bist-du-bereit%3F)\n- [Mehr erfahren](#mehr-erfahren)\n\n## Warum ist GitLab für das Projektmanagement geeignet?\n\nStell dir vor, du hast dein Code-Repository, das Ticketsystem und deine Kommunikationsplattform nahtlos an einem Ort integriert. Genau das ist GitLab. Indem alles zentralisiert ist, kannst du deinen Workflow optimieren, die Zusammenarbeit verbessern und deine Projekte voranbringen. Du musst nicht mehr zwischen verschiedenen Tools hin und her wechseln und verlierst nicht mehr den Überblick über Informationen. GitLab führt alles zusammen, sodass du Projekte von Anfang bis Ende einfacher verwalten kannst.\n\n## Hauptkomponenten des Projektmanagements mit GitLab\n\nSchlüsseln wir nun die wichtigsten Elemente (inkl. Links zur englischsprachigen Dokumentation) auf:\n\n* [Epics](https://docs.gitlab.com/ee/user/group/epics/): Stell dir Epics als das große Ganze vor. Sie repräsentieren wichtige Funktionen, übergeordnete Ziele oder langfristige Initiativen in deinem Projekt. Du möchtest deine Website überarbeiten? Das ist ein Epic! Epics helfen dir, deine Arbeit in größere, überschaubare Teile zu organisieren.\n* [Tickets](https://docs.gitlab.com/ee/user/project/issues/): Issues sind die einzelnen Aufgaben oder Workitems, die zu deinen Projektzielen beitragen. Jedes Ticket ist eine spezifische Handlung, wie „Homepage entwerfen“ oder „Über-uns-Seite verfassen“. Tickets sind die Bausteine des Projekts und bieten eine übersichtliche Möglichkeit, individuelle Aufgaben nachzuverfolgen.\n* [Labels](https://docs.gitlab.com/ee/user/project/labels.html): Labels sind wie Tags, mit denen du deine Arbeit kategorisieren und filtern kannst. Du kannst mithilfe von Labes Prioritäten (z. B. hoch, mittel, niedrig) oder Status (z. B. zu erledigen, in Bearbeitung, erledigt) zuordnen oder Tickets bestimmten Teams oder Personen zuweisen. Labels bieten eine flexible Möglichkeit, deine Arbeit zu organisieren und zu priorisieren.  \n* Übersichten: Die Ticketübersichten von GitLab sind dein visueller Arbeitsbereich. Sie stellen dein Projekt im Kanban-Stil dar, sodass du auf einen Blick den Status all deiner Tickets sehen kannst. Ziehe Tickets per Drag & Drop in verschiedene Listen (z. B. „To Do“, „Doing“, „Done“), um deinen Workflow zu visualisieren und den Fortschritt nachzuverfolgen. In GitLab kannst du Übersichten für [Tickets](https://docs.gitlab.com/ee/user/project/issue_board.html) und [Epics](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html) erstellen.\n* [Meilensteine](https://docs.gitlab.com/ee/user/project/milestones/): Meilensteine markieren wichtige Kontrollpunkte oder Zieltermine in deinem Projekt. Sie helfen dir, den Fortschritt bei der Erreichung bestimmter Ziele und Fristen zu verfolgen. Du kannst beispielsweise Meilensteine festlegen, wenn eine wichtige Funktion fertiggestellt wird, eine Beta-Version veröffentlicht wird oder das Endprodukt eingeführt wird.\n* [Aufgaben](https://docs.gitlab.com/ee/user/tasks.html): Wenn du eine noch feinere Unterteilung möchtest, kannst du deine Tickets in kleinere Aufgaben aufteilen. Dies hilft dabei, sie anderen Personen zuzuweisen, individuelle Verantwortlichkeiten zu klären und sicherzustellen, dass nichts übersehen wird. Aufgaben sind eine Möglichkeit, Checklisten innerhalb von Tickets zu erstellen, um den Fortschritt bei komplexen Aufgaben einfacher nachverfolgen zu können.\n\n## Sieh dir die Funktionen im Detail an\n\n### Epics - Das große Ganze\n\n* Epics erstellen: Gehe in deiner Gruppe unter „Planen“ zum Menü „Epics“. Klicke auf **Neues Epic** und gib einen beschreibenden Titel sowie eine deutliche Beschreibung ein, die das Ziel umreißt. Du kannst auch ein Start- und Enddatum für das Epic angeben. Dies ist nützlich, wenn du [Roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/) verwendest.\n\n![Seite zum Erstellen von Epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097300817.png)\n\n* [Roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/): Füge deine Epics zu einer Roadmap hinzu, um deinen Projektzeitplan und deine langfristigen Ziele zu visualisieren. Die Roadmaps bieten einen Überblick über deinen Projektplan und machen es dir leicht, das Gesamtbild zu sehen und den Fortschritt in Richtung wichtiger Meilensteine zu verfolgen.\n\n![Roadmap-Ansicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097300818.png)\n\n### Tickets - Dinge erledigen\n\n* Tickets erstellen: Gehe in deinem Projekt zum Menü „Tickets“ unter „Planen“ und klicke auf **Neues Ticket**. Gib einen prägnanten, beschreibenden Titel wie „Homepage-Wireframes entwerfen“ ein, weise es einem Teammitglied zu, lege ein Fälligkeitsdatum fest und gib eine detaillierte Beschreibung an, in der die Anforderungen der Aufgabe festgelegt sind.\n* GitLab Duo: Du kannst die Möglichkeiten von [GitLab Duo nutzen, um detaillierte Issue-Beschreibungen zu erstellen](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#populate-an-issue-with-issue-description-generation), indem du nur kurz angibst, was du erreichen möchtest.\n* Gewichtung: Schätze den für jedes Ticket erforderlichen Aufwand ein, indem du Gewichtungen zuweist. Dies hilft bei der Planung und Priorisierung. Eine einfache Aufgabe kann beispielsweise eine Gewichtung von **1** haben, während eine komplexere Aufgabe mit **5** gewichtet ist.\n\n![Ticket mit einer zugewiesenen Gewichtung von 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097300819.png)\n\n### Labels - Organisiere deine Arbeit\n\n* Labels erstellen: Gehe zum Tab „Tickets“ deines Projekts und klicke auf „Labels“. Erstelle benutzerdefinierte Labels mit eindeutigen Namen, um deine Tickets zu kategorisieren. Erstelle beispielsweise Labels wie **Priorität: Hoch**, **Status: In Bearbeitung** oder **Team: Design**. Wende diese Labels auf deine Tickets an, um sie zu organisieren und filtern zu können.\n\n![Bildschirm „Labels“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097300820.png)\n\n### Übersichten - Visualisiere deinen Workflow\n\n* Kanban-Boards: Die Übersichten von GitLab bieten eine Ansicht deines Projekts im Kanban-Stil. Erstelle Listen wie „To Do“, „Doing“ und „Done“, um die Phasen deines Workflows darzustellen. Ziehe die Issues per Drag & Drop in diese Listen, um den Fortschritt zu visualisieren.\n* Übersichten anpassen: Passe deine Übersichten an deinen spezifischen Workflow an. Füge weitere Spalten ein, filtere Tickets nach Labels oder Beauftragten oder richte Swimlanes ein, um Tickets nach Epics oder anderen Kriterien zu kategorisieren.\n\n![Workflow mit Ticketübersichten visualisieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097300820.png)\n\n### Aufgaben - Schlüssle deine Arbeit auf\n\n* Aufgaben erstellen: Verwende innerhalb eines Tickets die Markdown-Syntax für Checklisten, um eine Aufgabenliste zu erstellen. Jedes Element in der Liste stellt einen kleineren Schritt innerhalb des größeren Tickets dar. Im Ticket „Homepage-Wireframes entwerfen“ kannst du zum Beispiel die Aufgaben „Erstkonzept skizzieren“, „Digitale Wireframes erstellen“ und „Feedback von Stakeholdern einholen“ erstellen. Um eine Aufgabe zu erstellen, klicke im Abschnitt „Untergeordnete Elemente“ auf der Seite eines Tickets auf die Schaltfläche **Hinzufügen**. Gib dann den Titel der Aufgabe ein und klicke auf **Aufgabe erstellen**.\n\n![Ticket mit der Schaltfläche „Aufgabe erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097300822.png)\n\n### Meilensteine - Verfolge deinen Fortschritt\n* Meilensteine setzen: Definiere Meilensteine, um wichtige Punkte in deinem Projekt zu markieren, z. B. wenn eine bestimmte Funktion fertiggestellt wird oder eine wichtige Frist erreicht wird. Gib deinen Meilensteinen klare Titel und Fälligkeitstermine.\n* Mit Tickets verknüpfen: Verknüpfe Tickets und Epics mit Meilensteinen, um den Fortschritt bei der Erreichung dieser Ziele zu verfolgen. Auf diese Weise kannst du erkennen, wie einzelne Aufgaben zum gesamten Projektplan beitragen.\nMeilenstein erstellen: Klicke in der Auswahl-Liste „Planen“ auf **Meilensteine > Neuer Meilenstein**. Gib den Titel des Meilensteins, eine Beschreibung sowie Start- und Enddatum an.\n\n![Bildschirm „Neuer Meilenstein“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097300823.png)\n\n\u003Cbr>\u003C/br>\n\n![Neue Seite mit Meilenstein](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097300823.png)\n\n### [Iterationen](https://docs.gitlab.com/ee/user/group/iterations/) - Arbeiten in Sprints\n\n* Iterationen definieren: Wenn du einen Agile-Workflow verwendest, definiere Iterationen (Sprints) mit bestimmten Start- und Endterminen. So kannst du deine Arbeit in kleinere, überschaubarere Zeitfenster aufteilen.  \n* Tickets zuweisen: Weise Tickets zu Iterationen zu, um deine Arbeit in kürzeren Zyklen zu planen und dich auf die Bereitstellung von inkrementellem Wert zu konzentrieren.\n\n### [Zeiterfassung](https://docs.gitlab.com/ee/user/project/time_tracking.html) - Miss deinen Aufwand\n\n* Zeit erfassen: Verwende innerhalb eines Tickets die Schnellaktion „/spend“, gefolgt von der aufgewendeten Zeit (z. B. „/spend 2h 30m“), um deine Arbeit zu protokollieren. Auf diese Weise kannst du die tatsächliche Zeit erfassen, die du für jede Aufgabe aufgewendet hast.  \n* Daten analysieren: Erstelle Zeiterfassungsberichte, um Einblicke in den Projektfortschritt und die Teameffizienz zu erhalten und potenzielle Engpässe zu identifizieren.\n\n![Bericht zur Zeiterfassung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097300824.png)\n\n### Abhängigkeiten - Verwalte deinen Workflow\n\n* [Tickets verknüpfen](https://docs.gitlab.com/ee/user/project/issues/related_issues.html): Erstelle Abhängigkeiten zwischen Tickets, um sicherzustellen, dass Aufgaben in der richtigen Reihenfolge abgeschlossen werden. Wenn zum Beispiel Tickets A abgeschlossen sein muss, bevor Tickets B beginnen kann, kannst du eine Abhängigkeit zwischen ihnen erstellen. Damit kannst du den Workflow visualisieren und potenzielle Hindernisse vermeiden.\n\n### Vorlagen - Optimiere die Erstellung von Tickets\n\n* [Vorlagen erstellen](https://docs.gitlab.com/ee/user/project/description_templates.html): Erstelle Vorlagen für Tickets, um die für allgemeine Aufgaben erfassten Informationen zu standardisieren, Zeit zu sparen und Konsistenz zu gewährleisten. Du kannst zum Beispiel eine Vorlage für Fehlerberichte erstellen, die Felder für Schritte enthält, um das erwartete Verhalten und das tatsächliche Verhalten zu reproduzieren.\n\n### Zusammenarbeit ist der Schlüssel\n\nGitLab fördert die Zusammenarbeit durch Folgendes:\n\n* [Kommentare](https://docs.gitlab.com/ee/user/discussions/): Besprich Tickets und Epics direkt in GitLab. Verwende Kommentare, um Updates bereitzustellen, Fragen zu stellen und Feedback zu geben.  \n* [Erwähnungen](https://docs.gitlab.com/ee/user/discussions/#mentions): Verwende **@**, um bestimmte Teammitglieder zu erwähnen und sie über Aktualisierungen zu informieren oder um ihren Input zu bitten.\n* Diskussionen: Nimm an Diskussionen innerhalb von Tickets und Epics teil, um Ideen zu sammeln, Probleme gemeinsam zu lösen und alle auf dem Laufenden zu halten.\n\n### Bist du bereit?\n\nDa du nun gesehen hast, wie leistungsstark die Projektmanagementfunktionen von GitLab sind, ist es an der Zeit, sie praktisch einzusetzen! Erstelle ein Beispielprojekt, experimentiere mit verschiedenen Funktionen und entdecke, wie GitLab deinen Workflow verändern kann. In der GitLab-Dokumentation erfährst du mehr darüber, wie GitLab dich bei [Kanban](https://docs.gitlab.com/ee/tutorials/kanban/) und [Scrum](https://docs.gitlab.com/ee/tutorials/scrum_events/) unterstützen kann.\n\n> #### Du hast noch kein GitLab-Konto? Melde dich jetzt für eine [kostenlose, 60-tägige Testversion von GitLab Ultimate und GitLab Duo](https://about.gitlab.com/de-de/free-trial/) an!\n\n## Mehr erfahren\n- [Erste Schritte mit GitLab: Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Erste Schritte mit GitLab: So importierst du deine Projekte in GitLab (nur auf Englisch verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)\n",[789],"2025-05-14","2025-02-11","Projektmanagement mit GitLab – Erste Schritte",[678,14,727,836],"Entdecke die wichtigsten Komponenten des Projektmanagements und erfahre, wie du sie nutzen kannst, um Organisation und Nachverfolgung zu verbessern.",{"slug":904,"featured":6,"template":681},"getting-started-with-gitlab-mastering-project-management","content:de-de:blog:getting-started-with-gitlab-mastering-project-management.yml","Getting Started With Gitlab Mastering Project Management","de-de/blog/getting-started-with-gitlab-mastering-project-management.yml","de-de/blog/getting-started-with-gitlab-mastering-project-management",{"_path":910,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":911,"content":917,"config":925,"_id":927,"_type":16,"title":928,"_source":18,"_file":929,"_stem":930,"_extension":21},"/de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"ogTitle":912,"schema":913,"ogImage":914,"ogDescription":915,"ogSiteName":716,"noIndex":6,"ogType":717,"ogUrl":916,"title":912,"canonicalUrls":916,"description":915},"Leitfaden: Kontinuierliche Bereitstellung mit GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Vom Code bis zur Produktion: Ein Leitfaden für die kontinuierliche Bereitstellung mit GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Benjamin Skierlak\"},{\"@type\":\"Person\",\"name\":\"James Wormwell\"}],\n        \"datePublished\": \"2025-01-28\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","Erfahre, wie du mit dem Aufbau einer robusten Pipeline für die kontinuierliche Bereitstellung in GitLab beginnen kannst. In diesem Artikel findest du Schritt-für-Schritt-Anleitungen, praktische Beispiele und Best Practices.","https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"heroImage":914,"body":918,"authors":919,"updatedDate":898,"date":922,"title":923,"tags":924,"description":915,"category":14},"Die kontinuierliche Bereitstellung ist eine bahnbrechende Praxis, die es Teams ermöglicht, schneller und mit höherem Vertrauen Werte zu schaffen. Das Eintauchen in erweiterte Bereitstellungs-Workflows – wie GitOps, Container-Orchestrierung mit Kubernetes oder dynamische Umgebungen – kann jedoch für Teams, die gerade erst anfangen, einschüchternd sein.\n\nGitLab setzt sich dafür ein, die Bereitstellung nahtlos und skalierbar zu gestalten. Indem wir es den Teams ermöglichen, sich auf die Grundlagen zu konzentrieren, befähigen wir sie, eine starke Basis zu schaffen, die das Wachstum komplexerer Strategien im Laufe der Zeit unterstützt. Dieser Leitfaden enthält wichtige Schritte, um mit der Implementierung der kontinuierlichen Bereitstellung mit GitLab zu beginnen und die Grundlage für deinen langfristigen Erfolg zu schaffen.\n\n## Inhaltsverzeichnis\n\n- [Beginne mit einem Workflow-Plan](#beginne-mit-einem-workflow-plan)\n  - [Artefakt-Management-Strategie](#artefakt-management-strategie)\n    - [Artefakte und Versionsstrategien](#artefakte-und-versionsstrategien)\n    - [Artefaktaufbewahrung erstellen](#artefaktaufbewahrung-erstellen)\n    - [Registrierungszugriff und Authentifizierung](#registrierungszugriff-und-authentifizierung)\n  - [Umgebungsstrategie](#umgebungsstrategie)\n  - [Bereitstellungsziele](#bereitstellungsziele)\n- [Deine CD-Pipeline implementieren](#deine-cd-pipeline-implementieren)\n  - [Ein Schritt-für-Schritt-Beispiel](#ein-schritt-für-schritt-beispiel)\n    - [Voraussetzungen](#voraussetzungen)\n  - [Best Practices](#best-practices)\n- [Skaliere deine Bereitstellungsstrategie](#skaliere-deine-bereitstellungsstrategie)\n  - [Erweiterte Sicherheitsmaßnahmen](#erweiterte-sicherheitsmaßnahmen)\n  - [Progressive Bereitstellungsstrategien](#progressive-bereitstellungsstrategien)\n  - [Überwachung und Optimierung](#überwachung-und-optimierung)\n- [Warum GitLab](#warum-gitlab)\n- [Noch heute starten](#noch-heute-starten)\n\n## Beginne mit einem Workflow-Plan\n\nBevor du dich mit der technischen Implementierung befasst, nimm dir Zeit, um deinen Bereitstellungs-Workflow zu planen. Der Erfolg liegt in der sorgfältigen Planung und dem methodischen Vorgehen.\n\n### Artefakt-Management-Strategie\n\nIm Zusammenhang mit der kontinuierlichen Bereitstellung sind Artefakte die Paket-Ausgaben deines Build-Prozesses, die gespeichert, als Versionen verwaltet und bereitgestellt werden müssen. Darunter fallen:\n\n- Container-Images für deine Anwendungen\n- Pakete\n- kompilierte Binärdateien oder ausführbare Dateien\n- Bibliotheken\n- Konfigurationsdateien\n- Dokumentationspakete\n- andere Artefakte\n\nJede Art von Artefakt spielt eine bestimmte Rolle in deinem Bereitstellungsprozess. Zum Beispiel könnte eine typische Webanwendung Folgendes generieren:\n\n- ein Container-Image für den Backend-Service\n- ein ZIP-Archiv mit kompilierten Frontend-Assets\n- SQL-Dateien für Datenbankänderungen\n- umweltspezifische Konfigurationsdateien\n\nDie effektive Verwaltung dieser Artefakte ist für erfolgreiche Bereitstellungen von entscheidender Bedeutung. Hier erfährst du, wie du das Artefakt-Management angehen kannst.\n\n#### Artefakte und Versionsstrategien\n\nEine Best Practice, um mit einer sauberen Struktur zu beginnen, besteht darin, eine klare Versionsstrategie für deine Artefakte festzulegen. Bei der Erstellung von Releases gilt:\n\n- Verwende eine semantische Versionsverwaltung (major.minor.patch) für Release-Tags\n  - Beispiel: `myapp:1.2.3` für ein stabiles Release\n  - Wichtige Versionsänderungen (2.0.0) für Breaking Changes\n  - Geringfügige Versionsänderungen (1.3.0) für neue Funktionen\n  - Patch-Versionsänderungen (1.2.4) für Fehlerbehebungen\n- Pflege einen „neuesten“ Tag für die neueste stabile Version\n  - Beispiel: `myapp:latest` für automatisierte Bereitstellungen\n- Beziehe Commit-SHA für präzises Versions-Tracking ein\n  - Beispiel: `myapp:1.2.3-abc123f` zum Debuggen\n- Berücksichtige Branch-basierte Tags für Entwicklungsumgebungen\n  - Beispiel: `myapp: feature-user-auth` für Funktionstests\n\n#### Artefaktaufbewahrung erstellen\n\nImplementiere definierte Aufbewahrungsregeln:\n\n- Lege explizite Ablaufzeitrahmen für temporäre Artefakte fest\n- Definiere, welche Artefakte dauerhaft aufbewahrt werden müssen\n- Konfiguriere Bereinigungsrichtlinien zur Verwaltung des Speichers\n\n#### Registrierungszugriff und Authentifizierung\n\nSchütze deine Artefakte mit den richtigen Zugangskontrollen:\n\n- Implementiere persönliche Zugriffstoken für den Entwicklerzugriff\n- Konfiguriere CI/CD-Variablen für die Pipeline-Authentifizierung\n- Richte ordnungsgemäße Zugangsumfänge ein\n\n### Umgebungsstrategie\n\nBetrachte deine Umgebungen frühzeitig, da sie deine gesamte Bereitstellungspipeline prägen:\n\n- Konfigurationen der Entwicklungs-, Staging- und Produktionsumgebung\n- Umgebungsspezifische Variablen und Geheimnisse\n- Zugangskontrollen und Schutzregeln\n- Ansatz zur Nachverfolgung und Überwachung der Bereitstellung\n\n### Bereitstellungsziele\n\nSei dir bewusst, wo und wie du bereitstellen wirst. Diese Entscheidungen sind wichtig und die jeweiligen Vor- und Nachteile sollten berücksichtigt werden:\n\n- Infrastrukturanforderungen (VMs, Container, Cloud-Services)\n- Netzwerkzugriff und Sicherheitskonfigurationen\n- Authentifizierungsmechanismen (SSH-Schlüssel, Zugriffstoken)\n- Überlegungen zur Ressourcenzuweisung und Skalierung\n\nNachdem wir unsere Strategie definiert und grundlegende Entscheidungen getroffen haben, können wir diese Pläne jetzt in eine funktionierende Pipeline umsetzen. Wir werden ein praktisches Beispiel erstellen, das diese Konzepte demonstriert, beginnend mit einer einfachen Anwendung und dem schrittweisen Hinzufügen von Bereitstellungsfunktionen.\n\n## Deine CD-Pipeline implementieren\n\n### Ein Schritt-für-Schritt-Beispiel\n\nSehen wir uns nun die Implementierung einer grundlegenden Pipeline für die kontinuierliche Bereitstellung für eine Webanwendung an. Wir werden eine einfache HTML-Anwendung als Beispiel verwenden, aber diese Prinzipien gelten für jede Art von Anwendung. Wir werden unsere Anwendung auch als Docker Image auf einer einfachen virtuellen Maschine bereitstellen. Somit können wir uns auf ein kuratiertes Bild mit minimalen Abhängigkeiten stützen und sicherstellen, dass keine umgebungsspezifischen Anforderungen unbeabsichtigt eingeführt werden. Wenn wir an einer virtuellen Maschine arbeiten, werden wir die nativen Integrationen von GitLab nicht nutzen, sodass wir zunächst an einem einfacheren, aber weniger skalierbaren Setup arbeiten können.\n\n#### Voraussetzungen\n\nIn diesem Beispiel zielen wir darauf ab, eine Anwendung zu containerisieren, die wir auf einer virtuellen Maschine ausführen, die auf einem Cloud-Anbieter gehostet wird. Wir werden diese Anwendung auch lokal auf unserem Computer testen. Diese Liste der Voraussetzungen wird nur für dieses Szenario benötigt.\n\n##### Einrichtung der virtuellen Maschine\n\n- Stelle eine VM in deinem bevorzugten Cloud-Provider (z. B. GCP, AWS, Azure) bereit\n- Konfiguriere die Netzwerkregeln, um den Zugriff auf die Ports 22, 80 und 443 zu ermöglichen\n- Zeichne die öffentliche IP-Adresse des Computers für die Bereitstellung auf\n\n##### SSH-Authentifizierung einrichten:\n\n- Generiere ein öffentliches/privates Schlüsselpaar für die Maschine\n- Gehe in GitLab zu **Einstellungen > CI/CD > Variablen**\n- Erstelle eine Variable mit dem Namen `GITLAB_KEY`\n- Wähle als Typ „Datei“ (für SSH-Authentifizierung erforderlich)\n- Füge den privaten Schlüssel in das Feld „Wert“ ein\n- Definiere eine BENUTZERVARIABLE; dies ist der Benutzer, der sich anmeldet und die Skripte auf deiner VM ausführt\n\n##### Bereitstellungsvariablen konfigurieren\n\n- Erstelle Variablen für deine Bereitstellungsziele:\n  - `STAGING_TARGET`: deine Staging-Server-IP/-Domäne\n  - `PRODUCTION_TARGET`: deine Produktionsserver-IP/-Domäne\n\n##### Lokales Entwicklungs-Setup\n\n- Installiere Docker auf deinem lokalen Computer, um Bereitstellungen zu testen\n\n##### GitLab-Container-Registry-Zugriff\n\n- Finde deinen Registry-Pfad:\n  - Navigiere zu **Bereitstellen > Container-Registry**\n  - Kopiere den Registry-Pfad (z. B. registry.gitlab.com/group/project)\n- Authentifizierung einrichten:\n  - Gehe zu **Einstellungen > Zugriffstoken**\n  - Erstelle ein neues Token mit Registry-Zugriff\n  - Token-Ablauf: max. 1 Jahr\n  - Speichere das Token sicher\n- Lokalen Registry-Zugriff konfigurieren:\n\n```\ndocker login registry.gitlab.com\n# Der Benutzername, wenn du einen PAT verwendest, ist gitlab-ci-token\n# Passwort: your-access-token\n```\n\n#### 1. Erstelle deine Anwendung\n\nBeginne mit einer grundlegenden Webanwendung. In unserem Beispiel verwenden wir eine einfache HTML-Seite:\n\n```\n\u003C!|||UNTRANSLATED_CONTENT_START|||-- index.html -->\n\u003Chtml>\n  \u003Chead>\n    \u003Cstyle>\n      body {\n        background-color: #171321; /* GitLab dark */\n      }\n    \u003C/style>\n  \u003C/head>\n  \u003Cbody>\n    \u003C!|||UNTRANSLATED_CONTENT_END|||-- Dein Inhalt hier -->\n  \u003C/body>\n\u003C/html>\n```\n\n#### 2. Containerisiere deine Anwendung\n\nErstelle ein Dockerfile, um deine Anwendung zu paketieren:\n\n```\nFROM nginx:1.26.2\nCOPY index.html /usr/share/nginx/html/index.html\n```\n\nDieses Dockerfile:\n\n- Verwendet nginx als Basis-Image für die Bereitstellung von Webinhalten\n- Kopiert deine HTML-Datei an die richtige Stelle in der nginx-Verzeichnisstruktur\n\n#### 3. Richte deine CI/CD-Pipeline ein\n\nErstelle eine `.gitlab-ci.yml`-Datei, um deine Pipeline-Phasen zu definieren:\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n\nstages:\n  - publish\n  - deploy\n```\n\nSehen wir uns das genauer an:\n\n`TAG_LATEST` besteht aus drei Teilen:\n\n- `$CI_REGISTRY_IMAGE` ist der Pfad zum Container-Registry deines Projekts in GitLab\n\nZum Beispiel: `registry.gitlab.com/your-group/your-project`\n\n- `$CI_COMMIT_REF_NAME` ist der Name deiner Branch oder deines Tags\n\nZum Beispiel, wenn du dich im Haupt-Branch befindest: `/main`, und wenn du dich in einem Feature-Branch befindest: `/feature-login`\n\n- `:latest` ist ein festes Suffix\n\nWenn du dich also im Main-Branch befindest, wird `TAG_LATEST` zu: `registry.gitlab.com/your-group/your-project/main:latest`.\n\n`TAG_COMMIT` ist fast identisch, aber anstelle von `:latest` verwendet es: `$CI_COMMIT_SHA`, was die Commit-Kennung ist, zum Beispiel: `:abc123def456`.\n\nFür denselben Commit im Haupt-Branch wird `TAG_COMMIT` zu: `registry.gitlab.com/your-group/your-project/main:abc123def456`.\n\nDer Grund für beides ist, dass `TAG_LATEST` dir eine einfache Möglichkeit bietet, immer die neueste Version zu erhalten, und `TAG_COMMIT` gibt dir eine bestimmte Version, zu der du bei Bedarf zurückkehren kannst.\n\n#### 4. Im Container-Registry veröffentlichen\n\nFüge den Veröffentlichungsauftrag zu deiner Pipeline hinzu:\n\n```\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n```\n\nDieser Job:\n\n- verwendet Docker-in-Docker, um Bilder zu entwickeln\n- erstellt zwei getaggte Versionen deines Bildes\n- authentifiziert sich bei der GitLab-Registrierung\n- pusht beide Versionen in das Registry \n\nJetzt, da unsere Bilder sicher im Registry gespeichert sind, können wir uns darauf konzentrieren, sie in unseren Zielumgebungen bereitzustellen. Beginnen wir mit lokalen Tests, um unser Setup zu validieren, bevor wir zu Produktionsbereitstellungen übergehen.\n\n#### 5. In deiner Umgebung bereitstellen\n\nVor der Bereitstellung in der Produktion kannst du einen lokalen Test durchführen. Wir haben unser Image gerade im GitLab-Repository veröffentlicht, das wir lokal abrufen werden. Wenn du dir über den genauen Pfad nicht sicher bist, navigiere zu **Bereitstellen > Container-Registry**. Du solltest ein Symbol sehen, um den Pfad deines Bildes am Ende der Zeile für das Container-Image zu kopieren, das du testen möchtest.\n\n```\ndocker login registry.gitlab.com \ndocker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n```\n\nAuf diese Weise solltest du über deinen Webbrowser lokal über deine lokale Host-Adresse auf deine Anwendung zugreifen können.\n\nDu kannst jetzt einen Bereitstellungsjob zu deiner Pipeline hinzufügen:\n\n```\ndeploy:\n  stage: deploy\n  image: alpine:latest\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER \n      docker pull $TAG_COMMIT &&\n      docker rm -f myapp || true &&\n      docker run -d -p 80:80 --name myapp $TAG_COMMIT\n```\n\nDieser Job:\n\n- richtet einen SSH-Zugriff auf dein Bereitstellungsziel ein\n- ruft das neueste Image auf\n- entfernt alle vorhandenen Container\n- stellt die neue Version bereit\n\n#### 6. Bereitstellungen nachverfolgen\n\nAktiviere die Nachverfolgung von Bereitstellungen, indem du die Umgebungskonfiguration hinzufügst:\n\n```\ndeploy:\n  environment:\n    name: production\nurl: https://deine-anwendung-url.com\n```\n\nDadurch wird ein Umgebungsobjekt im Abschnitt **Betreiben > Umgebungen** von GitLab erstellt, das Folgendes bietet:\n\n- Bereitstellungsverlauf\n- aktueller Bereitstellungsstatus\n- schneller Zugriff auf deine Anwendung\n\nWährend eine einzelne Umgebungspipeline ein guter Ausgangspunkt ist, müssen die meisten Teams mehrere Umgebungen verwalten, um ordnungsgemäß zu testen und die Staging-Phase durchzuführen. Lass uns unsere Pipeline erweitern, um dieses realistischere Szenario zu bewältigen.\n\n#### 7. Mehrere Umgebungen einrichten\n\nFür eine robustere Pipeline, konfiguriere Staging- und Produktionsbereitstellungen:\n\n```\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\nstaging:\n  stage: staging\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  environment:\n    name: staging\n    url: https://staging.your-app.com\n  # deployment script here\n\nproduction:\n  stage: production\n  rules:\n    - if: $CI_COMMIT_TAG\n  environment:\n    name: production\n    url: https://your-app.com\n  # deployment script here\n```\n\nDieses Setup:\n\n- stellt die Staging-Phase deines Main-Branch bereit\n- verwendet GitLab-Tags, um Produktionsbereitstellungen auszulösen\n- bietet separate Nachverfolgung für jede Umgebung\n\nHier und in unserem nächsten Schritt nutzen wir eine sehr nützliche GitLab-Funktion: Tags. Durch manuelles Erstellen eines Tags im Abschnitt **Code > Tags** wird das `$CI_COMMIT_TAG` erstellt, wodurch wir Jobs entsprechend auslösen können.\n\n#### 8. Automatisierte Versionshinweise erstellen\n\nWir werden die Release-Funktionen von GitLab über unsere CI/CD-Pipeline nutzen. Aktualisiere zuerst deine Phasen in `.gitlab-ci.yml`:\n\n```\nstages:\n\n- publish\n- staging\n- release # New stage for releases\n- version\n- production\n```\n\nAls Nächstes fügst du den Release-Job hinzu:\n\n```\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG                  # Only run when a tag is created\n  script:\n    - echo \"Creating release for $CI_COMMIT_TAG\"\n  release:                                # Release configuration\n    name: 'Release $CI_COMMIT_TAG'\n    description: 'Release created from $CI_COMMIT_TAG'\n    tag_name: '$CI_COMMIT_TAG'           # The tag to create\n    ref: '$CI_COMMIT_TAG'                # The tag to base release on\n```\n\nDu kannst dies verbessern, indem du Links zu deinen Container-Bildern hinzufügst:\n\n```\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release created from $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  assets:\n    links:\n      - name: 'Container Image'\n        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n        link_type: 'image'\n```\n\nFür die automatische Erzeugung von Versionshinweisen basierend auf Commit-Nachrichten:\n\n```\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release notes for version $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  auto_generate_release_notes: true    # Enables automatic notes\n```\n\nFür aussagekräftige automatisierte Versionshinweise:\n\n- herkömmliche Commits verwenden (feat:, fix:, etc.)\n- Issue-Nummern einschließen (#123)\n- Betreff mit leerer Zeile vom Text trennen\n\nWenn du benutzerdefinierte Versionshinweise mit Bereitstellungsinformationen möchtest:\n\n```\nrelease_job:\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    description: './release_notes.md'\n```\n\nNach der Konfiguration werden Releases automatisch erstellt, wenn du ein Git-Tag erstellst. Du kannst sie in GitLab unter **Bereitstellen > Releases** anzeigen.\n\n#### 9. Alles zusammensetzen\n\nSo sieht unsere finale YAML-Datei aus:\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n  STAGING_TARGET: $STAGING_TARGET    # Set in CI/CD Variables\n  PRODUCTION_TARGET: $PRODUCTION_TARGET  # Set in CI/CD Variables\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\n# Build and publish to registry\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n\n# Deploy to staging\nstaging:\n  stage: staging\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET \"\n        docker pull $TAG_COMMIT &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $TAG_COMMIT\"\n  environment:\n    name: staging\n    url: http://$STAGING_TARGET\n\n# Create release\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n       - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: './release_notes.md'\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_TAG'\n    assets:\n      links:\n        - name: 'Container Image'\n          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n          link_type: 'image'\n\n# Version the image with release tag\nversion_job:\n  stage: version\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - docker pull $TAG_COMMIT\n    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n\n# Deploy to production\nproduction:\n  stage: production\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET \"\n        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\"\n  environment:\n    name: production\n    url: http://$PRODUCTION_TARGET\n```\n\nDiese komplette Pipeline:\n\n- veröffentlicht Images im Registry (Main-Branch)\n- stellt das Staging bereit (Main-Branch)\n- erstellt Releases (mit Tags)\n- bietet die Versionsverwaltung von Images mit Release-Tags \n- Stellt die Produktion bereit (für Tags)\n\nHauptvorteile:\n\n- Saubere, reproduzierbare, lokale Entwicklungs- und Testumgebung\n- Klarer Pfad zu Produktionsumgebungen mit Struktur, um Vertrauen in die Bereitstellung aufzubauen\n- Muster zur Wiederherstellung nach unerwarteten Fehlern usw.\n- Bereit, komplexere Bereitstellungsstrategien zu skalieren/zu übernehmen\n\n### Best Practices\n\nWährend der gesamten Implementierung solltest du diese Grundsätze einhalten:\n\n- Dokumentiere alles, von der variablen Nutzung bis hin zu Bereitstellungsverfahren\n- Nutze die integrierten Funktionen von GitLab (Umgebungen, Releases, Registry)\n- Implementiere ordnungsgemäße Zugriffskontrollen und Sicherheitsmaßnahmen\n- Sorge für Ausfälle mit robusten Rollback-Verfahren vor\n- Halte deine Pipeline-Konfigurationen SAUBER (wiederhole dich nicht)\n\n## Skaliere deine Bereitstellungsstrategie\n\nWie geht es weiter? Hier sind einige Aspekte, die du berücksichtigen solltest, wenn deine kontinuierliche Bereitstellungsstrategie ausgereift ist.\n\n### Erweiterte Sicherheitsmaßnahmen\n\nErhöhe die Sicherheit durch:\n\n- Geschützte Umgebungen mit eingeschränktem Zugang\n- Erforderliche Genehmigungen für Produktionseinsätze\n- Integriertes Sicherheitsscannen\n- Automatisierte Schwachstellenbewertungen\n- Branch-Schutzregeln für einsatzbedingte Änderungen\n\n### Progressive Bereitstellungsstrategien\n\nImplementiere erweiterte Bereitstellungsstrategien:\n\n- Feature-Flags für kontrollierte Rollouts\n- Canary-Bereitstellungen zur Risikominderung\n- Blaugrüne Bereitstellungsstrategien\n- A/B-Testfähigkeiten\n- Dynamisches Umgebungsmanagement\n\n### Überwachung und Optimierung\n\nEtabliere robuste Überwachungspraktiken:\n\n- Verfolge Bereitstellungsmetriken nach\n- Richte eine Leistungsüberwachung ein\n- Konfiguriere Bereitstellungswarnungen\n- Richte Bereitstellungs-SLOs ein\n- Regelmäßige Pipeline-Optimierung\n\n## Warum GitLab\n\nDurch die kontinuierlichen Bereitstellungsfunktionen ist GitLab eine herausragende Wahl für moderne Bereitstellungsworkflows. Die Plattform zeichnet sich dadurch aus, dass sie den Weg vom Code bis zur Produktion optimiert und eine integrierte Container-Registrierung, ein Umgebungsmanagement und eine Nachverfolgung der Bereitstellung innerhalb einer einzigen Benutzeroberfläche bietet. Die umgebungsspezifischen Variablen von GitLab, die Approval-Gates für die Bereitstellung und die Rollback-Funktionen bieten die Sicherheit und Kontrolle, die für Produktionsbereitstellungen erforderlich sind, während Funktionen wie Review-Apps und Feature-Flags progressive Bereitstellungsansätze ermöglichen. Als Teil der kompletten DevSecOps-Plattform von GitLab lassen sich diese CD-Funktionen nahtlos in deinen gesamten Software-Lebenszyklus integrieren.\n\n## Noch heute starten\n\nDer Weg zur kontinuierlichen Bereitstellung ist eine Evolution, keine Revolution. Beginne mit den Grundlagen, baue eine solide Grundlage auf und integriere nach und nach erweiterte Funktionen, wenn die Anforderungen deines Teams wachsen. GitLab bietet die Tools und die Flexibilität, um dich in jeder Phase dieser Reise zu unterstützen, von deiner ersten automatisierten Bereitstellung bis hin zu komplexen Bereitstellungspipelines für mehrere Umgebungen.\n\n> Melde dich für eine [kostenlose, 60-tägige Testversion von GitLab Ultimate](https://about.gitlab.com/free-trial/devsecops/) an, um noch heute mit der kontinuierlichen Bereitstellung zu beginnen.",[920,921],"Benjamin Skierlak","James Wormwell","2025-01-28","Vom Code bis zur Produktion: Ein Leitfaden für die kontinuierliche Bereitstellung mit GitLab",[749,110,750,14,678],{"slug":926,"featured":6,"template":681},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","content:de-de:blog:from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab","de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"_path":932,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":933,"content":939,"config":944,"_id":946,"_type":16,"title":947,"_source":18,"_file":948,"_stem":949,"_extension":21},"/de-de/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"title":934,"description":935,"ogTitle":934,"ogDescription":935,"noIndex":6,"ogImage":936,"ogUrl":937,"ogSiteName":716,"ogType":717,"canonicalUrls":937,"schema":938},"Erste Schritte mit GitLab: So importierst du deine Projekte in GitLab","Erfahre, wie du deine Projekte aus verschiedenen Quellen wie Bitbucket, Gitea, GitHub und GitLab Self-Managed importierst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097248/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097247785.png","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab: So importierst du deine Projekte in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-28\",\n      }",{"title":934,"description":935,"authors":940,"heroImage":936,"date":922,"body":942,"category":14,"tags":943},[941],"Abubakar Siddiq Ango","*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.*\n\nUm deine DevSecOps-Plattform von GitLab so gut wie möglich zu nutzen, ist es wichtig zu wissen, wie du Projekte in GitLab importieren kannst. Du hast bereits dein [Konto eingerichtet](https://university.gitlab.com/pages/getting-started), Benutzer(innen) eingeladen und sie entsprechend deines Anwendungsfalls oder deiner Teamstruktur [organisiert](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/). Nun musst du deine bestehenden Projekte in GitLab importieren und mit der Zusammenarbeit beginnen. Diese Projekte können lokale Dateien auf deinem Computer sein oder auf einer anderen Plattform für Quellcodeverwaltung gehostet sein. Sehen wir uns an, welche Möglichkeiten es gibt.\n\n## Lokale Projektdateien importieren\n\nDu möchtest nicht jedes Mal bei Null anfangen, wenn du ein Projekt importierst. Befolge diese Schritte, um bestehende Projekte oder Anwendungen mit oder ohne Versionskontrolle in GitLab nutzen zu können.\n\n### Git-Projekt\n\n1. Wenn Git bereits in deinem lokalen Projekt [initialisiert wurde](https://docs.gitlab.com/ee/topics/git/commands.html#git-init), erstellst du ein neues Projekt in GitLab und rufst die SSH- oder HTTPS-URL ab, indem du oben rechts in deiner Projektseite auf die Schaltfläche **Code** klickst.\n\n![Ein neues Projekt in GitLab mit SSH/HTTPS-URLs erstellen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097254/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097252717.png)\n\n2. Wechsele zu deinem Terminal und stelle sicher, dass du dich in deinem Projektordner befinden:\n\n```bash  \ncd /project_folder  \n```\n\n3. Sichere deinen bestehenden [Git-Origin](https://git-scm.com/book/de/v2/Git-Grundlagen-Mit-Remotes-arbeiten):\n\n```bash\n\ngit remote rename origin old-origin\n\n```\n\n4. Füge die [GitLab-Remote-URL](https://git-scm.com/book/de/v2/Git-Grundlagen-Mit-Remotes-arbeiten) für den neuen Origin hinzu, wenn du SSH verwendest:\n\n```bash  \ngit remote add origin [git@gitlab.com](mailto:git@gitlab.com):gitlab-da/playground/abubakar/new-test-repo.git  \n```\n\nUnd für HTTPS: \n\n```bash  \ngit remote add origin https://gitlab.com/gitlab-da/playground/abubakar/new-test-repo.git  \n```\n\n5. Pushe dann alle bestehenden [Branches](https://docs.gitlab.com/ee/user/project/repository/branches/) und [Tags](https://docs.gitlab.com/ee/user/project/repository/tags/) zu GitLab:\n\n```bash  \ngit push --set-upstream origin --all  \ngit push --set-upstream origin --tags  \n```\n\nAlle deine Dateiprojektdateien, Branches und Tags werden an GitLab übertragen und du kannst mit der Zusammenarbeit beginnen.\n\n### Nicht-Git-Projekt\n\nWenn du Git in deinem Projekt nicht initiiert hast, musst du Git vorher initialisieren, vorhandene Dateien commiten und wie folgt in GitLab pushen:\n\n```bash  \ngit init --initial-branch=main  \ngit remote add origin git@gitlab.com:gitlab-da/playground/abubakar/new-test-repo.git  \ngit add .  \ngit commit -m \"Initial commit\"  \ngit push --set-upstream origin main  \n```\n\n## Import aus Online-Quellen\n\nWenn du dein Projekt auf GitLab.com oder anderen Plattformen hast und es in eine andere GitLab-Instanz (wie eine Self-Managed-Instanz) oder von einer anderen Plattform zu GitLab.com verschieben möchtest, bietet GitLab die Funktion zum Importieren von Projekten, wenn du ein neues Projekt erstellen möchtest.\n\n![Bildschirm „Neues Projekt erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097252718.png)\n\nBeim Importieren eines Projekts werden die Projektdateien und (je nach Quelle) einige andere Komponenten des Projekts migriert. Du kannst aus verschiedenen Quellen importieren, darunter Bitbucket, GitHub, Gitea und GitLab-Instanzen. Importquellen sind auf GitLab.com standardmäßig aktiviert, müssen aber von einem bzw. einer Administrator(in) [für Self-Managed aktiviert werden](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources). In den folgenden Abschnitten sehen wir uns einige dieser Quellen an.\n\n![Projekt aus Drittquellen importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097252719.png)\n\n## GitLab-Quellen\n\nDu kannst Projekte von GitLab.com und GitLab-Self-Managed-Instanzen mit der Funktion „Projekt exportieren“ in den Einstellungen eines Projekts exportieren.\n\n![Bildschirm „Projekt exportieren“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097252720.png)\n\nDas geht so:\n\n- Gehe zu den Einstellungen deines Projekts und klicke in den Bereich **Allgemein**.\n- Scrolle zum Abschnitt **Erweitert**.\n- Wähle **Projekt exportieren** aus.\n- Es wird eine Benachrichtigung angezeigt, die sagt: „Projekt-Export gestartet. Ein Download-Link wird per E-Mail verschickt und auf dieser Seite bereitgestellt.“\n- Nachdem der Export generiert wurde, kannst du dem Link in der E-Mail folgen oder die Seite mit den Projekteinstellungen aktualisieren, um die Option„ Export herunterladen “anzuzeigen.\n\n### Projekt importieren\n\n![Ein exportiertes GitLab-Projekt importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097252722.png)\n\n- Klicke in deiner Ziel-GitLab-Instanz auf die Schaltfläche **Neues Projekt**.  \n- Wähle **Projekt importieren** aus und klicke in der Liste der Importquellen auf **GitLab-Export**.  \n- Gib einen Projektnamen an und wähle die Exportdatei aus. Klicke dann auf **Projekt importieren**.  \n- Es wird die Seite „Import wird durchgeführt“ angezeigt. Nach Abschluss wirst du zum importierten Projekt weitergeleitet.\n\nAbhängig von der Größe deines Projekts kann der Import unterschiedlich lange dauern. Beachte bitte, dass nicht alles in einem Projekt exportiert werden kann und einige Dinge nach dem Import anders sein können. In der [Dokumentation](https://docs.gitlab.com/ee/user/project/settings/import_export.html#export-a-project-and-its-data) findest du weitere Informationen zu den Einschränkungen. Wenn du eine ganze Gruppe anstelle einzelner Projekte migrieren möchtest, empfehlen wir dir die [Direct-Transfer-Methode](https://docs.gitlab.com/ee/user/group/import/index.html). Dabei wird eine Kopie einer ganzen Gruppe erstellt.\n\n## Drittanbieter\n\nGitLab unterstützt den Import von Bitbucket Cloud, Bitbucket Server, FogBugz, Gitea und GitHub. Der Import ist für alle unterstützten Drittpartner ähnlich, der Hauptunterschied liegt dabei in der Authentifizierungsmethode. Sehen wir uns einige der Möglichkeiten an.\n\n### GitHub\n\n![Bildschirm „Authentifizierung mit GitHub“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097252723.png)\n\nEs gibt drei Methoden, um GitHub-Projekte in GitLab zu importieren:\n\n- [Mit GitHub OAuth](https://docs.gitlab.com/ee/user/project/import/github.html#use-github-oauth)\n- [Mit einem persönlichen GitHub-Zugriffstoken](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token)\n- [Über die API](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api)\n\nDer Import mit GitHub OAuth und dem persönlichen Zugriffstoken ist ähnlich. Der Unterschied liegt darin, wie du GitLab autorisierst, auf deine Repositories zuzugreifen. Die OAuth-Methode ist einfacher, da du nur auf die Schaltfläche „Mit GitHub autorisieren“ klicken musst und du zu deinem GitHub-Konto weitergeleitet wirst, um die Verbindung zu autorisieren. Dann wird die Liste deiner Projekte geladen und du kannst auswählen, welche du importieren möchtest.\n\n![Bildschirm „Repositories aus GitHub importieren“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097252725.png)\n\nAlternativ kannst du ein persönliches GitHub-Zugriffstoken generieren, den Geltungsbereich `repo` und `read:org` auswählen und es dann auf der Seite „Import“ bereitstellen. Für API-Importe kannst du dasselbe persönliche Zugriffstoken mit unseren [Import-REST-API-Endpunkten](https://docs.gitlab.com/ee/api/import.html#import-repository-from-github) in deinem Skript oder deiner Anwendung verwenden.\n\nIn dieser Demo erklärt GitLabs Senior Developer Advocate Fernando Diaz, wie man ein Projekt mit der OAuth-Methode von GitHub importiert:\n\n\u003C!-- blank line -->  \n\u003Cfigure class=\"video_container\"> \n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=esF6wbz2j2JlhDVL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>  \n\u003C/figure>\n\u003C!-- blank line -->\n\nIn der [Importdokumentation](https://docs.gitlab.com/ee/user/project/import/github.html) erfährst du mehr über Voraussetzungen, bekannte Probleme, den Import von GitHub Enterprise sowie andere wichtige Themen.\n\n### Bitbucket\n\nDer Import von Projekten aus Bitbucket ähnelt dem Import von GitHub. Während OAuth für [Bitbucket Cloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html), die SaaS-Version von Bitbucket, verwendet werden kann, musst du für [Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html), die selbst gehostete Version für Unternehmen, eine URL, einen Benutzernamen und ein persönliches Zugriffstoken angeben. Wenn du auf der Seite „Import“ auf die Option „Bitbucket Cloud“ klickst, gelangst du automatisch zur Atlassian-Authentifizierung für Bitbucket.\n\n![Projekt aus Bitbucket importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097252726.png)\n\nDu kannst Bitbucket-Projekte auch mit der [Import-API von GitLab](https://docs.gitlab.com/ee/api/import.html) importieren.\n\n### Gitea\n\n![Projekt aus Gitea importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097252727.png)\n\nFür den Import von Projekten aus [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html) musst du ein [persönliches Zugriffstoken](https://docs.gitea.com/next/development/api-usage#authentication-via-the-api) auf der Gitea-Plattform erstellen und es zusammen mit der Gitea-Server-URL auf der GitLab-Importseite angeben. OAuth-Authentifizierung wird nicht unterstützt. \n\n### Generisches Remote-Git-Repository\n\n![Projekt aus Remote-Git-Repository importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097252728.png)\n\nWenn dein Git-Anbieter nicht unterstützt wird oder der Import mit den unterstützten Methoden nicht möglich ist, kannst du ein Repository mit der zugänglichen URL `https://` oder `git://` importieren. Wenn sie nicht öffentlich zugänglich ist, gibst du die URL des Repositorys zusammen mit dem Benutzernamen und dem Passwort (oder gegebenenfalls dem Zugriffstoken bei Multi-Faktor-Authentifizierung) an.\n\nDiese Methode kann auch verwendet werden, um eine Kopie eines Remote-Projekts beizubehalten und synchron zu halten, d. h. zu [spiegeln](https://docs.gitlab.com/ee/user/project/repository/mirror/). Mit der Spiegelung kannst du Repositories auf verschiedenen Plattformen verwalten und synchronisieren. Dies kann gewünscht werden, um den privaten und den öffentlichen Zugang zum Projekt zu trennen und gleichzeitig sicherzustellen, dass beide Enden die gleiche Kopie haben, was beim Open-Sourcing interner Projekte nützlich ist. Es kann auch bei der Zusammenarbeit mit Auftragnehmern verwendet werden, wenn beide Parteien unterschiedliche Plattformen verwenden und der Zugriff auf die Codebase auf beiden Seiten erforderlich ist. \n\n## Zusammenfassung\n\nDer Import und die Migration zwischen GitLab-Instanzen und aus anderen Quellen ist ein wichtiger Prozess, der gut geplant werden muss. So kann man klar darlegen, was mit welcher Methode importiert wird. Während bei den meisten Methoden von Drittanbietern Projektelemente importiert werden, einschließlich Dateien, Tickets und Merge Requests, sind bei einigen Methoden Probleme und Einschränkungen bekannt. Der [Abschnitt „GitLab-Import“](https://docs.gitlab.com/ee/user/project/import/) der Dokumentation enthält detaillierte Informationen zu allen unterstützten Methoden, damit du deine Migration entsprechend planen kannst.\n\n> #### Möchtest du dein Lernen auf ein neues Niveau heben? [Registriere dich für die englischsprachigen Kurse der GitLab University](https://university.gitlab.com/). Du kannst auch sofort mit [einer kostenlosen 60-tägigen Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/devsecops/) loslegen.\n",[14,678,727],{"slug":945,"featured":6,"template":681},"getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","content:de-de:blog:getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","Getting Started With Gitlab How To Import Your Projects To Gitlab","de-de/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","de-de/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"_path":951,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":952,"content":958,"config":965,"_id":967,"_type":16,"title":968,"_source":18,"_file":969,"_stem":970,"_extension":21},"/de-de/blog/getting-started-with-gitlab-how-to-manage-users",{"ogTitle":953,"schema":954,"ogImage":955,"ogDescription":956,"ogSiteName":716,"noIndex":6,"ogType":717,"ogUrl":957,"title":953,"canonicalUrls":957,"description":956},"GitLab Benutzerverwaltung: Erste Schritte einfach erklärt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab: Benutzerverwaltung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-14\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097273/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097273817.png","Wir zeigen dir, wie du die GitLab Benutzerverwaltung nutzt. ✓ Projektmitglieder ✓ Gruppen ✓ Rollen ✓ Berechtigungen ➤ Jetzt mit GitLab loslegen!","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users",{"heroImage":955,"body":959,"authors":960,"updatedDate":898,"date":961,"title":962,"tags":963,"description":964,"category":14},"*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.*\n\nDie Gewährleistung einer sicheren, konformen und kollaborativen Umgebung beginnt mit der grundlegendsten Aufgabe: der Verwaltung von Benutzer(inne)n. In diesem Tutorial zeigen wir dir, wie du Projektmitglieder einrichtest, Rollen und Berechtigungen zuweist und Gruppen und Untergruppen erstellst.\n\nHinweis: Um diesem Lernprogramm folgen zu können, solltest du ein GitLab-Konto besitzen, entweder über GitLab.com oder die Self-Managed-Instanz deines Unternehmens. Wenn du Hilfe brauchst, besuche unseren Grundlagenbereich der [GitLab University](https://university.gitlab.com/). (Die Kurse sind aktuell nur in englischer Sprache verfügbar.)\n\nLos geht’s.\n\n## Inhaltsverzeichnis\n\n- [Projektmitglieder](#projektmitglieder)\n- [Gruppenmitgliedschaften](#gruppenmitgliedschaften)\n  - [Untergruppen erstellen](#untergruppen-erstellen)\n  - [Gruppen verwalten](#gruppen-verwalten)\n- [Mehr erfahren](#mehr-erfahren)\n\nWenn du GitLab-Benutzer(innen) anlegst, haben sie nur Zugriff auf [ihre privaten und öffentlichen Projekte sowie auf Projekte mit interner Sichtbarkeit](https://docs.gitlab.com/ee/user/public_access.html) (nur in englischer Sprache verfügbar). Für dieses Tutorial ist dein Projekt streng geheim und nur eingeladene Mitglieder sollten darauf Zugriff haben – mit unterschiedlichen Berechtigungen. Um dies sicherzustellen, kannst du Benutzer(innen) als [Mitglieder des Projekts](https://docs.gitlab.com/ee/user/project/members/) (nur in englischer Sprache verfügbar) einladen.\n\n## Projektmitglieder\n\n![Anzeige der Projektmitglieder](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097278487.png)\n\nGitLab-Benutzer(innen) können zu einem Projekt eingeladen werden und [bekommen eine Rolle zugewiesen](https://docs.gitlab.com/ee/user/permissions.html) (nur in englischer Sprache verfügbar), die bestimmt, was sie in dem Projekt tun können. Projekteigentümer(innen) können andere Benutzer(innen) als Betreuer(innen) mit Verwaltungsaufgaben betrauen. Diese können fast dieselben Aufgaben ausführen wie Projekteigentümer(innen) , abgesehen von Änderungen am Projekt, wie z. B. das Löschen, Archivieren oder Übertragen eines Projekts.\n\n![Bildschirm zum Einladen von Mitgliedern](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097278487.png)\n\n[Betreuer(innen)](https://docs.gitlab.com/ee/user/permissions.html#roles) (nur in englischer Sprache verfügbar) des Projekts können andere Mitglieder als Entwickler(innen) einladen. Diese haben dann Zugriff auf alle Funktionen zum Entwickeln, Erstellen und Bereitstellen von Software. Benutzer(innen), die keine Entwickler(innen) sind, aber Zugang zum Projektmanagement benötigen, können in einer [Planungsrolle](https://about.gitlab.com/de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/), als Reporter(innen) oder Gäste mit unterschiedlichen Berechtigungsstufen in das Projekt eingeladen werden. Mit diesen Rollen lässt sich mit [geschützten Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) (nur in englischer Sprache verfügbar) auch festlegen, wer Änderungen an bestimmten Branches vornehmen darf.\n\nWenn du mit Auftragnehmer(innen) zusammenarbeitest oder deine Nutzung erfordert, dass die Benutzerberechtigungen verfallen können, kannst du ein Ablaufdatum festlegen, nach dem Benutzer(innen) den Zugriff auf das Projekt verlieren. Projektmitglieder können basierend auf der [Art ihrer Mitgliedschaft](https://docs.gitlab.com/ee/user/project/members/#membership-types) (nur in englischer Sprache verfügbar) auch als direkte oder indirekte Mitglieder identifiziert werden. Direkte Mitglieder werden direkt in das Projekt eingeladen, während indirekte Mitglieder oft aus einer [GitLab-Gruppe](https://docs.gitlab.com/ee/user/group/) (nur in englischer Sprache verfügbar), zu der ein Projekt gehört, übernommen werden.\n\nSehen wir uns nun die Gruppenmitgliedschaften an.\n\n## Gruppenmitgliedschaften\n\nGruppen in GitLab können eine oberste Ebene sein, die im Stammverzeichnis einer GitLab-Instanz erstellt wird, wie z. B. [gitlab.com/gitlab-org](http://gitlab.com/gitlab-org). Dies ist eine übergeordnete Gruppe, die zum Organisieren anderer Untergruppen wie [gitlab.com/gitlab-org/charts](http://gitlab.com/gitlab-org/charts) verwendet wird. Gruppen sind auch dann nützlich, wenn du nur ein Projekt hast.\n\nGruppen können für verschiedene Zwecke verwendet werden:\n\n- Organisation ähnlicher oder verwandter Projekte  \n- Organisation der Benutzer(innen) in Gruppen zur besseren Teamkoordination\n\nWenn du Gruppen zur Organisation von Benutzer(inne)n verwendest, kannst du Teams in Gruppen organisieren und [eine Gruppe zu einem Projekt einladen](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html) (nur in englischer Sprache verfügbar) und allen Mitgliedern des Teams die gleiche Rolle geben. Du kannst eine `dev`-Gruppe für die Entwickler(innen) des Teams haben, eine `pm`-Gruppe für die Projektmanager(innen) und eine `leads`-Gruppe für die Teamleiter(innen). Wenn du die Gruppen einlädst, kann `dev` die Rolle Entwickler(in), `pm` die Rolle Planer(in) und `leads` die Rolle Betreuer(in) zugewiesen werden.\n\n!]Bildschirm zum Einladen von Gruppen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175686/Blog/ce7ulc2obua9zaz2zjsb.png)\n\nIn jeder Gruppe können Mitglieder hinzugefügt oder entfernt werden, ohne dass die Projektberechtigungen aktualisiert werden müssen. Das ist besonders nützlich, wenn dein Team auf mehrere Projekte angewachsen ist. Es gibt jedoch [bewährte Methoden](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html#setting-up-a-group-for-collaboration) (nur in englischer Sprache verfügbar) für die Verwendung von Gruppen für die Zusammenarbeit.\n\nEin weiterer hilfreicher Aspekt bei der Organisation von Benutzer(inne)n in Gruppen ist, dass du die gesamte Gruppe in Tickets, Merge Requests oder Kommentaren [erwähnen](https://docs.gitlab.com/ee/user/discussions/#mentions) (nur in englischer Sprache verfügbar) kannst. Das vereinfacht den Informationsaustausch mit dem gesamten Team.\n\n### Untergruppen erstellen\n\n[Untergruppen](https://docs.gitlab.com/ee/user/group/subgroups/) (nur in englischer Sprache verfügbar) können verwendet werden, um die Benutzer(innen) in einer Gruppe weiter zu unterteilen. Du kannst bis zu 20 ineinander verschachtelte Untergruppen hinzufügen. Benutzer(innen) in einer Untergruppe erben die Rechte aus der übergeordneten Gruppe. Wenn du jemandem in einer Untergruppe eine höhere Rolle zuweisen möchtest, als er/sie geerbt hat, musst du ihn/sie [in die Untergruppe mit der neuen höheren Rolle einladen](https://docs.gitlab.com/ee/user/group/subgroups/#override-ancestor-group-membership) (nur in englischer Sprache verfügbar). Hinweis: Du kannst ihm/ihr in der Untergruppe keine untergeordnete Rolle zuweisen.\n\n### Gruppen verwalten\n\nGruppeneigentümer(innen) haben mehrere Verwaltungsoptionen, um festzulegen, wie Benutzer(innen) in einer Gruppe funktionieren. Du kannst z. B. festlegen, wie eine Person den Zugang zu einer Gruppe anfordert, [Gruppenerwähnungen](https://docs.gitlab.com/ee/user/group/manage.html#disable-group-mentions) aktivieren/deaktivieren, den [Zugang einschränken](https://docs.gitlab.com/ee/user/group/manage.html#turn-on-restricted-access) oder [Benutzer(innen) moderieren](https://docs.gitlab.com/ee/user/group/moderate_users.html), um nur einige Optionen zu nennen. Eine interessante neue Funktion, die sich zum Zeitpunkt der Veröffentlichung dieses Artikels noch in der Entwicklung befindet, ist die [automatische Löschung von ruhenden Benutzer(innen)](https://docs.gitlab.com/ee/user/group/moderate_users.html#automatically-remove-dormant-members) nach einem Minimum von 90 Tagen und einem Maximum von fünf Jahren. Dies wird dazu beitragen, die Gruppen übersichtlich zu halten und die Freigabe von Lizenzplätzen besser zu verwalten. (Alle verlinkten Artikel in diesem Absatz sind nur in englischer Sprache verfügbar.)\n\n## Mehr erfahren\n\nDas Verwalten von Benutzer(inne)n in GitLab hängt von deinem Anwendungsfall ab. Wenn dein Unternehmen größer ist und fortgeschrittene Workflows und Benutzerverwaltung benötigt, bietet GitLab fortschrittlichere Möglichkeiten zur Verwaltung von [Unternehmensbenutzern](https://docs.gitlab.com/ee/user/enterprise_user/index.html) (nur in englischer Sprache verfügbar). Du kannst auch weitere Optionen zum [Verwalten deines Unternehmens](https://docs.gitlab.com/ee/topics/set_up_organization.html) (nur in englischer Sprache verfügbar) erkunden. Mit [GitLab Ultimate](https://about.gitlab.com/de-de/pricing/ultimate/) erhältst du mehr Granularität und weitere Compliance-Funktionen.\n\n> #### Möchtest du dein Lernen auf ein neues Niveau heben? [Registriere dich für die englischsprachigen Kurse der GitLab University](https://university.gitlab.com/). Du kannst auch sofort loslegen mit [einer kostenlosen 60-tägigen Testversion von GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F).",[941],"2025-01-14","Benutzerverwaltung mit GitLab: Erste Schritte",[727,750,678,836,14],"Erfahre, wie du Benutzer(innen) mithilfe von Gruppen, Rollen und Berechtigungen verwalten kannst. Erkunde die Einrichtung einer sicheren Zusammenarbeit mit dem richtigen Projektzugang.",{"slug":966,"featured":92,"template":681},"getting-started-with-gitlab-how-to-manage-users","content:de-de:blog:getting-started-with-gitlab-how-to-manage-users.yml","Getting Started With Gitlab How To Manage Users","de-de/blog/getting-started-with-gitlab-how-to-manage-users.yml","de-de/blog/getting-started-with-gitlab-how-to-manage-users",{"_path":972,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":973,"content":979,"config":986,"_id":988,"_type":16,"title":989,"_source":18,"_file":990,"_stem":991,"_extension":21},"/de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"title":974,"description":975,"ogTitle":974,"ogDescription":975,"noIndex":6,"ogImage":976,"ogUrl":977,"ogSiteName":716,"ogType":717,"canonicalUrls":977,"schema":978},"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","\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":974,"description":975,"authors":980,"heroImage":976,"date":982,"body":983,"category":14,"tags":984,"updatedDate":985},[981],"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 60-tägige 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",[110,727,14,750,678,879],"2025-06-06",{"slug":987,"featured":92,"template":681},"data-driven-devsecops-exploring-gitlab-insights-dashboards","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":993,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":994,"content":1000,"config":1009,"_id":1011,"_type":16,"title":1012,"_source":18,"_file":1013,"_stem":1014,"_extension":21},"/de-de/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"title":995,"description":996,"ogTitle":995,"ogDescription":996,"noIndex":6,"ogImage":997,"ogUrl":998,"ogSiteName":716,"ogType":717,"canonicalUrls":998,"schema":999},"Tutorial: Migration von Google Cloud Source Repositories zu GitLab","Google stellt Cloud Source Repositories ein. Hier erfährst du, wie du ein CSR-Quellcode-Repository zu GitLab migrierst und erhältst auch einige tolle Tipps und Tricks.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097739/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2813%29_1zdtbfPDHZVe6JC2AbdHmb_1750097738370.png","https://about.gitlab.com/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Migration von Google Cloud Source Repositories zu GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Regnard Raquedan\"}],\n        \"datePublished\": \"2024-08-28\",\n      }",{"title":995,"description":996,"authors":1001,"heroImage":997,"date":1004,"body":1005,"category":14,"tags":1006,"updatedDate":1008},[1002,1003],"Tsukasa Komatsubara","Regnard Raquedan","2024-08-28","Durch die [Einstellung der Cloud Source Repositories](https://cloud.google.com/source-repositories/docs/release-notes) von Google (CSR) mussten Entwicklungsteams eine voll funktionsfähige Alternative für ihre Quellcode-Repositories finden. GitLab, ein [Google-Cloud-Technologiepartner](https://cloud.google.com/find-a-partner/partner/gitlab-inc), ist aufgrund seiner umfassenden DevSecOps-Funktionen eine gute Wahl.\n\nIn diesem Tutorial erfährst du, wie du nahtlos von CSR zu GitLab übergehst, egal, ob du GitLab.com oder eine Self-Managed-Instanz auf Google Cloud verwendest.\n\n## Warum GitLab?\nDer Übergang von Google Cloude Source Repositories zu GitLab ist ein empfohlener Schritt. Als strategischer Partner von Google Cloud lässt sich GitLab nahtlos und einfach in bestehende Infrastruktur integrieren und bringt den Kund(inn)en auf folgende Weise einen Mehrwert:\n- **Vereinheitlichte DevSecOps-Plattform**\n    - Konsolidiere deinen gesamten Entwicklungszyklus in einer einzigen Anwendung – von der Planung bis zur Überwachung. Vermeide ein Überangebot von Tools und steigere die Produktivität signifikant.\n- **Nahtlose Google-Cloud-Integration**\n    - Verbinde dich ganz einfach mit GKE, Cloud Build und Cloud Storage. So stellst du eine reibungslose Migration und einen effizienten Betrieb im Google-Cloud-Ökosystem sicher.\n- **Erweiterte CI/CD-Funktionen**\n    - Nutze [Auto-DevOps](https://docs.gitlab.com/ee/topics/autodevops/), um alles vom Sicherheitsscan bis zur Bereitstellung zu automatisieren und deine Entwicklungszyklen zu beschleunigen.\n- **Branchenführende KI-Programmierunterstützung**\n    - Profitiere von der integrierten KI-gestützten Entwicklung mit [GitLab Duo](https://about.gitlab.com/gitlab-duo/) und ermögliche eine sichere und effiziente Programmierumgebung.\n\n## Voraussetzungen\n\nBevor du die Migration startest, stelle Folgendes sicher:\n- GitLab-Konto: Richte dein Konto auf GitLab.com oder in einer selbst gehosteten Instanz ein.\n- GitLab-Projekt: Erstelle ein leeres Projekt in GitLab, in das das CSR-Repository migriert wird.\n\n## Migrationsschritte\n\n1. Erstelle ein leeres GitLab-Projekt: Dies dient als Ziel für dein migriertes CSR-Repository. Lasse dieses Projekt vorerst leer.\n2. Generiere einen persönlichen Zugriffstoken (PAT): Gehe zu den GitLab-Einstellungen und [generiere einen PAT](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html), wenn die Bereiche `read_repository` und `write_repository` aktiviert sind. Dieser Token wird verwendet, um deine Git-Vorgänge während des Migrationsprozesses zu authentifizieren.\n3. Bearbeite den Code im Cloud Shell Editor: Öffne in deinem CSR-Repository den Cloud Shell Editor, indem du auf die Schaltfläche „Code bearbeiten“ klickst. Um fortzufahren, musst du die Cloud-Shell autorisieren und „Trust repo“ auswählen.\n\n![Google Cloud Shell Editor](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097750517.png)\n\n4. Überprüfe den Git-Status: Führe `git status` in der Cloud-Shell aus, um den aktuellen Branch zu überprüfen und sicherzustellen, dass alles in Ordnung ist, bevor du zu GitLab pusht.\n\n![Git-Status prüfen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097750518.png)\n\n5. Richte das Remote-Repository ein: Füge dein GitLab-Projekt als Remote-Repository hinzu, indem du Folgendes ausführst:\n\n```\ngit remote add origin [GITLAB_PROJECT_URL]\n\n```\n\n6. Ersetze `[GITLAB_PROJECT_URL]` durch die tatsächliche URL deines GitLab-Projekts.\nPushe zu GitLab: Pushe schließlich dein lokales Repository zu GitLab, indem du Folgendes ausführst: \n\n```\ngit push -u origin [BRANCH_NAME]\n\n```\n\n7. Ersetze `[BRANCH_NAME]` durch den aktuellen Branch-Namen, den du bereits angegeben hast.\nWenn du dazu aufgefordert wirst, verwende deinen GitLab-Benutzernamen und den PAT als Passwort, um dich zu authentifizieren und den Push abzuschließen.\n\n## Tipps und Tricks\n\n- Erstelle ein Backup, bevor du beginnst: Sichere immer dein CSR-Repository, bevor du mit dem Migrationsprozess beginnst.\n- Teste nach der Migration: Stelle sicher, dass alle Aspekte des Repositorys, einschließlich Branches und CI/CD-Pipelines, wie erwartet in GitLab funktionieren.\n- Nutze die Funktionen von GitLab: Nutze die erweiterten DevSecOps-Funktionen von GitLab wie [KI](https://about.gitlab.com/gitlab-duo/), [CI/CD](https://docs.gitlab.com/ee/ci/) und [Enterprise Agile Planning](https://about.gitlab.com/solutions/agile-delivery/), um deinen Entwicklungs-Workflow zu verbessern.\n\nDer Übergang von Google Cloud Source Repositories zu GitLab ist einfach und bietet mehr Vorteile als nur die Verwaltung von Quellcode. GitLab ist mit seiner Integration in Google Cloud eine ideale Wahl für Entwickler(innen), die ihren Workflow nach der Migration verbessern möchten.\n\n> Erfahre mehr über die [Integration von GitLab in die Google Cloud](https://about.gitlab.com/blog/gitlab-google-cloud-integrations-now-in-public-beta/).",[678,1007,727],"google","2025-03-12",{"slug":1010,"featured":6,"template":681},"tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","content:de-de:blog:tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","Tutorial Migrate From Google Cloud Source Repositories To Gitlab","de-de/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","de-de/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"_path":1016,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":1017,"content":1023,"config":1033,"_id":1035,"_type":16,"title":1036,"_source":18,"_file":1037,"_stem":1038,"_extension":21},"/de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"title":1018,"description":1019,"ogTitle":1018,"ogDescription":1019,"noIndex":6,"ogImage":1020,"ogUrl":1021,"ogSiteName":716,"ogType":717,"canonicalUrls":1021,"schema":1022},"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":1018,"description":1019,"authors":1024,"heroImage":1020,"date":1028,"body":1029,"category":14,"tags":1030,"updatedDate":1032},[1002,1025,1026,1027],"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",[110,1031,727,678,879,14,235],"AWS","2024-11-27",{"slug":1034,"featured":92,"template":681},"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":1040,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":1041,"content":1047,"config":1056,"_id":1058,"_type":16,"title":1059,"_source":18,"_file":1060,"_stem":1061,"_extension":21},"/de-de/blog/monitor-application-performance-with-distributed-tracing",{"title":1042,"description":1043,"ogTitle":1042,"ogDescription":1043,"noIndex":6,"ogImage":1044,"ogUrl":1045,"ogSiteName":716,"ogType":717,"canonicalUrls":1045,"schema":1046},"Application Performance Monitoring (APM) mit Distributed Tracing","Erfahre, wie Distributed Tracing die Fehlerbehebung bei Problemen mit der Application Performance unterstützt, indem es eine durchgängige Transparenz und eine nahtlose Zusammenarbeit innerhalb deines Unternehmens ermöglicht.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098000/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%288%29_5x6kH5vwjz8cwKgSBh1w11_1750098000511.png","https://about.gitlab.com/blog/monitor-application-performance-with-distributed-tracing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Application Performance Monitoring (APM) mit Distributed Tracing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sacha Guyon\"}],\n        \"datePublished\": \"2024-06-13\",\n      }",{"title":1042,"description":1043,"authors":1048,"heroImage":1044,"date":1050,"body":1051,"category":14,"tags":1052,"updatedDate":1055},[1049],"Sacha Guyon","2024-06-13","Ausfallzeiten aufgrund von Anwendungsfehlern oder Performance-Problemen können für Unternehmen verheerende finanzielle Folgen haben. Laut Information einer [Umfrage der ITIC von 2022](https://itic-corp.com/server-and-application-by-the-numbers-understanding-the-nines/ \"Umfrage der ITIC von 2022\") kostet eine Stunde Ausfallzeit Unternehmen schätzungsweise 301.000 $ oder mehr. Diese Probleme sind häufig auf von Menschen vorgenommene Änderungen zurückzuführen, z. B. Code- oder Konfigurationsänderungen.\n\nUm Probleme schnell zu beheben, müssen Entwicklungs- und Betriebsteams Hand in Hand arbeiten, um die Ursache zu finden und das System zügig wiederherzustellen. Häufig nutzen sie jedoch unterschiedliche Tools, um ihre Anwendungen und Infrastruktur zu verwalten und zu überwachen. Das führt zu isolierten Daten, schlechter Kommunikation und einem unvollständigen Überblick – was die Lösung von Vorfällen verzögert.\n\nGitLab setzt genau hier an und vereint Softwarebereitstellung und Monitoring auf einer Plattform. Letztes Jahr haben wir [Error Tracking](https://docs.gitlab.com/ee/operations/error_tracking.html \"Error Tracking\") in [GitLab 16.0](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/#error-tracking-is-now-generally-available \"GitLab 16.0\") als feste Funktion integriert. Jetzt freuen wir uns, die [Beta-Version von Distributed Tracing](https://docs.gitlab.com/ee/operations/tracing \"Beta-Version von Distributed Tracing\") vorzustellen – der nächste große Schritt zu einem umfassenden Monitoring, das vollständig in die GitLab-DevSecOps-Plattform eingebettet ist.\n\n## Eine neue Ära der Effizienz: GitLab Observability\n\nGitLab Observability ermöglicht es Entwicklungs- und Operationsteams, Fehler, Traces, Protokolle und Metriken aus ihren Anwendungen und ihrer Infrastruktur zu visualisieren und zu analysieren. Durch die Integration des Application Performance Monitoring in bestehende Softwarebereitstellungs-Workflows werden Kontextwechsel minimiert und die Produktivität erhöht, sodass die Teams auf einer einheitlichen Plattform fokussiert zusammenarbeiten können.\n\nDarüber hinaus überbrückt GitLab Observability die Kluft zwischen Entwicklung und Betrieb, indem es Einblicke in die Application Performance in der Produktion gewährt. Dies verbessert die Transparenz, den Informationsaustausch und die Kommunikation zwischen den Teams. Folglich können sie Fehler und Leistungsprobleme, die durch neuen Code oder Konfigurationsänderungen entstehen, schneller und effektiver erkennen und beheben und so verhindern, dass diese Probleme zu größeren Vorfällen eskalieren, die sich negativ auf das Geschäft auswirken könnten.\n\n## Was ist Distributed Tracing?\n\nMit Distributed Tracing können Entwickler(innen) die Ursache von Leistungsproblemen bei Anwendungen und in der Architektur verteilter Systeme ermitteln. Ein Trace stellt eine einzelne Benutzeranfrage dar, die verschiedene Dienste und Systeme durchläuft. Die Entwickler(innen) sind in der Lage, den zeitlichen Ablauf der einzelnen Vorgänge und alle auftretenden Fehler zu analysieren.\n\nJede Protokollierung besteht aus einem oder mehreren Abschnitten, die einzelne Vorgänge oder Arbeitseinheiten darstellen. Spans enthalten Metadaten wie den Namen, Zeitstempel, Status und relevante Tags oder Protokolle. Durch die Untersuchung der Abhängigkeiten zwischen Spans können Entwickler(innen) den Request Flow verstehen, Performance-Engpässe erkennen und Probleme lokalisieren.\n\n### Distributed Tracing in Microservices\n\nDistributed Tracing ist besonders wertvoll für [Microservices-Strukturen](https://about.gitlab.com/de-de/topics/microservices/ \"Microservices-Strukturen\"), bei denen eine einzige Anfrage zahlreiche Serviceaufrufe in einem komplexen System nach sich ziehen kann. Tracing bietet Einblick in diese Interaktion und ermöglicht es den Teams, Probleme schnell zu diagnostizieren und zu beheben.\n\n![Nutzeranfrage beim Distributed Tracing, um Produktempfehlungen abzurufen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098009139.png)\n\nDieses Beispiel veranschaulicht, wie eine Nutzeranfrage verschiedene Dienste durchläuft, um Produktempfehlungen auf einer E-Commerce-Website abzurufen:\n- `User Action`: Dies zeigt die erste Aktion der Nutzer(innen) an, z. B. das Anklicken einer Schaltfläche zur Anforderung von Produktempfehlungen auf einer Produktseite.\n- `Web front-end`: Das Web-Frontend sendet eine Anfrage an den Empfehlungsdienst, um Produktempfehlungen abzurufen.\n- `Recommendation service`: Die Anfrage vom Web-Frontend wird vom Recommendation Service (dt. Empfehlungsservice) bearbeitet, der die Anfrage verarbeitet und eine Liste empfohlener Produkte erstellt.\n- `Catalog service`: Der Recommendation Service ruft den Servicekatalog auf, um Details zu den empfohlenen Produkten abzurufen. Ein Warnsymbol weist auf ein Problem oder eine Verzögerung in dieser Phase hin, z. B. eine zu langsame Rückmeldung oder einen Fehler beim Abrufen von Produktdetails.\n- `Database`: Der Catalog Service fragt die Datenbank ab, um die aktuellen Produktdaten abzurufen. Dieser Bereich zeigt die SQL-Abfrage in der Datenbank.\n\nDurch die Visualisierung dieses End-to-End-Trace können Entwickler(innen) Leistungsprobleme – hier ein Fehler im Servicekatalog – erkennen und Probleme im gesamten Distributionssystem schnell diagnostizieren und beheben.\n\n![Visualisierung des End-to-End-Trace in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098009140.png)\n\n## Wie funktioniert Distributed Tracing?\n\nIm Folgenden wird die Funktionsweise von Distributed Tracing Tools erläutert.\n\n### Sammeln von Daten aus beliebigen Anwendungen mit OpenTelemetry\n\nTraces und Spans können mit [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/ \"OpenTelemetry\") gesammelt werden, einem Open-Source-Framework für Beobachtungen, das eine breite Palette von SDKs und Bibliotheken für [die wichtigsten Programmiersprachen und Frameworks](https://opentelemetry.io/docs/languages/ \"die wichtigsten Programmiersprachen und Frameworks\") unterstützt. Dieses Framework bietet einen herstellerneutralen Ansatz für die Erfassung und den Export von Telemetriedaten, sodass Entwickler(innen) nicht an einen bestimmten Anbieter gebunden sind und die Tools auswählen können, die ihren Anforderungen am besten entsprechen.\n\nDas bedeutet, dass du, wenn du bereits OpenTelemetry mit einem anderen Anbieter verwendest, Daten an uns senden kannst, indem du einfach unseren Endpunkt zu deiner Konfigurationsdatei hinzufügst –so kannst du unsere Funktionen ohne Weiteres ausprobieren!\n\n![Daten aus verschiedenen Anwendungen werden über OpenTelemetry and GitLab Observability geschickt.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098009141.png)\n\n### Datenerfassung und -speicherung in großem Umfang mit schnellen Echtzeitabfragen\n\nBeobachtbarkeiterfordert die Speicherung und Abfrage riesiger Datenmengen bei gleichzeitiger Beibehaltung niedriger Latenzzeiten für Echtzeit-Analysen. Um diese Anforderungen zu erfüllen, haben wir eine horizontal skalierbare Langzeitspeicherlösung mit ClickHouse und [Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/ \"Kubernetes\") entwickelt, die auf unserer Übernahme von Opstrace basiert. Diese [Open-Source-Plattform](https://gitlab.com/gitlab-org/opstrace/opstrace \"Open-Source-Plattform\") gewährleistet eine schnelle Abfrageleistung und Skalierbarkeit auf Unternehmensebene, während gleichzeitig die Kosten minimiert werden.\n\n### Traces mühelos untersuchen und analysieren\n\nEine fortschrittliche Benutzeroberfläche auf nativer Ebene ist entscheidend für eine effektive Datenanalyse. Wir haben eine solche Schnittstelle von Grund auf entwickelt. Der Trace Explorer ermöglicht es den Nutzer(innen), Traces zu untersuchen und die Leistung ihrer Anwendung zu verstehen:\n\n- __Erweiterte Filterung:__ Filtere nach Diensten, Vorgangsnamen, Status und Zeitspanne. Die automatische Vervollständigung vereinfacht die Abfrage.\n- __Fehlerhervorhebung:__ Fehlerbereiche in den Suchergebnissen werden einfach erkannt.\n- __RED-Metriken:__ Visualisiere die Anforderungsrate, die Fehlerrate und die durchschnittliche Dauer in einem Zeitseriendiagramm für jede Suche in Echtzeit.\n- __Timeline-Ansicht:__ Einzelne Traces werden als Wasserfalldiagramm dargestellt. So erhältst du einen vollständigen Überblick über eine Anfrage, die über verschiedene Dienste und Vorgänge verteilt ist.\n- __Historische Daten:__ Nutzer(innen) können bis zu 30 Tage in die Vergangenheit zurückreichende Daten abfragen.\n\n![Tracing Benutzeroberfläche für eine effektive Datenanalyse.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098009141.png)\n\n## Wie wir bei GitLab das Distributed Tracing einsetzen\n\n[Dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding \"Dogfooding\") ist ein zentraler Wert und eine wichtige Praxis bei GitLab. Wir haben bereits frühere Versionen von Distributed Tracing für unsere technischen und betrieblichen Anforderungen verwendet. Hier sind ein paar Anwendungsbeispiele aus unseren Teams:\n\n### 1. Beheben von Fehlern und Leistungsproblemen in GitLab Agent für Kubernetes\n\nDie [Environments-Gruppe](https://handbook.gitlab.com/handbook/engineering/development/ops/deploy/environments/ \"Environments-Gruppe\") hat Distributed Tracing verwendet, um Probleme mit dem [GitLab Agent für Kubernetes](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent \"GitLab Agent für Kubernetes\") zu beheben, z. B. Zeitüberschreitungen oder hohe Latenzzeiten. Die Ansichten „Trace List“ und „Trace Timeline“ bieten dem Team wertvolle Einsichten, mit denen sie derartige Probleme effizient lösen können. Diese Traces werden in den [entsprechenden GitLab Issues](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/386#note_1576431796 \"entsprechenden GitLab Issues\") geteilt und diskutiert, wo das Team dann gemeinsam an der Lösung arbeitet.\n\n*„Die Funktion Distributed Tracing ist von unschätzbarem Wert, wenn es darum geht, festzustellen, wo Latenzprobleme auftreten, sodass wir uns auf die eigentliche Ursache konzentrieren und diese schneller beheben können.“ - Mikhail, GitLab-Ingenieur*\n\n### 2. Optimierung der Dauer der GitLab-Build-Pipeline durch Ermittlung von Leistungsengpässen \n\nLangsame Deployments von GitLab-Quellcode können sich erheblich auf die Produktivität des gesamten Unternehmens sowie auf unsere Rechenleistung auswirken. In unserem Haupt-Repository werden jeden Monat [über 100.000 Pipelines](https://gitlab.com/gitlab-org/gitlab/-/pipelines/charts \"über 100.000 Pipelines\") ausgeführt. Wenn sich die Zeit für die Ausführung dieser Pipelines nur um eine Minute ändert, können dadurch mehr als 2.000 Stunden Arbeitszeit hinzukommen oder wegfallen. Das sind 87 zusätzliche Tage!\n\nUm die Ausführungszeit von Pipelines zu optimieren, verwenden die [Entwicklerteams der GitLab-Plattform](https://handbook.gitlab.com/handbook/engineering/infrastructure/ \"Entwicklerteams der GitLab-Plattform\") ein [speziell entwickeltes Tool](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace \"speziell entwickeltes Tool\"), das GitLab-Deployment-Pipelines in Traces umwandelt.\n\nDie Ansicht „Trace Timeline“ ermöglicht es den Teams, die detaillierte Ausführung komplexer Pipelines zu visualisieren und festzustellen, welche Aufträge Teil des kritischen Pfads sind und den gesamten Prozess verlangsamen. Durch die Identifizierung dieser Engpässe können sie die Auftragsausführung optimieren, indem sie z. B. dafür sorgen, dass der Auftrag schneller fehlschlägt oder mehr Aufträge parallel ausgeführt werden, um die Gesamteffizienz der Pipeline zu verbessern.\n\n![Trace Timeline und Details](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098009143.gif)\n\nDas Skript ist frei verfügbar, sodass du es für deine eigenen Pipelines anpassen kannst.\n\n*„Der Einsatz von Distributed Tracing für unsere Deployment-Pipelines war ein echter Durchbruch. Es hat uns geholfen, Engpässe schnell zu erkennen und zu beseitigen, was unsere Bereitstellungszeiten erheblich verkürzt hat“ - Reuben, GitLab Engineer*\n\n## Was kommt als Nächstes?\nIn den nächsten Monaten werden wir unsere Beobachtbarkeits- und Monitoring-Funktionen mit den kommenden Versionen Metrics und Logging weiter ausbauen. Weitere Informationen findest du auf unserer Seite zu GitLabObservability.\n\n## Nimm an der privaten Beta teil\nMöchtest du Teil dieser aufregenden Entwicklung sein? Melde dich für die private Beta-Version an und probiere unsere Funktionen aus. Mit deinem Beitrag kannst du die Zukunft der Beobachtbarkeit in GitLab mitgestalten und sicherstellen, dass unsere Tools perfekt auf deine Bedürfnisse und Herausforderungen abgestimmt sind.\n",[1053,750,726,727,1054],"performance","collaboration","2024-10-23",{"slug":1057,"featured":92,"template":681},"monitor-application-performance-with-distributed-tracing","content:de-de:blog:monitor-application-performance-with-distributed-tracing.yml","Monitor Application Performance With Distributed Tracing","de-de/blog/monitor-application-performance-with-distributed-tracing.yml","de-de/blog/monitor-application-performance-with-distributed-tracing",{"_path":1063,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":1064,"content":1071,"config":1081,"_id":1083,"_type":16,"title":1084,"_source":18,"_file":1085,"_stem":1086,"_extension":21},"/de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":1065,"description":1066,"ogTitle":1065,"ogDescription":1066,"noIndex":6,"ogImage":1067,"ogUrl":1068,"ogSiteName":716,"ogType":1069,"canonicalUrls":1068,"schema":1070},"GitLab-Tutorial: Releases & Versionshinweise automatisieren","Mit GitLab kannst du Release-Artefakte, Versionshinweise und Änderungsprotokolle, die benutzerbezogenen Software-Änderungen enthalten, automatisieren.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab","Artikel","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Releases und Versionshinweise mit GitLab automatisieren\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Ridley\"}],\n        \"datePublished\": \"2023-11-01\",\n      }",{"title":1065,"description":1066,"authors":1072,"heroImage":1067,"date":1074,"body":1075,"category":14,"tags":1076,"updatedDate":1080},[1073],"Ben Ridley","2023-11-01","***Update 2025** - Die Änderungsprotokoll-API wurde weiterentwickelt und enthält jetzt geniale neue Funktionen, auf die wir in diesem Blog nicht eingehen, wie die Möglichkeit, benutzerdefinierte Änderungsprotokolle mit Vorlagenwerten aus deinem Commit-Verlauf bereitzustellen. [Mehr dazu erfährst du in der offiziellen Dokumentation zu Änderungsprotokollen (nur in englischer Sprache verfügbar).](https://docs.gitlab.com/user/project/changelogs/)*\n\nWenn du Software entwickelst, auf die sich Benutzer(innen) verlassen, ist eine effektive Kommunikation über Änderungen bei jeder Release unerlässlich. Indem du Benutzer(innen) über neue Funktionen sowie darüber informierst, was geändert oder entfernt wurde, stellst du sicher, dass sie die Vorteile der Software wirklich nutzen können und sie bei Upgrades keine unangenehmen Überraschungen erwarten.\n\nIn der Vergangenheit war das Erstellen von Versionshinweisen und die Pflege eines Änderungsprotokolls eine mühsame Aufgabe, bei der Entwickler(innen) die Änderungen extern überwachen oder eigene Release Manager den Verlauf der Zusammenführungen durcharbeiten mussten. Mit der Änderungsprotokoll-API von GitLab kannst du den umfassenden Verlauf, der in unserem Git-Repository gespeichert ist, heranziehen, um ganz einfach Versionshinweise zu erstellen und ein Änderungsprotokoll zu führen.\n\nIn diesem Tutorial sehen wir uns an, wie du Releases mit GitLab automatisieren kannst und finden heraus, wie man Release-Artefakte, Versionshinweise und ein umfassendes Änderungsprotokoll, das alle benutzerbezogenen Software-Änderungen enthält, erstellt.\n\n## Releases in GitLab\nZuerst wollen wir uns ansehen, wie Releases in GitLab funktionieren.\n\nIn GitLab ist eine Release eine bestimmte Version deines Codes, die durch ein Git-Tag identifiziert wird. Dieses enthält Details zu den Änderungen seit der letzten Release (und Versionshinweise) sowie zugehörige Artefakte, die aus dieser Version des Codes erstellt wurden, wie Docker-Images, Installationspakete und Dokumentation.\n\nDu kannst Releases in GitLab über die UI erstellen und nachverfolgen, indem du unsere Release-API aufrufst oder den Job `release` innerhalb einer CI-Pipeline aufrufst. In diesem Tutorial verwenden wir den Job `release` in einer CI/CD-Pipeline, sodass wir die Automatisierung, die wir in unserer Pipeline zum Testen, für Code-Scans und mehr verwenden, auch für automatisierte Releases nutzen können.\n\nUm unsere Releases zu automatisieren, müssen wir zunächst die folgende Frage beantworten: Wo bekommen wir für unsere Versionshinweise und unser Änderungsprotokoll Informationen zu den vorgenommenen Änderungen? Die Antwort: In unserem Git-Repository, in dem wir durch Commit-Nachrichten und den Merge-Commit-Verlauf eine umfassende Übersicht über die Entwicklungsaktivitäten haben. Sehen wir uns an, ob wir diesen umfassenden Verlauf nutzen können, um automatisch unsere Versionshinweise und Änderungsprotokolle zu erstellen.\n\n## Einführung in Commit-Trailer\n[Commit-Trailer](https://git-scm.com/docs/git-interpret-trailers) sind strukturierte Einträge in deinen Git-Commits, die erstellt werden, indem du einfach die Formatierungsnachrichten `\u003CHEADER>:\u003CBODY>` am Ende deines Commits einfügst. Das CLI-Tool `git` kann diese dann parsen und für die Verwendung in anderen Systemen extrahieren. Ein Beispiel, das du vielleicht schon einmal verwendet hast, ist `git commit --sign-off`, um ein Commit zu beenden. Dies wird implementiert, indem der Trailer `Signed-off-by: \u003CDein Name>` zum Commit hinzugefügt wird. Wir können hier beliebige strukturierte Daten hinzufügen, sodass dies eine tolle Möglichkeit ist, Informationen zu speichern, die für das Änderungsprotokoll nützlich sein könnten.\n\nWenn wir in unseren Commits den Trailer `Changelog: \u003Cadded/changed/removed>` verwenden, parst die Änderungsprotokoll-API von GitLab diese und verwendet sie, um automatisch ein Änderungsprotokoll für uns zu erstellen!\n\nSehen wir uns das in Aktion an, indem wir Änderungen an einer echten Codebase vornehmen, eine Release durchführen und dann Versionshinweise und Änderungsprotokoll-Einträge generieren.\n\n## Beispielprojekt\nFür diesen Blog verwende ich ein einfaches Python-Web-App-Repository. Nehmen wir an, dass Version 1.0.0 der Anwendung gerade veröffentlicht wurde und die aktuelle Version des Codes ist. Ich habe auch die Release 1.0.0 in GitLab erstellt, was ich manuell tun musste, da wir unsere automatisierte Release-Pipeline ja noch nicht erstellt haben:\n\n![Ein Screenshot der GitLab-UI, die eine Release für Version 1.0.0 zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/1-0-release.png)\n\n## Nehmen wir unsere Änderungen vor\nWir entwickeln rasend schnell und arbeiten daher schon daran, Version 2.0.0 unserer Anwendung heute zu veröffentlichen. Im Rahmen unserer Release 2.0.0 fügen wir eine neue Funktion zu unserer App hinzu: einen Chatbot! Wir werden auch die Quanten-Blockchain-Funktion entfernen, da wir diese nur für die erste Finanzierungsrunde benötigt haben. Außerdem fügen wir einen automatisierten Release-Job zu unserer CI/CD-Pipeline für unsere Release 2.0.0 hinzu.\n\nZuerst entfernen wir die nicht benötigten Funktionen. Ich habe einen Merge Request erstellt, der die notwendigen Änderungen enthält. Wir müssen sicherstellen, dass wir eine Commit-Nachricht haben, die den Trailer `Changelog: removed` enthält. Dazu gibt es mehrere Möglichkeiten: Wir können ihn unter anderem direkt in einen Commit einbauen oder einen interaktiven Rebase durchführen und über das CLI hinzufügen. Der einfachste Weg in unserem Fall ist meiner Meinung nach, bis zum Ende zu warten und dann die Schaltfläche `Edit commit message` in GitLab zu verwenden, um den Trailer folgendermaßen zum Merge-Commit hinzuzufügen:\n\n![Screenshot der GitLab-UI, der einen Merge Request zum Entfernen nicht verwendeter Funktionen zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/remove-unused-features-mr.png)\n\nMit dieser Methode kannst du auch den Titel des Merge-Commits auf einen prägnanteren Titel ändern. Ich habe den Titel meines Merge-Commit auf „Nicht verwendete Funktionen entfernen“ geändert, da dies im Eintrag im Änderungsprotokoll angezeigt wird.\n\nAls nächstes fügen wir einige neue Funktionen für die Version 2.0.0 hinzu. Hier müssen wir nur einen weiteren Merge Request öffnen, der unsere neuen Funktionen enthält, und dann den Merge-Commit bearbeiten, sodass er den Trailer `Changelog: added` enthält, und dann den Commit-Titel auf einen prägnanteren Titel ändern:\n\n![Screenshot der GitLab-UI, der einen Merge Request zum Hinzufügen neuer Funktionen zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/add-chatbot-mr.png)\n\nJetzt sind wir eigentlich bereit, 2.0.0 zu veröffentlichen. Aber dieses Mal möchten wir unsere Release nicht manuell erstellen. Deshalb fügen wir vor der Release einige Jobs zur Datei `.gitlab-ci.yml` hinzu, die die Release automatisch für uns durchführen und die entsprechenden Versionshinweise und Einträge ins Änderungsprotokoll erstellen, wenn wir unseren Code mit einer neuen Version wie z. B. `2.0.0` taggen.\n\n**Hinweis:** Wenn du Änderungsprotokoll-Trailer erzwingen möchtest, solltest du überlegen, etwas wie [Gefahr bei der Durchführung automatischer Überprüfungen für MR-Konventionen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/development/dangerbot.html) zu verwenden.\n\n## Erstellen einer automatisierten Release-Pipeline\nDamit unsere Pipeline funktioniert, müssen wir ein Projektzugriffstoken erstellen, mit dem wir die GitLab-API aufrufen können, damit sie die Einträge im Änderungsprotokoll erstellt. [Erstelle ein Projektzugriffstoken im API-Bereich (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) und [speichere das Token dann als CI/CD-Variable (nur in englischer Sprache verfügbar)]((https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui) mit dem Namen `CI_API_TOKEN`. Wir verweisen auf diese Variable, um uns bei der API zu authentifizieren.\n\nNun fügen wir zwei neue Jobs zu unserer Datei `gitlab-ci.yml` hinzu:\n```yaml\nprepare_job:\n  stage: prepare\n  image: alpine:latest\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - apk add curl jq\n    - 'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\" | jq -r .notes > release_notes.md'\n  artifacts:\n    paths:\n    - release_notes.md\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  needs:\n    - job: prepare_job\n      artifacts: true\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - echo \"Creating release\"\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: release_notes.md\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_SHA'\n    assets:\n      links:\n        - name: 'Container Image $CI_COMMIT_TAG'\n          url: \"https://$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\"\n```\n\nIn der oben angeführten Konfiguration verwendet `prepare_job` die Befehle `curl` und `jq`, um den Endpunkt der Änderungsprotokoll-API von GitLab aufzurufen und übergibt dies dann an unser `release_job`, um die Release zu erstellen. Genauer gesagt sieht das so aus:\n- Wir verwenden das Projektzugriffstoken, dass wir zuvor erstellt haben, um die Änderungsprotokoll-API von GitLab aufzurufen, die dann die Versionshinweise erstellt. Wir speichern dies als Artefakt.\n- Wir verwenden die Variable `$CI_COMMIT_TAG` als Version. Dazu müssen wir eine semantische Versionierung für unsere Tags verwenden (beispielsweise so etwas wie `2.0.0`). Du wirst auch bemerkt haben, dass ich den Release-Job mit dem Abschnitt `rules` eingeschränkt habe, der auf ein semantisches Versions-Tag überprüft.\n\t- Damit die Änderungsprotokoll-API von GitLab funktioniert, ist eine semantische Versionierung erforderlich. Sie verwendet dieses Format, um die neueste Release zu finden und sie mit unserer aktuellen Release zu vergleichen.\n- Wir verwenden das offizielle Image `release-cli` von GitLab. „release-cli“ ist erforderlich, um das Schlüsselwort `release` in einem Job zu verwenden.\n- Wir verwenden das Schlüsselwort `release`, um eine Release in GitLab zu erstellen. Dies ist ein spezielles Job-Schlüsselwort, das für die Erstellung einer Release und das Ausfüllen der erforderlichen Felder reserviert ist.\n- Wir können eine Datei als Argument an die `description` der Release übergeben. In unserem Fall ist es die Datei, die wir in `prepare_job` erstellt haben und die als Artefakt an diesen Job übergeben wurde.\n- Wir haben auch unser Container-Image, das früher in der Pipeline erstellt wurde, als Release-Asset hinzugefügt. Du kannst alle Assets aus deinem Build-Prozess anhängen, die du möchtest, z. B. Binärdateien oder Dokumentationen, indem du eine URL zu dem Ort angibst, an den du sie zuvor in der Pipeline hochgeladen hast.\n\n## Durchführen einer automatisierten Release\nMit dieser Konfiguration müssen wir nur ein Tag in unser Repository übertragen, das unserem Versionsschema entspricht, um eine Release durchzuführen. Du kannst einfach ein Tag mit dem CLI pushen. Für dieses Beispiel wird die GitLab-UI verwendet, um ein Tag im main-Branch zu erstellen. Erstelle ein Tag, indem du in der Seitenleiste „Code“ -> „Tags“ -> „Neues Tag“ auswählst:\n![Screenshot der GitLab-UI, der zeigt, wie man ein Tag erstellt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/create-2-tag.png)\n\nNach der Erstellung werden unsere Pipelines ausgeführt. Die Änderungsprotokoll-API von GitLab generiert automatisch Versionshinweise für uns als Markdown, der alle Änderungen zwischen dieser Release und der vorherigen Release enthält. Hier ist der Markdown, der in unserem Beispiel generiert wurde:\n\n```md\n## 2.0.0 (2023-08-25)\n\n### added (1 change)\n\n- [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4))\n\n### removed (1 change)\n\n- [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3))\n```\n\nWie du sehen kannst, hat GitLab die Einträge für unsere Versionshinweise automatisch mit unseren Git-Commit-Trailern extrahiert. Außerdem werden hilfreiche Links zum Merge Request bereitgestellt, damit die Leser(innen) weitere Details und Diskussionen zu den Änderungen sehen können.\n\nUnd jetzt folgt unsere letzte Release:\n![GitLab-Release-UI, die ein Release für Version 2.0.0 zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/2-0-release.png)\n\n## Erstellen des Änderungsprotokolls\nAls nächstes möchten wir unser Änderungsprotokoll aktualisieren (das im Grunde ein gesammelter Verlauf aller deiner Versionshinweise ist). Du kannst dazu eine `POST`-Anfrage an den Änderungsprotokoll-API-Endpunkt senden, den wir zuvor verwendet haben.\n\nDu kannst dies auch als Teil deiner Release-Pipeline tun, wenn du möchtest. Dazu kannst du beispielswiese den folgenden Code in den Abschnitt `script` deines Vorbereitungsjobs einfügen:\n```sh\n'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" -X POST \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\"\n```\n\n**Beachte dabei, dass dies das Repository ändert.** Es wird ein Commit erstellt, um die neuesten Notizen zu einer Datei `CHANGELOG.md` hinzuzufügen:\n![Screenshot des Repositorys, der einen Commit zeigt, der die Änderungsprotokolldatei aktualisiert](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/changelog-api-commit.png)\n\nUnd das war’s auch schon! Indem wir den umfassenden Verlauf, den uns `git` bietet, mit praktischen Commit-Trailern nutzen, können wir die leistungsstarke API und die CI/CD-Pipelines von GitLab optimal einsetzen, um unsere Release-Prozesse zu automatisieren und Versionshinweise für uns zu erstellen.\n\n> Wenn du das Projekt erkunden möchtest, das wir für diesen Artikel verwendet haben, [findest du es unter diesem Link](https://gitlab.com/gitlab-learn-labs/sample-projects/release-automation-demo).\n",[1077,748,110,1078,702,1079],"Tutorial","DevOps","Git","2025-06-05",{"slug":1082,"featured":6,"template":681},"tutorial-automated-release-and-release-notes-with-gitlab","content:de-de:blog:tutorial-automated-release-and-release-notes-with-gitlab.yml","Tutorial Automated Release And Release Notes With Gitlab","de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab.yml","de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab",2,[688,709,734,758,780,799,824,844,865],1753475285955]